ISO/IEC 27001:2013 is more commonly known simply as "ISO 27001". It is, as the ISO website puts it, "the best-known standard in the family providing requirements for an information security management system".
On the other hand, many businesses think it is a highly complex, unattainable standard – and a pain in the backside – as customers demand compliance ever more frequently.
But much of what I hear about ISO 27001 is conjecture and misinformation. The standard is quite short and very easy to understand: it is 34 pages long and the meat of it doesn't start until page nine and ends on page 30. Although it is not trivial to implement, the difficulty with ISO 27001 is not attaining certification. It is in remaining accredited by demonstrating that you act properly in your day-to-day, business-as-usual operations.
Compliant vs certified
I'll be honest – I have a hard time with companies that claim to be "ISO 27001 compliant" that haven't gone out and become formally certified. The difference is simple. If you are certified, you've had an independent auditor spend time examining how you operate and confirm that you do so within the requirements of the standard.
But if you claim to be compliant you are basically self-certifying – you're saying: "We believe that our business operates such that an ISO 27001 assessor would certify that we do so." My response is: "OK, so why haven't you spent a few thousand quid being audited, then?" After all, the time and effort you'll have expended internally will be far greater than the cost of an independent audit.
The basics of ISO 27001 Security is an inherent consideration in the way you work, not something you look at every few months when an audit is due. ISO 27001 provides a framework for implementing an Information Security Management System (ISMS) that encompasses the policies, procedures and standards that sets out how you run your company.
To embark on the road to becoming ISO 27001 accredited, the first thing you need to do is decide which elements of your business you want to include in the accreditation. Yes, that's right: you don't have to do the whole lot at once.
Sounds a bit bonkers, but if your business is multifaceted and has several divisions that address many vertical markets it is not unusual to, say, go for accreditation of your ecommerce department first and follow later with your marketing department.
ISO 27001 is handy like that: you can split the task into bite-size chunks and do them one at a time. In this respect it is similar to Agile development in that you can take several small steps instead of one socking big one.
Once you've decided which bit(s) of the business you want to certify, you need to decide the criteria under which you want to certify them. Step one is to acknowledge that clauses four to 10 of the standard are mandatory, so you must comply with them. The key components are:
- Leadership: you need complete buy-in from senior management – preferably at a company level but at least at the highest point of management for the bit you're certifying. If you don't have this commitment, don't even bother trying – because you will fail.
- Risk (clause 6 is called "Planning" but it really means "risk"): the absolute core of ISO 27001 is security risk assessment, analysis and treatment.
- Engagement: clause 7 is called "Resources" but it's all about engaging with everyone responsible for implementing security, promoting awareness, training them where appropriate, communicating about security issues and documenting processes, procedures and standards.
- Operation: the ongoing activity of assessing and reassessing risks regularly and dealing with them.
- Evaluation: frequent checks of where you are, internal audits and management reviews (remember the leadership element above).
- Improvement: not just dealing with issues that you find when assessing risks and doing internal audits, but proactive improvement even where you haven't found anything particularly lacking.
The key sub-clause
The other essential element is, oddly enough, buried in a sub-clause of a sub-clause (specifically clause 6.1.3): the Statement of Applicability (SoA). This is where you list the criteria on which you'll be measured, so what you need to do is come up with a list of things that are relevant to your organisation.
Helpfully, the standard gives you a starting point in the form of Annex A, which begins on page 18 of the document and is a long list of controls that you should consider for inclusion in your SoA.
Some are classed as "mandatory" – but realistically this is because one cannot imagine an organisation where they would not be relevant: examples are A.7.1.2 (terms and conditions of employment of staff) and A.16.1.5 (security incident response). Although Annex A is 13 pages long you don't necessarily have to include everything – particularly if much of what your business does relates to physical rather than IT security. What matters is that you consider each item and decide if it is in or out of scope.
Thinking of what's not there
Bear in mind, though, that Annex A is a starting point, not an all-encompassing nirvana. It is essential that you consider stuff that could relate to security but isn't covered by the list in Annex A. The obvious place to look is in any other regulatory requirements that cover your business: for example, if you're a finance business an ISO 27001 auditor would expect you to include controls that relate to the requirements of your financial services regulator. An auditor will question your thoroughness if all you've done is list the Annex A clauses and not added anything else.
Engaging third parties
Unless you have internal staff qualified in ISO 27001 practices, it makes sense to engage a third-party specialist to help you out. First of all they'll help you put together your SoA and the required documentation you will need to implement controls (many will provide templates for your documents: one size definitely doesn't fit all, but starting from a general template instead of a blank page is a great help). You can arrange to taper off the third-party support as your internal expertise grows, but having access to people who have done it loads of times before is a great way to get going.
You may be surprised to hear that you should also engage with an auditor early on in your ISO 27001 implementation. There are many organisations out there that will provide this service, and you'll usually find that a specific auditor is assigned to deal with you on an ongoing basis.
The reason is simple: if a different person rocked up for every six or 12-monthly audit he or she will spend half the time learning about your organisation, whereas someone with continuity of relationship will hit the ground running each time. It's a slightly odd arrangement given that the auditor is supposedly independent. But you are paying their company to audit you, and the auditors are in turn audited by their peers and the accrediting body to keep things above board.
Get some internal expertise
Clause 9.2 in the standard is one of the most important, and it's all about internal audit. Between your independent audits you are expected to do your own internal audits and act on the findings – and that means you need some knowledge of how to do this.
I wholeheartedly recommend simply sending a couple of people – preferably from independent divisions so they don't have axes to grind against the auditees – on an ISO 27001 Implementer or Auditor course. It's a few days and a couple of thousand pounds well spent, and it equips you with the knowledge of everything the external auditor will be doing when he or she visits. I did precisely this a few months ago and the clarity it brought to how to do ISO 27001 was staggering.
Keep the wheels turning: I said right at the beginning that the hardest part of ISO 27001 accreditation is maintaining the standards of operation required. You need to demonstrate that you have a constant focus and are reviewing your entire regime regularly and in a controlled fashion: if you just have a two-week push in the fortnight before the independent audit you're kidding yourself and the auditor won't fall for it.
Most importantly – be honest
The final thing to remember is that you need to be honest – with yourself and with your auditor. There's no point trying to sweep failings under the carpet and pretend they didn't happen, because they'll come back to bite you. In fact the most prominent odour of rodent occurs when your incident log shows you had nothing of interest happen in the last few months: unless you're unbelievably perfect there will have been something that didn't quite go right. Pretend to be perfect and the auditor will see right through you.
And the point is this: your ISO 27001 ISMS is there as a framework to help you manage your information security in a risk-based way. There's no such thing as a company that has no risks: what the auditor is looking for is evidence that you frequently look for risks, you evaluate the ones you find, and you take appropriate action (which for minor risks may be to change nothing and accept them as-is).
Excellent is good enough
The final note is that since (as I've already mentioned) perfection seldom exists in business, it's not a requirement for ISO 27001 either. When your auditor gives you your report, it would be very unusual for it not to contain negative findings – nonconformities, as they're termed.
But nonconformities come in two flavours, and only "major" ones make you fail: generally speaking, you're slapped with these when there are clear, systematic, fundamental failures in your regime that show the auditor that your ISMS and/or the way you run it just aren't up to the job.
"Minor" nonconformities are part of life, and tend to relate to isolated failings or small gaps in what you do, and they don't destroy your accreditation – so long as you respond to them and take the necessary action to put them right.
ISO 27001 doesn't, then, certify perfection. But it does certify excellence, and I think that's the best most of us can strive for. ®