This section of the ISO27k FAQ helps you make a start on your ISO27k implementation, including governance aspects such as scoping the ISMS and planning the project.

• How do we engage management?
• Should we aim for ISO27k alignment, conformance/conformity, compliance or certification?
• How long will it take us to implement an ISMS?
• Is it necessary to appoint an Information Security Manager?
• Should our CISO report to Quality, IT Operations or the GM?
• Must we involve members from all parts of the business in the ISMS?
• How do we define the scope of our ISMS?
• If we limit the scope of our ISMS, how do we treat out-of-scope risks?
• Why do some organisations de-scope their ISMSs?
• How do we compile an inventory of our information assets?
• What should we include in our information asset inventory?
• Do we need to risk assess all our information assets?
• Do we really need to implement control X?
• Can you help me make sense of the generic ISO27k recommendations?

FAQ: “How do we engage our management, persuading them that the ISMS program has to be established?”

A: A good place to start is to work on raising awareness at the management levels, as high as you can go. There are several ways of actually doing that, such as:

• Directly working with your senior security contacts/friends, including colleagues in risk, compliance, legal, IT, facilities, Internal Audit etc. (particularly any business units that have a clear and pressing need for information security e.g. R&D functions with pre-patent information; S&M functions with customer credit card info; HR with personal data on personnel ...): they (should!) already have some awareness of information security but may be unfamiliar with ISO27k and ISMS concepts, and may have the rather narrow IT security perspective;
• Drawing up strategies and plans for the ISMS, linked as explicitly as you can to corporate strategies and plans. The closer and more obvious those linkages, the harder it will be for management to resist the need for security in support of the business. Work hard at this - it will pay off big time in the end, trust me;
• Work with Finance on business plans, cost-benefit analysis, budget proposals or whatever it takes to get sufficient resources for the ISMS, both initially at the design, development or implementation phases and long-term for ongoing security operations and maintenance of the ISMS. Without sufficient resources, the ISMS is doomed. This is largely a matter of prioritisation relative to other business activities and initiatives, so you will have to negotiate timing and funding in the business context - which means you need an appreciation of what else is going on;
• Mapping communications and power relationships in your management levels i.e. the informal structure chart for management (not [just] the formal organogram that HR puts out, but the one showing who really wears the trousers, who they consult/rely on - possibly even a RACI-type chart and psychometrics if you have the knowledge, energy and access). This can help you understand your audience/customers better, communicate more effectively, and develop an uncanny ability to get your way. It can also help you identify and deal with any blockers. Validate your findings and assumptions with one or more friendly managers;
• Working with your team i.e. the information security people, help-deskers, security architects and others to formulate plans and approaches, and exploit their business contacts where possible. Implementing a formal ISMS is a change management activity for the team as a whole - not something for the lone ranger!;
• Launching some basic strategic or management-level metrics, such as maturity scores against the recommendations in ISO/IEC 27001 and ISO/IEC 27002, section by section in only as much detail as you need to make the numbers meaningful to management;
• Finding and exploiting opportunities to tackle security pinch-points, longstanding security issues that have caused problems for the business. If you can resolve some of these in the business's favour, you will make friends. Make sure to take notes and use these situations as examples illustrating the new approach you are taking;
• Setting up regular briefing sessions with relevant managers, leading in to and supplemented by ad-hoc security briefings and workshops for management meetings (including the ISMS Management Reviews formally required by ISO/IEC 27001 clause 9.3), committees, teams or groups on security and risk-related matters (e.g. risk and business continuity workshops). Engagement is the underlying aim, which means both informing them and drawing them along, motivating them to support your efforts and helping them with whatever they/the business needs from information security (“you scratch my back and I’ll scratch yours”);
• Tackling any outstanding audit issues of relevance to information security, and starting to build up your 'stock' of security anecdotes, incidents, policies, procedures, briefings etc., leading in to a full-on security awareness program when the time is ripe;
• Working with independent security consultants or contacts, perhaps starting by using external (and internal?) experts as invited speakers for management events. Help them find and speak on topics of current interest to management, and so set managers thinking about security stuff. If appropriate, keep the speakers on for a few hours or days to do some actual work as well! They can often help you find and exploit good relationships within the management hierarchy, and often have access to higher levels purely by dint of being independent experts. Just be careful to manage their expectations i.e. you may not be keen to have managers employ them independently of your initiatives.

Implementation tip: a bit of creative or lateral thinking should come up with a bunch of ideas of your own along these lines, from which to select the few that you are actually going to pursue this month. Don’t try to do too much at once or nothing will get the attention it requires. Focus! It takes planning, preparation and prioritisation to exploit the techniques that work best in your organisation, and to spot and respond to the opportunities that will arise in due course as your ISMS is launched and gradually matures.

Top

FAQ: “Should we aim for ISO27k alignment, conformity, conformance, compliance or certification?”

A: Yes. Next question?

Well OK, I guess you want some advice on which way to go, so here are some of the pros and cons:

• Alignment could mean almost anything. It implies that the organisation has adopted and is using [one or more of] the ISO27k standards but equally it may be that it merely intends to do so, management is sympathetic to the general concept, or someone quite likes the idea in theory. Alignment is a basic starting point, achievable at little cost for any organisation that takes information security seriously. However, the ‘general intent’ bit implies a fair amount of management discretion about which specific parts of the ISO27k set are going to be used, and more importantly to what extent they are to be adopted. Alignment gives little if any assurance to third parties about the organisation’s information risk, security or privacy status. It’s practically meaningless without further information (for example which ISO27k standards have been implemented, and to what extent? Is the organisation merely planning to adopt the ISO27k standards at some future point, or has it already done so? Does it actually have a working ISMS??).
• Conformity/conformance suggests the presence of an ISMS that satisfies the requirements of ISO/IEC 27001. This typically involves the organisation implementing an ISMS of some form (ideally using ISO/IEC 27001) along with a suite of information security controls (typically, but not necessarily, those from ISO/IEC 27002). The value of a self-assertion depends largely on whether the organisation is both competent at information risk and security management, and trustworthy.  [For some reason “conformance” is a deprecated term within ISO standards whereas “conformity” is preferred.]
• Compliance implies fulfillment of mandatory obligations as imposed by laws, regulations or contracts. It might refer to the main-body clauses of ISO/IEC 27001 ... or something else. Again, the value is uncertain without more information plus assurance.
• Certification normally means formal certification of the organisation’s ISMS against ISO/IEC 27001 by a proiperly accredited certification body. This in turn means that the organisation’s ISMS has been independently audited by competent ISMS certification auditors to confirm that the management system fulfills all the mandatory requirements of ISO/IEC 27001 in terms of its structure/design, and there is evidence that it is operating correctly. Nevertheless, it is a moot point as to whether this means the organisation is actually secure in any real sense since certification auditors need not necessarily probe too deeply into the presence, design and/or operation of the information security controls: their primary concern is to validate the management system rather than test the information security. That said, there’s a fighting chance that a ISMS which complies fully with ISO/IEC 27001 is in fact supported by a reasonably comprehensive and effective suite of information security controls addressing its information risks, and that the organisation is proactively managing and continually improving its information risk and security arrangements.

Certification of your ISMS is a laudable objective but even that is not much of a goal in itself. The real value of an ISMS is in the realisation of business benefits, primarily the reduction in number and/or severity of information security incidents, provided the cost savings outweigh the cost of the ISMS and the controls (both aspects being difficult to measure accurately). Additional business benefits stem from the reduction in information risks and increased management control over them, leading to greater confidence. The value of assuring third parties about the organisation’s information security status depends on the specific commercial situation: increasingly, organisations are being forced to become ISO27k compliant if not certified by business partners, regulators or legal obligations. It is then a matter of whether management feels it is worth the organisation becoming compliant and perhaps being certified under its own terms and timescale, or under pressure from third parties.

Implementation tip: if you are  genuinely compliant already, the incremental cost of certification is relatively low whereas the benefits business of independent assurance may be significant. Why would you not go the whole hog? If a third party merely claims or asserts compliance, it begs the obvious question: why don’t they have the certificate to prove it?

Top

FAQ: “How long will it take us to implement an ISMS?”

A: How long do you have? Here are just some of the relevant factors:

1. Level of senior management support. Definitely the #1 factor in my book, as just noted above. Affects most of the rest of this list. Itself depends on management’s understanding of what will be or is involved in the implementation, and what are the business drivers and anticipated positive outcomes for the organisation when the ISMS is in place and certified. Can be overcome to some extent by information security awareness activities, business cases, and general schmoozing, focusing specifically on these issues for the Execs and dealing positively with their concerns. Hint: it pays to work one-on-one with individual managers rather than addressing the faceless “management”.
2. Level of middle/junior management understanding and support, particularly in areas such as IT, HR, Risk Management and Legal/Compliance. Tends to follow #1 but not necessarily in dysfunctional organisations. Can also be mitigated/improved through security awareness, schmoozing etc. Make friends and influence these people by showing them how the ISMS will make their jobs easier and more effective.
3. Experience, capabilities and diligence of ISMS implementation team comprising the team leader (probably but not necessarily the Information Security Manager) plus assorted team members. Can be boosted by reading and training, plus of course this website and the ISO27k Forum. It is also worth considering targeted consultancy assistance to benefit from others' experiences (both good and bad!). Includes expertise in project and change management, and political astuteness: remember this is NOT repeat NOT a purely technical/cybersecurity project within IT!
4. Organisation's information security maturity level when starting the project, and the desired goal level when the implementation phase can be considered “finished”. Usually unstated and difficult to pin down. Worse than that, it’s a moveable feast that will shift as the project proceeds, typically because improved information risk assessment processes identify ‘risks and opportunities’ [for improvement] that weren’t even appreciated in the beginning (ah, ignorance is bliss) ...
5. The organisation’s actual/true level of information risk. This factor rather self-evidently affects the amount and quality of security controls necessary, and hence the nature of the ISMS required. A military or high-profile organisation in an intensely competitive market or highly regulated industry will probably end up with a rather different ISMS than, say, a bicycle shop.
6. Existing compliance load and experience e.g. PCI DSS, privacy, FISMA and particularly ISO 9001 or similar ISO management systems expertise within the organisation. The need for compliance with externally-imposed information security-related laws, regulations, contractual terms etc. may be driving the ISMS implementation project forwards, but equally this pressure tends to divert many of the self same resources from their ISMS implementation activities.
7. Level of understanding and support for the ISMS project in related assurance functions such as IT, risk management, finance, HR, legal/compliance, physical security, audit, plus key business functions (i.e. the political and commercial powerhouses of the organisation). Make no mistake: if your ISMS does not have - or at least if the implementation project cannot generate - sufficient genuine support from these functions, you are stuffed. Ignore this factor at your peril.
8. Strategic fit between the putative ISMS claimed/actual benefits and the organisation's stated/actual business goals. Finding, creating and/or making explicit the points of alignment (such as obviously shared objectives etc.) can be the key both to surmounting any speed bumps on the road to ISMS nirvana and generating ISMS success metrics that management simply cannot ignore.
9. Number and power of blockers or barriers - generally this refers to powerful people within the organisation (not necessarily managers!) but sometimes technical and/or commercial barriers can threaten to derail a project. See #1 and #8.
10. Resourcing levels (not just the core ISMS implementation project team!), plus the level of other competing initiatives and activities. This includes $$$, skilled people, consultants etc., and I mean the actual level of effort expended on the project-related activities, not just the budgeted or committed levels. It’s no good ‘trying to make the time for this’.
11. Scope of the ISMS e.g. business units to be included, supplier relations included or excluded. Counter-intuitively, perhaps, scope is not a primary factor since a basic level of effort is always required to design and implement the management system, regardless of how widely it is applied throughout the organisation. Scoping the ISMS too narrowly-scoped may actually create more work for the implementation team as well as unduly constraining its business value!
12. String length :-)

Implementation tip: check out the ISMS implementation project estimator - a simplistic (crude)  spreadsheet provided in the ISO27k Toolkit. If it turns out to be wildly inaccurate, we would welcome your assistance to improve it for future users.

Top

FAQ: “Is it necessary to appoint an Information Security Manager for our ISMS? If so, what qualifications should he/she possess?”

A: Yes, in practice an ISMS needs someone such as an Information Security Manager, Chief Information Security Officer or similar leader 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 that a minimum of about 1% of an organisation’s total employees should work purely in information security (a greater proportion in any organisation for which information is a vital corporate asset hence information security is a critical business issue). Small organisations may not have the luxury of a dedicated full-time ISM/CISO but may assign the corresponding responsibilities to the IT Manager or someone else as a part-time duty. Organisations of all sizes are encouraged to utilise independent experts (consultants, contractors, auditors, or even managed service providers specializing in compliance, communications, collaboration and continuity) as necessary, both for the additional pairs of hands and more importantly their brains, expertise 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 Forum by Wawet):

Must haves:

• Personal integrity (#1 requirement), high ethical standards, basically beyond reproach and entirely trustworthy
• Passion for information risk and security 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 one certified to ISO/IEC 27001)
• Can competently and confidently explain what “CIA“ means and why this is so important to the organisation

Highly recommended:

• Professional IT or similar technical background (e.g. former IT system/network administrator, analyst, developer, project manager, operations, IT disaster recovery/contingency planner/manager)
• 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, evangelically even (check in the interview process)
• Business management experience & expertise, ideally MBA material, with knowledge of the organisation’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
• Hands-on experience of ISMS design and implementation (e.g. actively contributing member of the ISO27k Forum!)
• 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
• Good knowledge of, and ideally implementation experience with, the ISO27k standards
• Can competently and confidently explain the differences between threats, vulnerabilities and impacts, giving relevant examples

Nice to haves:

• Knowledge of COBIT, FISMA, SOX, PCI-DSS and other information security, governance, risk management or related standard, methods, laws, regulations etc.
• Able to understand and discuss the pros and cons of quantitative versus qualitative risk analysis methods as applied to information security
• Experience of designing and delivering successful education, training and/or awareness activities (e.g. trainers, teachers, help desk workers etc.)
• Experience of security administration, security architecture, physical security, risk management, compliance etc.
• Information security and/or IT audit or consultancy experience with a variety of organisations, and the accumulated wisdom that often comes with a long grey beard

Implementation tip: good, competent, experienced information security professionals are hard to find. If you have a potential ISM already on the payroll but he/she lacks sufficient experience or qualifications to carry the whole job right now, consider employing a consultant to assist with the ISMS implementation project but give them the specific brief to mentor/train the proto-ISM and gradually hand over the reins. Completing a significant ISMS implementation is a fabulous learning and career development opportunity in its own right!

Top

 FAQ: “Should our CISO report to Quality, be part of the IT Operations department or report directly to the General Manager of the business unit?”

A: The question hints at a governance issue, maybe, or a naive misunderstanding. Generally speaking, the Chief Information Security Officer is, by definition, part of the C-suite comprised of all the CxOs - CEO, CIO, CTO, CFO, CRO, C3PO etc., in other words the most senior level of executive managers in the organisation. The reason is that the organisation as a whole is dependent on information, which therefore requires securing. The CISO’s purview, then, extends across the entire organisation, while the risks associated with information are such that information security is a strategic business matter, requiring senior management involvement.

“Quality” in the modern sense of quality assurance is also an issue that affects the entire organisation and has strategic aspects ... but quality and information security are not closely aligned. Squeezing them into the same function suggests than neither is being taken seriously.

IT Operations is generally a function or team within the IT Department with an important role providing internal IT services, but that’s only part of the information risk and security landscape. What about knowledge management, intellectual property protection, trade secrets, privacy compliance, business continuity, physical security for information, commercial cloud services and other concerns? This smacks of today’s myopic focus on “cybersecurity”, meaning security for IT systems, networks and computer data: those are indeed an important part of the risk and security portfolio, but not all. Ignore the rest at your peril.

The business unit GM may be the most senior executive manager in that part of the organisation, or a non-specialist manager, or even a nondescript middle manager depending on how the role is defined. The fact that the questioner referred to the business unit GM implies that there may be other GMs in other business units (or divisions, sites etc.), and probably a senior executive management team for the entire organisation or group ... which would be the ideal place for the CISO’s strategic perspective across the whole lot.

organisational structures and reporting lines, plus the objectives for all senior positions, are a matter for senior management, especially in such a critical area as information risk and security. This is part of corporate governance, a key responsibility and in fact accountability for senior management: if things ever go badly wrong (e.g. a serious compliance incident such as a privacy breach, or a business-threatening hack, ransomware infection, fraud or whatever), hard questions will be asked of senior management. A response along the lines of “We had no idea: this was delegated to some relatively junior part of the organisation and we don’t trouble ourselves with such trivia” is distinctly lame, unconvincing and unprofessional.

Implementation tip: work with everyone in the C-suite (particularly those in areas such as IT, risk, security, compliance and HR) first to help them understand the issues, and then come to an agreement on the role, objectives, seniority, reporting lines, alliances etc. if a CISO is the right approach for your organisation. It makes little sense to work on any one aspect without also considering the rest in the corporate governance context.

Top

FAQ: “When creating an ISMS, is it absolutely necessary to involve non-IT parts of the business (business owners, Finance, Legal, HR etc.)?”

A: The short answer is YES!

ISO27k is most 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 many forms of proprietary knowledge. What's more, the average IT department does not own and hence lacks full and total control of all the computer data, systems and/or networks in the entire organisation, so limiting the scope of the ISMS to IT would not necessarily protect all the data to the same degree.

ISO/IEC 27001 is a deceptively simple and elegant standard. Designing and implementing a compliant and worthwhile ISMS is not trivial for several reasons:

• Information security is inherently complex and difficult to do well, while perfect security is practically unattainable. Whereas hackers, fraudsters and information thieves need only find a small chink in our defences, we must defend all points simultaneously, both around the perimeter and within. Most organisations have a plethora of technical platforms, applications and network connections, plus a raft of non-IT information assets to protect. We all face a range of internal and external threats, including the mundane but ubiquitous errors, accidents, equipment failures, bugs etc.
• The need for information security mirrors the use of and dependence on information, and therefore extends across the enterprise and beyond. It is not only necessary to involve representatives of the entire organisation but also business partners, particularly where the organisation outsources critical information processes or relies on IT and telecomms services from third parties and hence has a direct interest in their security arrangements. Customers, owners, regulators and other stakeholders share similar concerns, leading to substantial governance and compliance obligations.
• Information security threats and vulnerabilities are constantly changing. As with the capital markets, this dynamism creates both risks and opportunities for the organisation, especially in competitive environments (which includes national security and government departments by the way!). Agile, security-aware organisations respond to both, but positioning information security as a business enabler is a hard sell to old-fashioned managers with outdated views.

It is possible to restrict the scope and apply the ISMS narrowly, perhaps to just the IT Department 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: 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 organisation and its stakeholders. The information owners, in turn, will call on IT, Information Security, HR, Risk, Legal/Compliance and/or third parties (such as Information, Professional Services, Internet and Cloud Service Providers) 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 risk assessment. The responsibility for security cascades naturally through the organisation but accountability sticks firmly at the top (“the buck stops here”!). This is a useful concept because those at the top generally have the budgets and influence/control to make security happen, or not. They also have the strategic vision and broad business/market knowledge to determine the value and hence amount of protection needed for business information.

Top

FAQ: How do we define the scope of our ISMS?

A: First decide the boundaries (i.e. which parts of your organisation are going to be subject to the ISMS and which parts if any are not) and applicability of the ISMS (i.e. what does the ISMS apply to and protect - usually ‘information’ or ‘information assets’), then write it down. QED.

Scoping the ISMS is an important business decision, best made by senior managers who appreciate what the ISMS is all about and understand what it does for the business. Unfortunately, however, there’s a chicken-and-egg situation here: before the ISMS is approved, designed and implemented, few senior managers are likely to have much of a clue about what the ISMS is, let alone how valuable it will be ... so it’s a very good idea to put some time and effort into explaining things in a way that make business sense. A good business case for the ISMS, for instance, will describe the approach in general terms, laying out the anticipated business benefits and the costs, and giving management various options.

Here’s a bunch of questions typically of interest to management that you might like to consider if not explicitly address in the business case and associated chats, discussions, presentations, project plans etc.:

• Why do we need an ISMS? What will it do for us? How much will it cost? How long will it take to get going? Will it consume all our information security resources?
• We’ve managed without an ISMS until now: why the change? What prompted this proposal?
• Isn’t this something that IT should be doing? What is the relevance to the rest of the organisation? Why are you even asking me to get involved?
• Don’t we have this already?
• What are our options? Do we HAVE to have an ISMS, for some reason, or is this a strategic matter? What approaches could we take? Why go down the ISO27k route instead of, say, NIST SP800-53 or PCI DSS or COBIT ... or just continuing as we are doing now?
• How deeply should we get into this? Can we scrape by with the bare minimum and still reap most of the benefits, or do we need to make a serious investment and go for broke? What else can we squeeze out of this opportunity?
• What do other departments, experts, advisors and influencers think about this? Who else is or should be involved? Are they all fully engaged with and supportive of the proposal, or might they be upset if this goes ahead? Can we cope with the changes of power and relationships that are likely to happen? Do the changes promise to be beneficial overall?
• Is this something our competitors are doing? Is there any competitive advantage in doing this? Is it more advantageous than all the other stuff we could be doing?
• What barriers are there or might there be, and what can/should we do about them?
• If we decide to go ahead, when is the best time to do it? What else will be affected? What are the risks associated with the implementation project?
• Who should run it? What kinds of skills and competencies do they need? Can we afford to divert them from other duties onto this? What about the rest of the team?
• How big should we go? Should we limit the ISMS to certain parts of the organisation, whether just for now or for good? Are they parts of the organisation that should not be included in the ISMS for various reasons (e.g. because they are too busy with other initiatives, struggling with other challenges, about to be outsourced ...)?

So you see that scoping is just one of many issues on the table.

Implementation tip: it will be easier to explain and remain within the scope if you make the formal scope statement as simple as possible e.g.:

“The Information Security Management System (ISMS) protects information belonging to, or under the custody of, ACME Inc. of Coyote Gulch, USA.”

 

- or -

 

“ACME’s Information Security Management System (ISMS) protects information assets located in or associated with ACME’s offices in Roadrunner Gulch, TX, and Coyote Valley, NM.”

 

- or -

 

“The scope of ACME’s Information Security Management System (ISMS) includes the Head Office in Roadrunner Gulch, TX, the Procurement Department in Coyote Valley, NM, and the IT function in Mumbai.”

 

- or -

“The Information Security Management System (ISMS) protects information belonging to, or under the custody of, ACME Inc. in the USA, excluding ACME locations overseas.”

 

- or even -

 

[A scope diagram such as this qualifies as “documented information” and so fulfils the requirement in ISO/IEC 27001 section 4.3. It’s OK to get creative.]

Top

FAQ: “Is it possible to restrict the scope of the ISMS to just one department or business unit, at least initially? If so, how do we treat information risks that extend across the ISMS scope boundary?”

A: Restricting the scope of the ISMS may reduce some of the effort and costs involved in the implementation but also reduces the realisable benefits, hence the net business value of the ISMS may well be lower. It is not necessarily such an easy option as it might at first appear, as the supplementary question implies.

There are several serious drawbacks to limited-scope ISMSs:

• Failure to gain the valuable business benefits of world-standard information security in the rest of the organisation.
• Discontinuities in the way information risks are managed (analysed, treated, discussed …) across the organisation.
• Failure to align information security and business strategies, missing out on the broader strategic, commercial, risk management, loss reduction, compliance, governance, management, continuous improvement and other advantages which accrue to an organisation that has information security firmly under management control.
• Likely unmanaged information risks in the rest of the organisation, and probably a distinct lack of understanding/appreciation of many of those risks if the processes of risk information security analysis, not just the ISMS, are restricted to the in-scope parts.
• Demonstrates a lack of full commitment to information security by senior management, obvious to anyone who actually bothers to look at the formal scope and SoA.
• Need to apply security controls at the perimeter of the ISMS, including some within the organisation, since the rest of the world is “outside” the ISMS and hence to some extent untrusted.

The scope boundary can be a problem since, by definition from the ISMS perspective, everything outside the scope is inherently less trustworthy than that within. Information risks within scope of the ISMS will need to be assessed and treated, including risks affecting the information flowing into or out of the scoped area and information risks that are entirely external to it. The treatments that you select to deal with these boundary and external information risks may include:

• Controlling the risks through Service Level Agreements (typically with other business units or departments of the same organisation) or contracts (with third parties) that specify certain security requirements, and perhaps technical and/or procedural controls for example a defined process for identifying and dealing with information security incidents affecting the trans-border information flows;
• Knowingly accepting the risks, albeit preferably with suitable contingency arrangements in place in case they materialise;
• Sharing the risks through some form of insurance or liabilities in contracts, SLAs, NDAs etc.;
• Avoiding the risks [by not unduly restricting the scope!].

Furthermore, while the incremental costs to extend the scope of an operating ISMS will normally be lower, there will inevitably be initial costs to plan and establish the ISMS of any size (e.g. to create a decent set of information security policies, standards, procedures and guidelines), all of which would have to be borne up-front by the initial in-scope area and may be impossible to recover from other business units/departments later.

In other words, this is a strategic investment decision for management.

That said, there are some advantages to starting small: it focuses the project and makes planning simpler. The project manager should have an easier time running the project with a smaller team (probably) and fewer stakeholders to satisfy. It may be a worthwhile learning opportunity, a chance to build skills and gain experience before proceeding with the remainder of the organisation. It’s not all bad.

Implementation tip: rather than deliberately and consciously restricting the scope of the ISMS as you suggest, it may instead be worth talking in terms of a “pilot implementation” in whichever area/s you choose. This minor change of the wording implies that, provided it is successful, the pilot will be expanded to become a full-scope implementation ...

Top

FAQ: “Why do some organisations restrict the scope of their ISMS?”

A: There are at least 23 reasons to de-scope or constrain an ISMS to particular business units, departments, locations or whatever:

1. It’s a pilot or a starting point, a way to gain experience, see how it works and set things up in preparation for a larger implementation “at some future point”.
2. It’s a pilot or a starting point, a way to gain experience, see how it works and set things up in preparation for a larger implementation that is actually planned as part of an documented and approved business/security strategy.  (NB  Reason 1 =/= Reason 2)
3. Markedly different information risks and hence information security requirements in various parts of the organisation e.g. international businesses with conflicting legal and regulatory compliance obligations, or large organisations comprised of multiple, largely independent, companies/operating units.
4. Lack of time – there’s an urgent need to “get certified” and a certificate is all that matters right now.
5. It’s too risky to go for a full-scope implementation – “we might not pass the certification audit (because we only fully control the in-scope part)”
6. Political constraints e.g. if information security is seen by management as an IT matter, so it’s IT’s problem and IT can do what it likes so long as no one else is affected.
7. Skunk-works i.e. the in-scope area is implementing the ISMS secretly, under the radar of senior management in general, for various dubious reasons.
8. Stakeholder demands e.g. if The Minister or A Major Customer insists on certified ISO27k compliance, so ‘all thtat is required’ is the parchment.
9. Stakeholder demands e.g. if The Minister or The Owner insists, for some external (and probably ill-advised or misguided) reason, that the scope be limited.
10. Genuine budget or resourcing constraints [for legitimate reasons, not just because of arbitrary decisions by management] meaning that a narrow-scope ISMS is all that can possibly be achieved, at the moment anyway.
11. The ISMS is needed to address a specific, narrow compliance obligation such as PCI-DSS or privacy: nothing else really matters.
12. Myopia or blinkers - a fundamental lack of understanding and support from management (especially senior/powerful people) concerning the all-encompassing nature and wider value/benefits of information security, probably reflecting limited security awareness or perhaps bad experiences in the past.
13. Myopia - short-sightedness, narrow perspective, lack of ambition, inexperience, cluelessness and/or extreme naiveté by the information security professionals concerned.
14. The in-scope business unit/departments/whatever is a fully independent operating unity, just like a separate company.
15. To cut corners and give the appearance of being concerned about information security while spending the least amount possible to do so.
16. “Because everyone else does it that way” - flock-together mentality.  Baaaaaaah.
17. Brains-in-neutral - it never even occurred to anyone that the ISMS might be applicable to, and benefit, the entire organisation.
18. Because they were (wrongly?) advised to do so by some self-proclaimed expert, or possibly by an experienced consultant, professional advisor or auditor who seriously doubts the organisation needs, or is capable of implementing, a full-scope ISMS.
19. Lack of genuine commitment to information security: the ISMS is just a fad, a nice line on someone’s CV or marketing brochures.
20. Lack of foresight, vision and ambition, self-doubt, small balls.
21. Genuine management doubts about the value of the ISMS, reflecting misunderstandings and distrust in the motives of those promoting the ISMS.
22. Too many other commitments and initiatives (including other management systems?) – a change management overload and management/resourcing crisis.
23. Because the rest of the organisation already has something better, or at least a different way of managing information security, that is deemed incompatible with ISO27k.
24. Others?  People can be very creative in thinking up reasons not to implement an ISMS across the entire organisation. If only they put as much effort into implementing it!

Some of these are genuine, legitimate reasons, valid for certain limited circumstances, but many are spurious.

Implementation tip: scoping the ISMS appropriately is an important strategic decision that should be made by senior managers, for example discussing, comparing and choosing between a set of scope options. Ideally, the options should lay out the costs and benefits over the entire lifecycle of the ISMS, several years at least, to enable their pros and cons to be assessed.

Top

FAQ: “We need an inventory of our information assets. How do we do that?”

A: Errrr, are you sure? What makes you say that?

ISO/IEC 27001 does not formally demand that you have an information asset list, inventory, register or whatever: it is one of the discretionary/suggested controls listed in Annex A (A.5.9). Technically, since it is not strictly mandatory for certification i.e. specified in the main body of 27001, you could decide to break with convention and not bother with an information asset inventory at all but if so you had better be ready to explain and justify that curious decision to the certification auditors!  It begs questions such as “If you don’t even know what information assets you own or are responsible for, how can you be sure you have dealt with the associated risks?” In theory there are approaches and situations which don’t necessarily involve inventories (or lists or registers or databases ….) but it is hard to envisage realistic scenarios where such an approach would be sensible.

‘27001 A.5.9 is a brief precis of ISO/IEC 27002 control 5.9 with a page and a half of advice.

You might, for instance:

• Conduct a high level risk assessment across all your known information assets, crudely lumped together for the first run;
• Group and sort the information assets by the assessed risk levels e.g. critical, high, medium or low;
• Analyse information assets with the highest risks in more detail, perhaps breaking down the groups to get more specific;
• Systematically work your way down to the lower risk items until it’s time to re-start the cycle (e.g. an annual information risk update).

Alternatively you could :

• Draw up a schedule of risk analysis and treatment activities that addresses and reviews the critical risk items every quarter, the highs every third of a year, the mediums twice a year and the lows once a year;
• Review and update the risk categorization as relevant throughout the year during the work, and perhaps revisit it as a whole once a year to plan the following year’s work.

Or maybe:

• Start by specifying the risk levels e.g. high, medium and low, with defined criteria [assemble your buckets];
• Search out your information assets, briefly assess them and assign them to the corresponding risk level [chuck things into the appropriate buckets];
• Take a closer look at those in the medium level, and a much closer look at the highs, leaving the lows to fend for themselves [rummage through the buckets];
• Once a year revisit the risk level criteria, review the classified items for any anomalies, and decide the approach, resources etc. for the following year [hoping not to kick the bucket!].

Otherwise:

• Adopt or adapt basically the same approach used currently elsewhere in the organisation to identify, assess/analyse and treat other kinds of risks (e.g. financial, strategic, market, compliance and/or health and safety risks), with adjustments as appropriate to suit the particular needs and context of information risk.

This is not a definitive or comprehensive list of options. You might prefer variants on or combinations of the above, perhaps the Monty Python option (“And now for something completely different”).

Bear in mind that, under ISO27k, you have a lot of latitude to go with the approach that suits your specific organisation. You can design it and put it into effect, along the way generating records/documents/evidence/collateral with which the certification auditors can confirm that you have:

1. Determined a sensible approach that makes sense in your situation;
2. Followed the approach as intended - you’ve done what you set out to do; and
3. Governed and managed the entire process/approach sensibly, systematically making fine adjustments or more substantial changes if appropriate to improve the process in the light of experience (e.g. risks that turned out to be more serious or more frequent than expected, plus incidents that ‘came out of nowhere’ implying failures or weaknesses in your information risk management activities) and perhaps other changes going on in parallel (e.g. a corporate strategy to be bolder and push harder when economic conditions look promising, and to retrench and be more careful when things look bleak; or pressure from the authorities or stakeholders to be more careful in respect of certain types of information risk, asset, incident or control).

Implementation tip: as to how to do actually it, the key is to categorize or group similar information assets together. By ‘similar’, we are really getting at the information risks associated with the information assets i.e. the threats, vulnerabilities and business impacts, rather than criteria used to group them in other contexts (e.g. by platform/vendor, type, value, age, location, asset code or whatever).

For a kick start, you may find that IT, Finance, Procurement, HR or other functions already maintain lists, databases or inventories of various information assets for their own purposes such as:

• Managing and maintaining software versions, updates, patches and perhaps licenses;
• Providing software, hardware or user support;
• Doing backups;
• Configuration management;
• Network address management;
• Intellectual property management (e.g. patents, copyright, licenses);
• Accounting and auditing;
• Relationship or vendor management;
• Training; or
• For insurance purposes.

Be very careful, though, or you could easily find yourself taking on a massive burden to consolidate, rationalize, verify, update, maintain and manage disparate information inventories for the entire enterprise! Ultimately that may well be the most sensible strategic approach but don’t lose sight of your tactical, near-term goal to get an ISMS up and running. It may pay to grab useful information from other functions without (at this stage) promising to give them anything in return!

Top

FAQ: “What/how much detail should our information asset inventory include?”

A: A reasonably comprehensive inventory of your information assets would be useful for purposes such as:

• Avoiding gaps and overlaps - such as classes or items of information that everybody presumes are someone else’s concern, or conversely those sexy ones where everybody wants a piece of the action;
• Risk assessment and treatment - making sure that all information assets have been duly assessed and treated;
• Ownership and accountability - clarifying exactly who is accountable for protecting valuable assets, and ensuring that they know it;
• Prioritization - within reason, it makes sense to put more effort into protecting the most valuable and vulnerable information assets, than the relatively low-value and more robust ones. Generally speaking, it also helps to tackle the biggest information risks early-on, not least because the information security program will start on a high if it makes real inroads into the organisation’s total risk profile and knocks back the things that keep management and other stakeholders awake at night;
• Asset management and exploitation - for organisations that revolve around intellectual property, the total value of information assets can far exceed the value of all other corporate assets combined, so of course information needs to be carefully managed. There may be accounting and other business or strategic reasons also, such as valuing the organisation for mergers and acquisitions, or to negotiate better rates with the banks and other lenders;
• Staying on top of significant changes - for instance recognizing when new classes or types of information asset come into being, or when values or risks change markedly as a result of business activities or substantive changes in the organisation’s situation.

Building, maintaining, using and managing the information asset inventory is one of the capabilities a mature ISMS is likely to incorporate, but it may pay to start at a simpler, more basic level and let things gradually develop and mature from there over, say, a year or two.

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, cables, UPSs etc.);
• IT service assets - see ITIL or ISO 20000 - or more broadly information process-related assets including business relationships with service providers such as your Internet service, cloud service and web site hosting providers.
• Human information assets (“people are our greatest assets” is literally true considering the value of their abilities, skills, expertise and the wealth of unwritten knowledge and understanding known as experience and wisdom).

[That classification is based on a list originally submitted to the ISO27k Forum. A more comprehensive version of this list is available in the ISO27k Toolkit.]

Don’t worry about needing a ‘complete’ inventory before you kick off: you can make a start on risk assessment almost as soon as you have identified the first few items, provided you are prepared to revisit them later on in the light of additional knowledge from assessing other assets. You will be revising assessments periodically in any case once the ISMS is running smoothly.

Another approach involves starting with the organisation’s key information resources - the things that are clearly crucial to the organisation’s ongoing business and survival. Disney’s brand and intellectual property, for example, or the Treasury’s taxpayers’ database. Obviously enough, security incidents involving such vital information assets are likely to have massive impacts on the organisation, hence the risks are likely to be highly significant. However, the devil may be in the details: maybe the CEO’s laptop containing all the company’s strategic plans is highly vulnerable to being stolen by a competitor. The capital value/replacement cost of the PC may be negligible, but the information it contains may be (to coin a phrase) “priceless”.

Implementation tip: whereas you or your colleagues might have in mind the idea of compiling and maintaining an inventory all your information assets, that’s a costly and probably futile approach. Luckily, it’s not strictly necessary. A list of the most significant/valuable information assets should be enough to get you started.

Top

FAQ: “Should the risk assessment process cover all our information assets?”

A: The previous Q&A addressed a very similar point. In practice, it's probably too much work to risk-analyse everything in depth so consider instead a two-phase process:

1. A broad but shallow/high-level risk assessment to categorize your most valuable information assets and distinguish those that deserve more in-depth risk analysis from those that will be adequately covered by baseline information security controls;
2. 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 elsewhere in the FAQ.

Implementation tip: 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) by remembering 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.

Top

FAQ: “Is control X mandatory [for various values of X]?”

A: This kind of question comes up all the time on the ISO27k Forum, hence the reason it qualifies for this FAQ. To save further bandwidth on the Forum, please select one of the following answers:

1. 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.
2. No, X is not needed because we don't have it, therefore we consider it neither good practice nor best practice nor recommended.
3. That depends - I'm a consultant with lots of letters after my name but you'd have to pay me $$$$ to answer your question.
4. 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?
5. You tell me: have you assessed the information 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?
6. Yes because NIST/COBIT/SOX/a little bird says so.
7. Yes.
8. No.
9. Yes because it is “mandatory”, according to [name favourite authority figure here].
10. No because it is “optional” and/or was not explicitly listed in black and white as absolutely mandatory by [name favourite authority figure here too].
11. Yes because it's the law [in country Y].
12. Only if your policies, plans, strategies, technical architecture, or internal standards say so.
13. Yes if there is a positive 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.
14. Yes, absolutely - I am a vendor selling X. X is all you need. X is better than sliced bread. I'd gladly sell both my kidneys to buy X ...
15. Yes because we will get a bad audit report and/or grief from HQ if we do not have X.
16. Not necessarily now but it will definitely be required in the future. Trust me.
17. No because we cannot afford it at the moment.
18. No because if you have it, then we have to have it too, else we will appear behind the times and that is BAD.
19. Yes because we have it and you are Behind The Times.
20. Do you even have to ask? Doh!

OK OK enough already. While there may be elements 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 organisation, based on their assessment of the information 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 information security controls in Annex A of ISO/IEC 27001 that most other organisations 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 organisation. Controls that are entirely appropriate, if not “essential” for some organisations 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 organisation, 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, ISO/IEC 27001 is the certification standard, not ISO/IEC 27002.

Implementation tip: this question betrays a misunderstanding 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 organisation’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.

Top

FAQ: “I’m struggling to make sense of and apply ISO 27002’s generic security recommendations to my organisation. Any guide or advice?”

A: There is no definitive answer for your question: 'it all depends' is the classic non-committal consulting response because each organisation is different.

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 probably need to focus on the implementation and compliance side, having reviewed the manual for currency and suitability.

If your organisation 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. You will not regret later the time you spend now making friends in senior management.

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: as well as drawing on ISO27k expertise, get professional help with the program management, project planning etc. unless you are a wizard with these things. Liaise with experts within the organisation: 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.

Top

< Previous FAQ section   FAQ index   Next FAQ section >