|
This FAQ (Frequently Asked Questions) provides explanation and guidance for those implementing the ISO/IEC 27000-series (“ISO27k”) standards, now including sprinkling of pragmatic implementation tips.
ISO27k FAQ quick links
What does “ISO” mean? And what about “ISO/IEC”? What do “FDIS” and other ISO/IEC acronyms mean? What is meant by “JTC/1 SC27” and what are “WG’s”?
How can I keep up with developments to the ISO 27000-series standards? Can I see draft ISO/IEC standards? Can I contribute to them? How can I get involved in the development of security standards?
What is really involved in becoming ISO/IEC 27001 certified? How do we start the certification process? What are the differences between SOA, RTP and AP? What does a RTP look like?  What kinds of things should be included in our asset inventory? Should the risk assessment process cover all our information assets? What will be covered in our security policy? Will the controls we already have be sufficient for certification? What documents are normally part of an ISMS? What format and style is appropriate for ISMS documentation? Is control X mandatory [for various values of X]?  Is it necessary to appoint an Information Security Manager? What should the ISMS implementation project manager do to assure success?
How does my organization get certified against ISO/IEC 27002? OK then, how do we get certified against ISO/IEC 27001? Who can certify us against ISO/IEC 27001? How does the certification process work? Why isn’t there a simple checklist we can follow?
What considerations should we take into account for the ISMS internal audits? How can we confirm the implementation of controls in the SOA? Will the certification auditors check our information security controls?
Download the FAQ as a PDF
(It’s better formatted for printing but the content is months out of date, sorry)
Information security vs. IT security
Q: “The titles of the ISO27k standards mention ‘Information Technology -- Security Techniques’. Does this mean they only apply to IT?”
A: No, most certainly not! The formal titles simply reflect the name of the joint ISO + IEC committee that oversees their production, namely SC27 “Information Technology -- Security Techniques”, itself a subcommittee of JTC1 “Information Technology”.
The scope of the ISO27k standards naturally includes many aspects of IT but does not stop there. The introduction to ISO/IEC 27002 states explicitly: “Information can exist in many forms. It can be printed or written on paper, stored electronically, transmitted by post of using electronic means, shown on films, or spoken in conversation. Whatever form information takes, or means by which it is shared or stored, it should always be appropriately protected.”
Not all an organization’s information assets belongs to or are managed within the IT function. IT typically owns and manages the shared IT infrastructure (the main corporate IT and network systems) but acts as a custodian for most corporate information content which belongs to other business units, and for other content belonging to customers and business partners. There are important implications in that information owners are accountable for ensuring that their information assets are adequately protected, just like other corporate assets. While information asset owners generally delegate key responsibilities for information security to an information security management function and/or IT function, they remain accountable and must ensure that information security is adequately funded and supported to achieve the necessary level of protection.
Implementation tip: think of IT as custodians of the subset of all information assets which exist as computer data and systems. In most cases they are not the asset owners as such, and furthermore they have little involvement in other information assets such as paperwork and knowledge. It helps to focus first on critical business processes rather than the IT systems which often support or enable them.
Q: “When creating an ISMS, is it an absolute necessity to include members from all aspects of the business (business owners, finance, legal, HR, etc.)? I don't see the ISMS as being IT Security driven. I see it as being driven by the business with IT Security input. Am I correct?”
A: ISO27k is quite definitely about information security management systems. IT security is of course a large part these days, given that so much information is communicated, stored and processed on computers, but non-computerized information assets (files, paperwork, printouts, knowledge) are still valuable corporate assets that deserve protection just as much as computer data, if not more so in the case of proprietary knowledge. What's more, the average IT department does not have full and total control of all the computer data, systems and/or networks in the entire organization, so limiting the scope of the ISMS to IT would not necessarily protect all the data to the same degree.
It is still possible to narrow the scope and apply the ISMS more narrowly, perhaps to IT or the data centre. Although this probably loses a significant proportion of the benefits of an enterprise-wide ISMS, it also reduces the costs and typically speeds implementation. Just be careful that you will need to clarify security issues and probably apply additional controls at the scope boundary, meaning additional hidden costs (e.g. explicit security clauses in SLAs and contracts between IT and The Rest). It's sub-optimal overall but can be a useful tactic to get your ISMS started and build some experience.
Implementation tip: the organization's senior management should focus on identifying suitable "information owners" - generally quite senior managers throughout the business - who they will hold personally accountable for adequately protecting 'their' assets on behalf of the organization and its stakeholders. The owners, in turn, will call on IT, information security, HR, risk, compliance, legal and/or third parties to provide the protection they require, and to help them clarify and specify their security requirements in the first place through some process of information security risk assessment. The responsibility for security cascades naturally through the organization but accountability rests firmly at the top ("the buck stops here"). This is a useful concept because those at the top generally have the budgets and influence to make security happen.
Back to top
Learning more about the ISO27k standards
Q: “Where can I obtain [insert name of ISO27k standard here]?”
A: ISO/IEC 27000, ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27005, ISO/IEC 27006 and other published standards may be purchased directly from ISO or from the various national standards bodies (such as ANSI or the British Standards Institute) and/or a number of third party commercial organizations (such as IHS Technical Indexes, SAI Global and TechStreet). We have no ongoing commercial relationship with these organizations. There are several other sources - shop around for the best deals, for example using this Google search.
If money is tight, it is worth checking the prices for localized/national versions of the standards. ISO sells the standards directly e.g. ISO/IEC 27002 costs ~200 Swiss dollars as a PDF or hardcopy. Several national standards bodies release translated versions of the standards in their local languages but all of them go to great lengths to ensure that the translations remain true to the original. Various commercial organizations sell the standards under license. SAI Global, for example, charges about US$180 for the ISO/IEC version of ISO/IEC 27002, or US$110 for the Australia and New Zealand Standards version, whereas the BSI charges about US$200 for the British version.
By the way, it is probably worth searching on the formal names of the standards including the “/IEC” bit, but perhaps not the date since country-specific translations of the standards are often issued later than the original versions (avoid old versions though!).
Both ISO/IEC 27001 and ISO/IEC 27002 can be purchased in electronic softcopy and hardcopy formats. Hardcopies are easier to read on the train or discuss in meetings. Softcopies are ideal for online searching for specific controls and for cutting and pasting into your own policy documents etc. (subject to the copyright restrictions). In addition to the usual PDF downloads, standards bodies may license online (intranet) access to the standards, limited by the number of concurrent users - this may be suitable for organizations who implement the standards and want to give their employees instant access to the standards for reference.
Implementation tip:  ANSI sells downloadable PDFs of ISO/IEC 27001 and ISO/IEC 27002 for just US$30 each (bargain!). BSI sells some as-yet-unpublished draft ISO27k standards “for public comment”, such as ISO/IEC 27003.
Q: “I want to become an ISO27k consultant. I’m looking for books or courses that teach ISO27k ... ”
A: The best books on the ISO27k standards are the standards themselves - in other words, you should buy and read the standards (see above). Being standards, they are quite formal in style but readable and useful. If you are going to implement them, write policies based upon them, consult around them etc. you will inevitably have to become very familiar with them so buy your copies and start reading!
The two main standards are essential:
ISO/IEC 27001 is the formal certification standard, the ‘Specification for Information Security Management Systems’. It is especially useful if you intend to become a accredited ISMS certification auditor - the usual way of doing that is to go through a training course run by one of the information security management system accredited audit and certification bodies such as the BSI, or various training and consultancy companies. They are generally called “ISO/IEC 27001 Lead Auditor” courses. ISO/IEC 27002 is the ‘Code of Practice’, a practical standard with tons of advice for those designing and implementing an information security management system. The best way to learn ISO/IEC 27002 is to use it, which means going all the way through an implementation from planning to operations, auditing and maintenance. If you have no prior experience in information security, you should try to find an experienced mentor or guide. Professional organizations such as ISSA, ISF and ISACA can help. Once you have made a start on your implementation, please join the free ISO27k Implementers’ Forum to consult with your peers.
As a professional and/or a consultant in this field, you should also be well aware of the remaining issued ISO27k standards (e.g. ISO/IEC 27005) and have some familiarity with other similar/related standards, methods, laws etc. (such as PCI DSS, COBIT and various privacy laws).
[There is more advice in the next Q&A.]
Implementation tip: further resources are outlined on the books and links pages and don’t forget to join the ISO27k Implementers’ Forum - the archive is a valuable resource worth browsing or searching, and members can always seek fresh answers though live dialogue.
Q: Are there any suitable qualifications for ISO27k users?
A: Kind of. There are training courses that hand out certificates of completion, not ‘qualifications’ exactly. The most common types of course are:
ISO/IEC 27001 Lead Auditor - these were initially run internally by accredited ISO/IEC 27001 certification bodies in order to train up their own staff to perform certification audits. Subsequently, public commercial Lead Auditor courses emerged.
Note: certification auditors are supposed to complete a number of certification audits under the guidance of a qualified certification auditor before claiming to be qualified, but some pass the course and immediately add “ISO/IEC 27001 LA” to their CVs and email sigs. Caveat emptor! ISO/IEC 27001 or ISO/IEC 27002 Lead Implementer - in response to demand for help with implementing the ISO27k standards rather than just auditing against ’27001, a number of IT training companies are now offering “Lead Implementer” courses. These aim to give students some familiarity with the ISO27k standards, and then presumably provide pragmatic guidance on how to apply them by designing and implementing an ISMS.
Other than the ISO and national standards bodies processes for checking and accrediting organizations who wish to offer ‘official’ compliance certification services, there is currently no global equivalent of, say, ISACA or (ISC)2 overseeing the ISO27k courses and qualifications in order to maintain professional standards, insist on continuous professional education and so forth. At present there is nothing to stop anyone offering Lead Implementer training courses and issuing certificates like confetti. Unfortunately, this calls into doubt the validity of the Lead Implementer courses and certificates in particular, and potentially discredits both the organizations currently offering them and the candidates who obtain them, even though they may be truly excellent. It’s a question of assurance not quality.
Advice for people who want to become IT auditors in our IT audit FAQ is useful for those planning to become Lead Auditors or Lead Implementers and is also pretty relevant to becoming an information security management specialist since the two fields are very closely related. Another excellent resource is www.cccure.org, especially if you are considering becoming CISSP, SSCP or CISM qualified in information security management - these are not specific to ISO27k but are generally well regarded.
Implementation tip: in our opinion, demonstrable hands-on ISMS implementation and audit experience, ideally with more than one organization, is by far the best “qualification” in the field today. Next best would be demonstrable consultancy experience, helping a number of clients design, install and run their ISMSs, preferably again with a considerable amount of hands-on work and not merely advising at a distance. The Lead Auditor and particularly the Lead Implementer certifications may lack credibility but nevertheless the courses are a valuable introduction for beginners, although students who already have a reasonable understanding of information security management concepts are more likely to benefit from ISO27k-specific training.
Back to top
ISO/IEC acronyms and committees
Q: “What does ‘ISO’ mean? And what about ‘ISO/IEC’?”
A: ISO is the short or common name of the global standards body known in English as the International Organization for Standardization. “ISO” is not strictly an abbreviation since the long name varies in different languages - it is in fact derived from the Greek word isos meaning equal. At least, that’s what we’re told.
IEC is the International Electrotechnical Commission, another international standards body that cooperates closely with ISO on electrical, electronic and related technical standards. Standards developed jointly with ISO are prefixed “ISO/IEC” although in practice most users [incorrectly] shorten it to “ISO”.
ISO/IEC also collaborate on some standards with other international organisations (both governmental and private sector) such as the ITU, the International Telecommunication Union. The ITU is primarily a trade body coordinating telecomms organizations to enable worldwide communications. It allocates radio frequencies, for example, to minimize co-channel interference and encourage the manufacture of radio equipment that can be used internationally.
Q: “What do ‘FDIS’ and those other acronyms prepended to draft ISO standards really mean?”
A: The acronyms indicate the stages reached by International Standards as they progress sequentially through the various committees and approvals:
PWI = Preliminary Work Item - initial feasibility and scoping activities NP = New Proposal (or study period) - formal scoping phase * WD = Working Draft (1st WD, 2nd WD etc.) - development phase CD = Committee Draft (1st CD, 2nd CD etc.)- quality control phase * FCD = Final Committee Draft - ready for final approval * DIS = Draft International Standard - nearly there * FDIS = Final Draft or Distribution International Standard - just about ready to publish * IS = International Standard - published!
* At several stages during the standards development process, national standards bodies that belong fully to ISO/IEC JTC1/SC27 are invited to vote on the standards and submit comments, particularly if they disapprove of anything.
A similar sequence applies to Technical Reports.
The process from PWI to IS normally takes between 2 and 4 years (average 2.8 years), given the attention to detail at every stage and the need for collaboration and consensus on a global scale e.g. when a WD is issued for comments, representatives of the national standards bodies that belong to ISO or IEC (known as “Member Bodies” MBs within ISO but “National Committees” NCs in IEC) typically have ~3 months to review the document, discuss it amongst themselves and submit formal votes and comments. If the comments are unfavourable or complex, an updated WD is normally released for a further round of comments. When documents have stabilised, they are circulated for voting. Any of you with experience of getting formal documents such as security policies prepared, reviewed and approved by your management will surely appreciate the ‘fun’ involved in doing this in an international arena!
A fast-track process is sometimes used to adopt an existing national standard as an ISO standard. Some 6 months is allowed for comments and no more than a quarter of the votes may be negative if the standard is to be approved. Don’t forget that “fast” is a relative term.
Published standards are reviewed every five years, or earlier if defect reports are submitted.
Q: “What is meant by ‘JTC/1 SC27’ and what are ‘WG’s’?”
A: As you might expect, an international body developing and coordinating a vast range of technical standards on a global basis has evolved a correspondingly vast bureaucracy to manage and share the work. Member Bodies normally participate in the development of standards through Technical Committees established by the respective organisation to deal with particular fields of technical activity. The ISO and IEC Technical Committees often collaborate in fields of mutual interest. IT standardisation presents unique requirements and challenges given the pace of innovation therefore, in 1987, ISO and IEC established a Joint Technical Committee ISO/IEC JTC 1 with responsibility for IT standards.
JTC1’s purpose is “Standardization in the field of Information Technology” which “includes the specification, design and development of systems and tools dealing with the capture, representation, processing, security, transfer, interchange, presentation, management, organization, storage and retrieval of information.” While there is general agreement that information security is a superset of IT security, the fact that the ISO/IEC committee is IT specific means that the ISO27k information security standards are in fact labelled IT standards.
In ISO-speak, “SC” is a “Sub-Committee”. SC27 is the main (but not the only!) ISO Sub-Committee responsible for numerous IT security standards. SC27 is a Sub-Committee of ISO/JTC1. SC27 runs around 90 projects of which around half are actively progressing. SC27, in turn, has carved-up its workload across five WGs (Working Groups):
SC27/WG1 - Information Security Management Systems: responsible for developing and maintaining the ISO27k family, in particular the core ISMS specification ISO/IEC 27001 and the code of practice ISO/IEC 27002. Convenor: Professor Ted Humphreys; SC27/WG2 - Security Techniques and Mechanisms: cryptography, algorithms, authentication, key management, digital signatures and all that. Convenor: Mr K Naemura; SC27/WG3 - Security Evaluation Criteria: Common Criteria, evaluation methods, protection profiles, security capability maturity models etc. Convenor: Mr M Ohlin; SC27/WG4 - Security Control Objectives and Controls: responsible for a variety of existing standards covering intrusion detection, IT network security, incident management, ICT disaster recovery, use of trusted third parties etc. and new areas such as business continuity, application security, cybersecurity and outsourcing. Some of these also fall into ISO27k. Convenor: Dr Meng-Chow Kang; SC27/WG5 - Identity Management and Privacy Technologies : does pretty much exactly ‘what it says on the tin’ (the title is self-explanatory). Includes biometrics. Convenor: Professor Kai Rannenberg.
As if that wasn’t complicated enough, there are also “Other Working Groups” (OWGs), “Special Working Groups” (SWGs), “Rapporteur Groups” (RGs, advisors), “Joint Working Groups” (JWGs), Workshops and the IT Task Force (ITTF). [There is presumably also a secret CRfA (Committee Responsible for Acronyms) somewhere in ISO/IEC land!].
Aside from SC27, other subcommittees that consider security-related matters include:
SC 6 - Telecommunications and information exchange between systems SC 7 - Software and systems engineering SC 17 - Cards and personal identification SC 25 - Interconnection of information technology equipment SC 29 - Coding of audio, picture, multimedia and hypermedia information SC 31 - Automatic identification and data capture techniques SC 32 - Data management and interchange SC 36 - Information technology for learning, education and training SC 37 - Biometrics
Implementation tip: once you have gained ISMS implementation experience, consider helping the continued development of the ISO27k standards by contacting your national standards body and volunteering your assistance (more advice follows ...).
Please note: this website is independent of and does not belong to, nor is it endorsed by or affiliated with, ISO/IEC. Please read the disclaimer for more.
Back to top
Keeping up with security
standards developments
Q: “How can I keep up with developments to the ISO 27000-series standards?”
A: If you are actively using the ISO27k standards, the best way to keep up with developments is to join the ISO27k Implementers’ Forum. Don’t forget to bookmark this website and call back every month or so to check what’s new.
You might like to check out the ISMS newsletters out there and sign-up to any that provide useful information as opposed to merely promoting specific products. Good luck!
Another option is to Google ISO/IEC 27000 or related terms. Google knows about helpful resources such as this article from the UK’s National Computing Centre.
Professional information security-related organizations such as ISSA and ISACA, and journals such as EDPACS, are increasingly publishing articles on ISO/IEC 27001/2 etc. The CISSPs over at CISSPforum discuss ISO27k related matters quite often.
Finally, if you discover some ISO27k news before it is published here, please tell us so we can share it with the user community via this website and the Forum.
Q: “Can I see draft ISO/IEC standards? Can I contribute to them?”
A: If you would like to get involved in contributing to, reviewing and commenting on the ISO/IEC 27000-series standards, contact your national standards body and get in touch with the person, team or committee working with JTC1/SC27 on the information security standards. There is a genuine chance for experienced professionals to influence the future directions of ISO27k if they are prepared to put in the effort and collaborate with colleagues around the world. Don’t wait for the published standard to raise your criticisms and improvement suggestions! Offer to get involved in the drafting and review!
BSI sells some as-yet-unfinalised draft ISO27k standards, such as ISO/IEC 27003, presumably to encourage wider feedback.
Q: “How can I get involved in the development of security standards?”
A: Contact your local national standards body (e.g. BSI, NIST) to find out about any special interest groups and committees working in the information security arena. If you can spare the time to get involved with standards specification, development and/or review, contact your local ISO/IEC JTC1/SC27 representative/s to volunteer your services.
Implementation tip: the ISO/IEC security Sub-Committees and Working Groups are extremely busy and produce lots of paperwork. Committee work drafting and reviewing standards plus responding to queries from other interested parties has to be slotted-in with other duties including the day-job. If you get involved, be prepared to lose a substantial chunk of your free time reading, reviewing and contributing to draft standards. It’s fun though, and good to have the opportunity to influence the development of ISO27k standards!
Back to top
Getting started on ISO27k implementation
Q: “What is really involved in becoming ISO/IEC 27001 certified?”
A: See the overview ISMS implementation and ISO/IEC 27001 certification process diagram (click the diagram for a higher-resolution PDF version):
The flow chart gives a high level view of the major steps in the process. This is a generic diagram - the details will vary from situation to situation. The main activities are as follows:
Get management support - easier said than done! This typically involves raising management’s awareness of the costs and benefits of having a ISO/IEC 27001 compliant ISMS. A great way to start is to raise management’s awareness of some of the key current information security risks and potential good practice controls (drawn from ISO/IEC 27002) that are not yet in place, perhaps through a “gap analysis” (outline risk assessment) followed by a business case and/or strategy for the security improvement (ISMS implementation) program. Define ISMS scope - what businesses, business units, departments and/or systems are going to be covered by your Information Security Management System? Inventory your information assets - the inventory of information systems, networks, databases, data items, documents etc. will be used in various ways e.g. to confirm that the ISMS scope is appropriate, identify business-critical and other especially valuable or vulnerable assets etc. (more below) Conduct an information security risk assessment - ideally using a recognized formal method but a custom process may be acceptable if applied methodically. There’s more advice below. (a) Prepare a Statement of Applicability - according to ISO/IEC 27000 [currently pending final release], the SoA is a “documented statement describing the control objectives and controls that are relevant and applicable to the organization’s ISMS”. Which of the control objectives from ISO/IEC 27002 are applicable to your ISMS, and which are irrelevant, not appropriate or otherwise not required? Document these management decisions in your SOA; and in parallel ... (b) Prepare Risk Treatment Plan - ISO/IEC 27000 describes the information security RTP as “a plan that identifies the appropriate management actions, resources, responsibilities, timeliness and priorities for managing information security risks”. Develop ISMS implementation program - given the scale, it is generally appropriate to think in terms of an overall program of individual projects to implement various parts of ISO/IEC 27002, for example one project for each of the main sections of the standard. Which resources can you call upon, direct, use, borrow or persuade to build or supplement your core ISMS implementation team? You will probably need experienced information security professionals (particularly to lead the team) and support from a variety of related functions such as Internal Audit, Risk, Compliance, HR, Finance and Marketing, not just IT. You are advised to plan the work in risk-priority-order where possible i.e. tackle the biggest risks early so that, whatever happens to your program of work in practice, it has had a good go at knocking down the main issues and can demonstrate real progress. Also, early wins are a source of helpful positive feedback: this is an important aspect to the program which as to be seen to be effective by management, as well as actually being effective. If all the program does is interfere with business, annoy managers and cost a packet, it is hardly going to be on the shortlist of “things we really must keep doing next year”! Run the ISMS implementation program - through the individual project plans, the implementation team sets to work to implement the controls identified in the RTP. Conventional program and project management practices are required here, meaning proper governance, planning, budgeting, progress reporting, project risk management and so forth. If the program is large, seek professional program management assistance. Operate the ISMS - as each project in the program fills in part of the ISMS, it hands over a suite of operational security management systems and processes, accompanied by a comprehensive set of policies, standards, procedures, guidelines etc. Operating the ISMS is an ongoing activity for the organization, not a one-off project! The Information Security Management function needs to be established, funded and directed, and many other changes are likely to be required throughout the organization as information security becomes part of the routine. Collect ISMS operational artifacts - the ISMS comprises a framework of security policies, standards, procedures, guidelines etc., and it routinely generates security logs, log review reports, firewall configuration files, risk assessment reports etc. ... all of which need to be retained and managed. These artifacts are crucial evidence that the ISMS is operating correctly. You need to build up sufficient artifacts to prove to the auditors that the system is stable and effective. Review compliance - are your doing what you said you were going to do? Section 15 of ISO/IEC 27002 covers compliance with both internal requirements (corporate policies etc.) and external obligations (such as laws and industry regulations). The ISMS itself needs to incorporate compliance testing activities which will generate reports and corrective actions. Internal compliance assessments, and perhaps external/independent assessments (audits, penetration tests etc.) are therefore routine activities in a mature ISMS. The ISMS operational artifacts produced in step 9 are a major source of evidence for such compliance activities - they give the auditors something to test. Undertake corrective actions - to improve the ISMS and address risks. The “Plan-Do-Check-Act” Deming cycle is central to the ‘management system’ part of ISMS and should result in continuous alignment between business requirements, risks and capabilities for information security. As with quality management systems, the idea is to give management a means of controlling information security management processes such that they can be continually monitored and improved, not least because perfect security is an unattainable goal in any real world situation. Conduct a pre-certification assessment - when the ISMS has stabilized, a certification body or other trusted, competent and independent advisor is invited by management to check whether the ISMS is functioning correctly. This is largely a compliance assessment but should ideally incorporate some independent review of the scope, the SOA and RTP to make sure that nothing important has been missed out of the ISMS, especially as the business situation and information security risks have probably changed in the months or years that it will have taken to implement the ISMS. It is a golden opportunity for your organization to identify and tie up any remaining loose ends before the actual certification audit. It’s also a good low-impact way to get to know the auditors. Certification audit - when management is happy that ISMS is stable and effective, they select and invite an accredited certification body to assess and hopefully certify that the ISMS complies fully with ISO/IEC 27001. The auditors will check evidence such as the SOA, RTP, operational artifacts etc. and will attempt to confirm that the ISMS (a) is suitable and sufficient to meet the organization’s information security requirements in theory i.e. it is correctly specified; and (b) actually meets the requirements in practice i.e. it is operating as specified. Party party - seriously, when it’s all over, celebrate your success. You’ve earned it! More than that, your ISO/IEC 27001 certificate is a valuable asset. The organization should be proud of what it has achieved, knowing of course that information security is never really “done”. With your certified ISMS operating normally, take a good look at the information security arrangements in place at your supply chain: are your suppliers, partners and customers also certified? Are they certifiable? Do they need your encouragement? If you haven’t already done so, please join the ISO27k Implementers’ Forum to share your experience with others who are in the process.
Alternatively, here’s another, simpler version of the process overview flowchart.
Implementation tip: genuine management support is the sine qua non. Time invested in explaining to managers what the ISMS is and more importantly how it benefits the organization is time well spent. At the same time, listen hard to find out what managers really need from information security and pick up opportunities for strategic alignment. If the ISMS supports or enables key business objectives, it is less likely to be seen as an impediment to progress.
Q: “I have been asked to work on ISO 27001, because my company is looking to be certified against ISO 27001. I do not how to start, how to write documentations, because I have not done that before. I have gone through ISO 27002 which is general rules, but I can not translate that to match what I have at work (real life). Any guide or advice?”
A: There is no definitive answer for your question: 'it all depends' is the classic consulting recommendation. The diagram and outline above should give you a reasonable idea of the overall process and the key documents that will be required or produced. However, the details vary in each organization. Take a look at the ISO27k Toolkit for more free advice.
If you already have a security policy manual, for instance, the specified controls may well address most of the risks in scope of ISO/IEC 27002, in which case you need to work more on the implementation and compliance side, having reviewed the manual for currency and suitability.
If your organization is just setting out on the path towards having an ISMS, you will probably need to start working on management understanding in order to justify the financial expense and changes associated with the program of work ahead - i.e. prepare your plan, business case and/or strategy. Think about it, document it, circulate it for comment and build executive support. Deal with the inevitable objections as best you can, don't just ignore them.
How will you obtain sufficient dedicated budget to achieve what needs to be done and how will you deal with the probable shortfall between ideal and actual funding? If you define your strategy as an investment proposal or business case, you will need to track projected and actual costs and benefits to demonstrate the net value of the program. This implies designing and implementing a comprehensive suite of information security metrics, either up-front or behind the scenes as the program continues. Don’t underestimate the difficulties of generating helpful and informative metrics, nor the practical problems of estimating the Return On Investment for information security or indeed other risk management activities.
Implementation tip: get some professional help with the program management, project planning etc. unless you are a wizard with these things. Take suggestions from sources within the organization: most people are flattered simply to be asked their professional opinion and it pays to re-use existing processes, forms etc. where possible if information security is to become truly embedded in the corporate culture.
Q: “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/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. It is conceivable that one or more of them may be dropped when ISO/IEC 27001 and 27002 are revised. Concentrate on their primary purpose, which is to document the links between information security risks, control objectives and controls.
Q: “I would like to see 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 RTP 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 consquential damages/losses including incident investigation and cleanup costs.
Risk treatments: mitigate the risk primarily through antivirus controls, plus network, system and data logial 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. 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 security 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 ....
|
|
|
|
|
|
Q: “In order to conduct a risk assessment, we need a list of all of our ‘information assets’. What kinds of things should be included in the list?”
A: You need to start with a reasonably comprehensive inventory of your information assets. Information assets may for example be categorized under the following generic headings:
Pure/intangible information assets (content, data, knowledge, expertise); Software assets (commercial, bespoke or internal/proprietary applications, middleware, operating systems etc.); Physical IT assets (computers, routers, disks etc.); IT service assets - see ITIL or ISO 20000; Human information assets (“people are our greatest assets” is actually true when considering their skills, expertise and unwritten knowledge).
The classification is based on a list originally submitted to the ISO27k Implementers’ Forum. A much more comprehensive version of this list is now available in the free ISO27k Toolkit.
Implementation tip: if you have a reasonable contingency planning process in operation, its list or inventory of critical information assets is probably a decent starting point for the ISMS. It’s a fair bet that systems and functions supporting processes that have been designated business-critical are themselves business-critical and therefore deserve adequate security. Remember that it is better to avoid or avert disaster than recover from it!
Q: “Should the risk assessment process cover all our information assets?”
A: It's probably too much work to risk-analyze everything in depth so consider instead a two-phase process:
A broad but shallow/high-level risk assessment to categorize all your information assets and distinguish those that deserve more in-depth risk analysis from those that will be covered by baseline information security controls; A detailed risk analysis on individual higher-risk assets or groups of related assets to tease out the specific supra-baseline control requirements.
Document “everything important” including management decisions about the categorization process. There’s more advice on inventories above.
Implementation tip: to avoid analysis paralysis (i.e. seeking to inventory and risk assess absolutely every information asset and becoming grid-locked in that part of the process), remember that information is a fluid asset that changes all the time. Even if you were theoretically able to cover absolutely everything today, the position would be slightly different tomorrow and substantially different within a few weeks, months or years. Therefore it is perfectly acceptable to move ahead with an inventory that is “good enough for now” provided that the ISMS incorporates review and update processes as part of the continuous improvement.
Q: “What will be covered in our security policy?”
A: It’s up to you - well, strictly speaking, it's up to your management. See section 5 of ISO/IEC 27002 for a decent outline of what the policy should cover, as a minimum.
My personal preference is for a comprehensive security policy manual following the structure of ISO/IEC 27002 and supported by technical standards (e.g. “Baseline security standard for Windows 2003”), procedures, guidelines and other security awareness materials:
I find the 39 control objectives ISO/IEC 27002 make an excellent comprehensive yet succinct set of policy axioms, albeit with the wording adapted to reflect what management actually wants to achieve in relation to the organization’s business objectives. Taken together, perhaps with the addition of even higher-level principles (e.g. the principles of least privilege and defense-in-depth - there are just a handful) and maybe a senior management statement of support for the ISMS, the 39 axioms comprise a useful ‘overarching security policy statement’ that summarizes and forms a solid basis for the entire policy suite.
Two styles of information security policies are common:
Individual policies covering specific security issues such as “Email security policy” and “Network access control policy”. Typically these are quite formally worded and define 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. A comprehensive policy manual containing succinct policy statements reflecting the whole of ISO/IEC 27002, with numerous embedded cross-references between related policy statements and to related axioms, standards, procedures and guidelines. The manual functions as a master index for the entire policy suite, which helps avoid overlaps, gaps and (worst of all) conflicts.
Many organizations use both styles of policy.
The axioms, if not the principles and detailed policies, should be formally reviewed and mandated by senior management to endorse 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 CIO and her peers: 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?).
Finally, the whole policy suite should be put online on the corporate intranet, ideally through a dedicated security policy management system or wiki, for two good reasons:
The online set becomes the definitive reference - no more wondering about whether printed policies are still current or have been superseded. Other online policies should be ruthlessly hunted down and vigorously eliminated; Everyone can refer to the policies etc. easily, cross-referencing between them or to/from other policies etc. using hyperlinks to the respective URLs.
The next level down from policies usually involves security standards for specific technical platforms and situations. The Security Technical Implementation Guides (STIGs) from NIST, NSA and DISA/DoD form an excellent basis for corporate standards, along with technical security guides available directly from operating system and other software vendors. A compilation of STIGs plus the associated checklists and scripts is now available as a downloadable ISO CD image (261 Mb!) covering: Active Directory, application security, biometrics, database security, desktop applications, DNS, DSN (Defense Switched Network), enclave security, network infrastructure, Secure Remote Computing (SRC), Sharing Peripherals Across the Network (SPAN), UNIX & Linux & various flavours of Windows, VoIP, Web server and wireless networking.
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.
Q: “Will the security controls we have already implemented be sufficient for the final ISO 27001 certification?”
A: Unlikely, unless your organization already has a full suite of mature best practice security controls, supporting a comprehensive ISMS! Controls already in place won’t be wasted but (in my experience) will probably need improvements, most likely documentation for a start and probably some extensions to cover the whole breadth of ISO/IEC 27001 or ISO/IEC 27002. Identifying and initiating any necessary security improvements is the first step towards a true self-sustaining ISMS. This process will eventually become a routine part of your ISMS.
Implementation tip: look for alignment between internally-driven information security requirements and those imposed by compliance obligations such as SOX, PCI DSS, privacy laws etc.
Q: “What documents are normally part of an ISMS?”
A: Please visit our ISO27k Toolkit page for a checklist of typical ISMS documents and examples/samples and a paper describing the documents mandated by ISO/IEC 27001. We, the members of the ISO27k Implementers’ Forum, are working to produce a more comprehensive suite of samples/examples of each type of document. If you own materials that you are willing to donate to the cause, please get in touch. Thank you.
Q: “What format and style is appropriate for ISMS documentation?”
A: I would suggest putting most of your ISMS documentation online on the corporate intranet. There are several advantages to using the intranet:
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 refer to your materials but link to them in their own policies, procedures etc. (and vice versa of course!). 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). 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 what the intranet ISMS says is the current, live, version. You may like to have a separate 'trial' or 'draft' area to expose proposed changes for feedback, but make sure that area is easily identified as such e.g. with a different colored page background.
There are some drawbacks though:
You need the skills and tools to design, prepare, publish and maintain the website, or at least easy access to someone who does that. 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 OK to have fun too, using more creative security awareness materials such as quizzes, crosswords and prize draw competitions.
Implementation tip: it definitely helps to have a consistent style/format for each type of material, and even better some consistent elements on all of them to bind them into a coherent suite. Do you have an ISMS logo, perhaps, with which to ‘brand’ the documentation and security awareness materials?
Q: “Is control X mandatory [for various values of X]?”
A: This kind of question comes up all the time on the ISO27k Implementers’ Forum, hence the reason it qualifies for this FAQ. To save further bandwidth on the Forum, please select one of the following answers:
Yes, you need X because it is a basic security control that everyone needs. You'd be silly/negligent/risking the farm not to have it. No, X is not needed because we don't have it, therefore we consider it neither good practice nor best practice nor recommended. That depends - I'm a consultant with lots of letters after my name but you'd have to pay me $$$$ to answer your question. No, X is unnecessary because it is more costly than the incidents it prevents. Unless we are really unlucky anyway. Do ya feel lucky, punk? You tell me: have you assessed the information security risks and identified a troubling risk that control X might mitigate? Have you decided that it would be better to implement X than some other risk treatment (avoid the risk, transfer the risk, accept the risk)? Is X the most cost-effective control in this situation? Does X adequately mitigate the risk and, ideally, others too yet without making the situation worse through additional complexity, procurement/management costs or whatever? Is X feasible? Yes because NIST/COBIT/SOX/a little bird says so. Yes. No. Yes because it is "mandatory", according to [insert favorite authority figure here]. No because it is "optional" and/or was not explicitly listed in black and white as absolutely mandatory by [insert favorite authority figure here too]. Yes because it's the law [in country Y]. Only if your policies, plans, strategies, technical architecture, or internal standards say so. Yes if there is a positive ROSI [Return On Security Investment], no if the ROSI is negative or if someone has seeded "reasonable doubt" or if there is something sexier on management's agenda this afternoon. Yes, absolutely - I am a vendor selling X. X is all you need. X is better than sliced bread. I'd sell both my kidneys to buy X ... Yes because we will get a bad audit report and/or grief from HQ if we do not have X. Not necessarily now but it will definitely be required in the future. Trust me. No because we cannot afford it at the moment. No because if you have it, then we have to have it too, else we will appear behind the times and that is BAD. Yes because we have it and you are Behind The Times. Do you even have to ask? Doh!
OK OK enough already. While there may be an element of truth in all of them, the most correct answer is (arguably) #5. You will no doubt have spotted that it is the longest answer and consists of a load more questions. If they are too hard for you, simply choose between answers #7 and #8, or consider the following advice.
The ISMS specified in ISO/IEC 27001 allows management to decide which information security controls are necessary for the organization, based on their assessment of the information security risks. If they have done the analysis, understood the risks and made a management decision, it is their right.
However, any competent ISMS auditor would probably be concerned at the nature of the risk analysis that led to the decision to exclude commonplace controls, and would want to explore the documentation around it for a start. This is the classic auditor’s “show me” situation!
The basic rationale, from an audit point of view, is that yes, management can decide not to apply any of the recommended information security controls in Annex A of 27001 or the whole of 27002 that most other organizations consider essential provided they can justify that decision on a rational basis. If the risk analysis and/or their reasoning and decision making processes were fundamentally flawed, the auditor would have grounds to complain and (in the case of a certification audit) perhaps refuse to certify, although even this outcome is not absolutely certain.
This is a tricky issue for ISO27k that extends well beyond such obvious examples as excluding incident management or continuity planning controls. The key aim of ISO27k is to ensure that management designs and implements a solid and reliable management system in order to manage and improve information security on an ongoing basis (including the periods between audits!) and over time get as close as reasonably possible to a state of security. That target security state, however, cannot reasonably be defined prescriptively in an international standard that is meant to apply to all types and sizes of organization. Controls that are entirely appropriate, if not “essential” for some organizations would be inappropriate and perhaps harmful (i.e. the costs would outweigh the business benefits) to others. Certain controls may be inappropriate today given the current state of maturity of the organization, but entirely appropriate n a few months or years from now. The ISO27k approach, therefore, stops short of mandating specific information security controls but does mandate a series of management controls comprising the management system. For these reasons, 27001 is the certification standard, not 27002.
Implementation tip: joking aside, this question betrays a lack of understanding of the ISO27k approach to Life, The Universe and Everything. Information security requirements are context dependent, hence the control requirements have to be determined by the organization’s management examining its risks as best it can, determining its best options for dealing with whatever risks it identifies, and making investment decisions based on the phases of the moon, lucky crystals, ley lines or whatever. IF management decides some commonplace information security controls are simply not required or justified in their circumstances, they should prepare to be challenged on this decision and consider their rational very carefully. In many cases, they may decide to make a limited implementation instead, which largely avoids the issue.
Q: “Is it necessary to appoint an Information Security Manager to implement and run an ISMS? If so, what qualifications should the ISM possess?”
A: Yes, in practice an ISMS needs a nominated Information Security Manager (ISM), Chief Information Security Officer (CISO) or similar to plan, implement, run and maintain it, although the ISO27k standards don’t exactly say it that clearly. A very rough rule-of-thumb suggests around 1% of employees should work in information security (more in any organization for which information security is a critical issue). Small organizations may not have a dedicated ISM but may assign the corresponding responsibilities to the IT Manager or someone else as a part-time duty. Organizations of all sizes are encouraged to utilize independent experts (consultants, contractors, auditors etc.) as necessary, both for the additional pairs of hands and more importantly their brains and experience.
Here are some generic suggestions of suitable qualities, qualifications and experience levels for an ISM/CISO (based on a list initially submitted to the ISO27k Implementers’ Forum by Wawet):
Must haves:
Personal integrity (#1 requirement), high ethical standards, basically beyond reproach and entirely trustworthy Passion for information security and IT risk management, with a professional track record in the field typically evidenced by certifications such as CISSP or CISM plus hands-on experience running an ISMS of some form (ideally to ISO27k) Can confidently explain what CIA really means and why this is so important to the organization
Highly recommended:
Professional IT background (e.g. former IT system/network administrator, analyst, developer, project manager, operations, IT disaster recovery/contingency planning) Project and personnel management experience, good at scheduling and managing time, people, budgets, tasks etc. and working to dynamic priorities Excellent communication skills, both written and oral, able to demonstrate the ability to write well and present confidently (perhaps as part of the interview process) Business management experience & expertise, ideally MBA material, with knowledge of the organization’s business situation, strategies and goals IT audit skills (e.g. able to assess risks, ask the right questions and get to the bottom of things, plus write and present formal management reports), ideally qualified to CISA or equivalent Process- and quality-oriented (demonstrated ability to identify and deliver continuous process improvements, knowledge/experience of ISO 9000 and ITIL/ISO 20000) plus people skills (e.g. generally gets along with all types of person yet self-confident and assertive enough to lay down the law when required without being aggressive) Highly organized, structured and self-motivated, “driven” even Negotiation skills Pragmatic rather than overtly academic, theoretical or idealistic outlook Works well under stress induced by conflicting priorities, frequent “interrupts”, limited resources, unreasonable/unrealistic expectations and often negative perceptions about the value and role of information security Knowledge of ISO27k and related standards, methods etc. Can explain the differences between threats, vulnerabilities and impacts |
