Brainstorm with your team to come up with ideas along these lines, then select the few that you are actually going to pursue this month or next. Focus! Learn as you go!

Start by raising management's awareness. Collaborate with internal contacts, especially in risk management, legal/compliance and IT departments, and demonstrate how the ISMS supports business strategies.  

Secure adequate resources by working with finance and understanding business priorities.  

Map management relationships to tailor communication and identify blockers.  

Engage your team, use metrics to show progress, and resolve existing security issues.  

Provide regular briefings and workshops, address audit findings, and expand the security awareness program to the rest of the organisation.  

Consider calling in external experts for events and consultation, but manage their engagements carefully to avoid becoming unduly dependent (a risk!).

Stopping short begs obvious questions: why don’t you have the certificate?  What are you hiding?

Yes!  

• Implementation: indicates you are making progress … but how much? How much further to go?  Why would you not go the whole hog i.e. certification of your ISMS?  

• Conformity: means using the ISO27k standards sensibly but, without assurance, that’s still just a claim, an assertion.

• Certification: formal certification by a properly-accredited conformity assessment and certification body verifies that the ISMS fulfils all the mandatory ISO/IEC 27001 requirements. Their accreditation gives the certificate meaning and value for others. 

• Compliance: satisfying applicable mandatory legal, regulatory or contractual obligations is non-negotiable. The ISMS can help achieve that in specific areas but is not its prime focus. The key benefit of an ISMS arises through reducing the number and severity of security incidents, getting a grip on the organisation's information risks.  Noncompliance with, say, privacy laws is the kind of business risk that management needs to tackle, head-on.

Check out the implementation project estimator - a simple spreadsheet tool provided in the ISO27k Toolkit.

The timeline varies greatly according to factors such as:

• Management support: senior and middle management buy-in is crucial.  Start here or regret it later.

• Team expertise: experience and project management skills matter, particularly for the ISMS implementation project manager/team leader and their boss.

• Security maturity: affects both the starting point and the rate of progress.  Is continual improvement a thing in your organisation, or just a dream?

• Risk profile: a community college faces markedly different challenges to a missile silo.

• Compliance and conformity: experiences and challenges make a difference.

• Cross-functional support: genuine collaboration and support from IT, HR, legal, operations and other departments can move things apace – or cause logjams if missing.

• Strategic alignment: how well does the ISMS fit business objectives and strategies?

• Obstacles: internal or external resistance or barriers will s l o w things down. 

• Resource availability: funding, personnel, priorities, commitment and attention all matter.

• ISMS scope: is the implementation enterprise-wide or just a small part?

Competent, experienced, trustworthy  information security professionals are hard to come by. A significant ISMS implementation is a fabulous learning and career development opportunity if only you can find someone suitable and willing to give it a go ... with oodles of support.

Not necessary a Chief Information Security Officer as such. Although ISO/IEC 27001 doesn't literally demand it, a manager or leader is indispensible if your ISMS is to achieve anything truly meaningful and valuable for the business, in a reasonable yet realistic timeframe.  

Here are the personal qualities, qualifications and experience ideally required:

• Personal integrity, high ethical standards, beyond reproach, entirely trustworthy;

• Clear passion and enthusiasm for information risk and security management;

• Professional technical/technological background e.g. IT, engineering;

• Project and personnel management experience;

• Excellent communication and strong negotiation skills;

• Business management experience & expertise e.g. budgeting and financial management, planning and prioritising, spotting and responding appropriately to risks and opportunities;

• Technology audit skills, awareness or experience;

• Hands-on experience with an ISMS or similar structured approach, preferably at management level but operational experience is a start; 

• Process- and quality-oriented, highly organised, structured and self-motivated - “driven” even;

• Pragmatic, adaptable, resilient and responds well to stress;

• Solid knowledge of the ISO27k standards, plus other standards, methods, laws, regulations etc.;

• Experience with training and awareness, security administration, security architecture, physical security, risk management, compliance, conformity etc. - more than cybersecurity!

An SME may have little option but to settle for a part-timer, preferably a suitable manager but a contractor, consultant or fractional CISO may suffice, at least for now - especially if the asignment explicitly includes mentoring an insider to step into their shoes.

Working with HR, help senior management understand the issues, and negotiate the role, goals/objectives, seniority, reporting lines etc. to suit your organisational context.

This is patently a corporate governance matter.  

They should preferably be part of the C-suite or executive team, at the highest level of management. Information security is a strategic, organisation-wide, business concern, not just a technology issue. 

Reporting to a lower-level function such as the Head of IT limits their scope, influence, independence and capability to manage the organisation's information risks.

Senior management is accountable for sound risk management, including information risk and security management. Delegating this important task to too junior a level would be irresponsible.

Rather than deliberately restricting the ISMS scope, consider a “pilot implementation”. If successful, build on the pilot by expanding the scope wherever it makes the most sense for the business.

ISO27k is about information security management systems.  While IT or cybersecurity is essential, ISO27k covers risks to all forms of information including non-digital assets such as trade secrets.

Aside from the challenge of securing technologies, implementing an ISMS is tricky due to:

• Complexity: information security incidents can affect everyone who uses, depends upon information or has an interest in its protection and exploitation.  That includes business partners, customers and other stakeholders such as staff and managers, owners and regulatory authorities, using all manner of information in myriad ways.

• Dynamics: ever-changing risks require agile responses. Serious incidents can blow up seemingly out of nowhere, dramatically changing the situation ... while we cannot afford to ignore more gradual, evolutionary changes such as ever-increasing automation.

Whereas it may be possible to narrow the scope, that reduces the benefits of an enterprise-wide ISMS and creates security issues at the scope boundary, meaning additional hidden costs e.g. incorporating explicit security requirements in Service Level Agreements and contracts, along with assurance measures.

Collaborate with business colleagues on this, particularly supportive senior managers.  If you don't have any of those, yet, work on raising management's awareness and understanding first. 

Short answer: see ISO/IEC 27001 Clause 4.3 plus the rest of Clause 4.

Scoping the ISMS appropriately is an important strategic decision for the organisation that should be made by senior managers.

To help them decide, research and lay-out a strategy, business case or proposal:

• Explain the ISMS's business value (benefits less costs); 

• Discuss the strategic objectives in busines terms;

• Address management's concerns about necessity, alternative approaches or options (including the do-nothing straw-man), resourcing, priorities and hidden benefits (e.g. assurance, compliance, efficiency); 

• Consider aspects such as competitive advantage, implementation risks, required skills and resources, and the timeline (e.g. maturation through continual improvement over a number of years).

• Define the ISMS's boundaries (which parts of the organization are included or excluded) and applicability (what it protects, usually just 'information'), perhaps discussing, comparing and choosing between a set of scope options. 

Ideally, outline the costs and benefits over the entire lifecycle of the ISMS, several years at least, to enable their pros and cons to be assessed realistically.

From the conformity and business perspectives, it is perfectly acceptable to move ahead with an inventory that is “good enough for now” since the ISMS incorporates the review and update processes as part of continuous improvement.

Aside from being largely pointless, it is literally impossible to risk-analyse everything in depth ... so consider instead a multi-phase process:

1. Focus on the information assets clearly within scope of the ISMS.  You defined the scope for a reason, and this is part of it. 

2. Undertake a broad but shallow (high-level) risk assessment to categorise your most valuable in-scope information assets (the crown jewels), distinguishing those that deserve more in-depth risk analysis from those that will be adequately covered by baseline or general information security controls;

3. Conduct more detailed risk analysis on individual higher-risk assets or groups of related assets to tease out the specific security concerns and hence control requirements.

Document 'everything important' including management's criteria and decisions about the categorisation.

Avoid analysis paralysis by remembering that information is a fluid asset, continually in flux. 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.

Don't forget the variety of information assets worth protecting: some workers' business or technical knowledge and expertise, for instance, is invaluable, perhaps irreplaceable: isn't that a risk?     

Joking aside, this FAQ betrays a lack of understanding of the ISO27k way. Information security requirements are risk and context-dependent, hence the control requirements are 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.

Before this FAQ was published, this question was so frequent that, to save time and effort, we invite you to 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, share 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/NIS2/DORA/a little bird says so.

7. Yes <full stop>

8. No <fukl stop>

9. Yes because it is “mandatory”, according to [name some authority figure here].

10. No because it is “optional” and/or was not explicitly listed in black and white as absolutely mandatory by [name some 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 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. Yes because I've hears rumours that certification auditors expect or insist on it.

17. Yes if X is one of several administrative, governance, management, process or assurance control requirements specified in the main body clauses.  Aha!

18. Yes if your management has determined that X is 'necessary', and you'll be sanctioned severely if you dare to countermand the edict, policy, instruction, demand or whatever it is. 

19. Not necessarily now but it will definitely be required in the future. Trust me.

20. No because we cannot afford it at the moment.

21. No because if you have it, then we have to have it too, else we will appear behind the times and that is BAD.

22. Yes because we have it and you are Behind The Times.

23. 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, appropriate and sound answer is (arguably) #5. You will no doubt have spotted that it is the longest answer ... which poses a load more questions.

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.

Unless you are a wizard, get professional help with the ISMS implementation program management, planning and execution. Information security controls are not entirely self-evident and mistakes can be costly, terminal maybe. 

ISO/IEC 27002 expands on the succinct control summaries in ISO/IEC 27001 Annex A with about a page of explanation and guidance per information security control.

To be honest, even '27002 is succinct and leaves a lot unsaid, so to fill in the gaps we recommend asking Google, the ISO27k Forum, competent peers, perhaps even a trustworthy AI LLM (good luck finding one of those!). 

Consult specialists within or available to your organisation: most people are flattered simply to be asked their professional opinion. Furthermore, it pays to re-use (or at least check out) existing approaches, processes, tools, forms etc. where possible if information security is to become truly embedded in the corporate culture.

Take care when determining which information security controls are 'necessary' to mitigate unacceptable information risks in scope of the ISMS.  As information security professionals, we tend to want to include and manage all the security controls, but management is likely to be most concerned about a smaller subset, implying a focus that can help prioritise whatever elements are most important to the business.

Probably not. While demonstrable conformity with all the main body text of ‘27001 (the bits concerning the management system) is mandatory for certification, the controls in annex A are discretionary.  Organisations choose whichever of those security controls they deem relevant and necessary to mitigate their information risks. Additional or alternative controls may be appropriate, perhaps those from other standards, laws, regulations and good practices. It’s a flexible approach that caters for quite different organisations and risks.

Strictly speaking, certification does not even depend on the organisation fully implementing all the security controls that it has selected, so long as the management system satisfies the requirements of ISO/IEC 27001. It is presumed that a compliant ISMS will successfully ensure that the information risks are in hand and will be treated due course, and indeed this is in the organisation's interests, regardless of certification, since failing to do so implies a failure to mitigate unacceptable risks – a governance issue. However, ISO/IEC 27001 clause 4.4 prompts certification auditors to check that the ISMS is in fact operational, not merely a paper tiger.

Remember: the primary purpose of implementing an ISMS is to support or enable achievement of business objectives relating to the protection and exploitation of valuable information.  Conformity and certification are subsidiary concerns. 

Maybe not, depending on precisely what you mean by 'Annex A controls'.  Various information security controls (such as backups) are almost universally applicable: it would be very unusual (but not inconceivable) for management to determine that backups are unnecessary ... but they may well decide that the precise control wording in Annex A is not quite right. 

A.8.13 in "Information backup" says "Backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup."   It's reasonably obvious what that control wording is getting at but, studying it intently, word-by-word, like a lawyer, jobsworth auditor or anally-retentive infosec consultant, there are a number of concerns e.g.:

• 'Backup copies' is plural. A single backup copy may be adequate for some readily-replaced or recreated information.  In fact, some information is ephemeral or of negligible value, with no need for backups at all. A.8.13, as literally worded, doesn't allow for such situations.

• 'Information' is an imprecise term. 'Software' is merely an example of a type of information, and 'systems' hints at computer systems and data, implying an IT or technology context ... but what about other forms of information, such as knowledge and intellectual property: must those also be backed up?  What about information services and sources: do those need backups too?  If so, how?    

• What is the exact meaning of 'maintained' in A.8.13?  What about 'tested'?  These are also imprecise, vague terms. Might a certification auditor doggedly insist on seeing details about backup testing, test reports etc. if this control is identified as necessary in the organisation's SoA?

• 'The agreed topic-specific policy on backup' begs further questions about what it means to 'agree' a policy, what 'topic-specific' means, plus the origin and content of such a policy.

Yes, that's a peculiar and unhelpful take on a commonplace control but it illustrates the problem of describing information security in a generic standard, since so many details are context- or implementation-specific.

Management might therefore decide to rewrite the control wording to suit the organisation's particular situation, perhaps restructuring and simplifying the control statement, elaborating on certain aspects (such as applicability) or clarifying it to allow for necessary variations in practice, replacing A.8.13 with one or more 'custom controls'.  Although not explicitly stated as such, this is perfectly acceptable, in accord with ISO/IEC 27001 Clause 8 and a reasonable, sensible interpretation of the standard. 

But why stop there?  Management can legitimately determine that every Annex A control, as literally worded in the standard, is 'unnecessary', instead slecting a full set of custom controls that truly reflect the organisation's actual information risks and security requirements.

That said, don't be surprised if certification auditors spot the lack of such commonplace controls as backups from the SoA and ask pointed questions about ensuring the availability of information!   

Learn from other initiatives, both internal and external to your organisation and whether entirely successful or not. Seek out and adopt good ideas from all quarters.

We can’t guarantee success but here are some trade secrets from the little black books typically maintained by experienced ISMS PMs:

• Become familiar with the business you serve. Get to know the department heads and the challenges they face. Try to see information risks and controls from their business perspectives, and look hard for situations in which strong, reliable information security is taken for granted or presents opportunities for new business activities that would otherwise be too risky.

• Cultivate business champions for information security in key areas, for example by talking to Sales people on how they win business and what would help them be more successful, asking the R&D boffins about the importance of keeping research secrets from commercial rivals, and checking how Finance department identifies and satisfies the accounting and tax obligations.

• Make friends with colleagues in related functions such as Risk Management, Legal/Compliance, Internal Audit, Site Security/Facilities and IT. Make time to explain to them how an ISMS will support what they do (which means exploring points of common interest), and garner their explicit support for the implementation project. Such people are often influential with senior management as well as their respective teams.

• Present ISO27k as a practical solution to current and future business problems rather than an academic set of controls. Solutions are more palatable than controls. Focus on the business outcomes of the ISMS rather than the ISMS itself. Continue to sell the ISMS as a solution to business needs and encourage other managers involved with security to adopt a similar business-focused attitude. Seek out and exploit strategic alignments.

• Remember that if the business is to adopt ISO27k and take on board a culture change, it should be perceived as empowering and enabling not restrictive and disabling.

• Tone down the technobabble and learn business-speak. Remember, IT is only part of the ISMS albeit an important one. Make a special effort to reach out to, inform and engage senior management up to board level: their understanding and support for the ISMS will facilitate the numerous changes necessary to business processes and systems as they are secured, and conversely their active or passive resistance will make your job much harder. Consider starting your management-level security awareness activities early in the ISMS implementation - even before your project is proposed and approved.

• Celebrate successes. Take every opportunity to write-up and share situations in which information security helps the organisation mitigate risks. Case studies and direct quotations from managers or staff who appreciate the value of the ISMS all help to spread the word: security is as much about saying “Yes!” as “No!”

There are a handful of published security guidelines, advisories or standards for Small to Medium-sized Enterprises, offering simplified guidance and, often, checklists ... but even they need to be interpreted and applied sensibly in any given SME.  Read the "Adaptive SME Security" paper in the ISO27k Toolkit for more.

Not really, at least not within ISO27k. It's just not that easy. Protecting valuable information is a complex challenge, given that  there are so many factors to take into consideration e.g.:

• Numerous possible threats, vulnerabilities and impacts;

• A large number and variety of information assets to protect;

• Questions about the meaning of 'protection' e.g. to what extent? How much assurance is appropriate? Who actually determines what protection is needed anyway, and how?

• Finite resources and other priorities and objectives, aside from infosec;

• Dynamics: nothing much stays still for long in this field. 

An effective ISO/IEC 27001 ISMS using a comprehensive suite of controls drawn from Annex A, ISO/IEC 27002 and other sources or security standards such as NIST SP 800-53, should satisfy and in fact exceed conformity expectations or compliance obligations, while simultaneously generating additional business benefits by satisfying the organisation's specific business requirements.

So, wise up! Take a step back to consider the broader business context within which information security exists, and the myriad issues at stake. Think about the practicalities of attempting to identify and protect all your information assets against all significant security risks. 

If you examine the costs and benefits honestly, investing in an ISO27k-style ISMS or a similar 'framework' is an effective way to deal with this. You can limit the effort by deliberately restricting the scope, reducing the problem space somewhat.  That may give you the chance to establish and gain experience with the management system ... but it also limits the potential benefits and is not necessarily the best long-term solution. You can also be smart about  designing and implementing the ISMS to align closely with and support business objectives, especially concerning the organisation's information risks.