This section of the ISO27k FAQ concerns internal auditing of an ISMS and formal certification against ISO/IEC 27001:
FAQ: “I work for an Internal Audit function. We have been asked by the ISMS implementation project team to perform an ISMS internal audit as a prelude to an external/third party certification audit against ISO/IEC 27001. They are asking for a load of things from us and expect us to do the audit within a tight timescale defined on their plans. Is this information really needed? Are we (as an independent audit team) forced to give them such information? Should we perform a quick Internal Audit or take the time necessary although the certification would be postponed? Are there ISMS Audit Programme/Plan templates we can use and what other considerations should we take into account for the ISMS internal Audit? ...”
A: If you are a truly independent audit team, you do not answer to the ISMS project team and they cannot force you to provide information or do things for them in a certain way. However, as Internal Audit, you work for - or at least in conjunction with - the organization's senior management and would presumably be expected to support the organization's strategic aims. If the ISMS has management's full support [a not insignificant assumption - something your audit might want to establish!], it is reasonable for them to invite you to audit it thus fulfilling the requirements for ISMS internal audits, and arguably also to ask about your competence/qualifications to do so. However, the manner in which you perform the audit, the way you plan and perform it, is really your domain. For example, you would need to develop the audit program, schedule the work, assign suitable auditors etc. How much advance notice and other information to give them is up to you, although in the interests of making the audit as effective as possible, I would try to work with them on this. Right now, they are probably quite sharply focused on compliance with ISO/IEC 27001 and are simply trying to fulfill the standard's requirement for internal ISMS audits, which you should read to understand. They may not appreciate your role in life, nor the value you can bring to the party. It sounds as if they are perhaps unfamiliar with the way you normally work, and probably have a naïve view of how you would approach the job (e.g. pure compliance auditing). They almost certainly presume that your audit would be entirely constrained within the scope of their ISMS whereas you would probably be interested in the wider picture, potentially including security and risk management issues elsewhere in the organization.
On a more positive note, it makes a nice change for auditors to be “invited” in by their prospective auditees! This could be an ideal opportunity for Internal Audit to get to work on the ISMS and make positive recommendations for improving the organization's information security controls, risk management, compliance and governance (at least within the scope of the ISMS for now), knowing that the implementation team and hopefully management has the incentive to address any issues quickly in order not to stall or preclude the certification. Personally, however, I would be cautious about being too ambitious with your audit at this stage since recommending major changes could be seen as derailing the ISMS project, while a softly-softly approach would leave the door open for further ISMS audits supporting their PDCA-based internal management review and improvement activities. With an effective ISMS in place, you can expect the information security situation to be more stable as it comes under better management control, and then to improve gradually of its own accord. You have a part to play in making this happen as effectively and efficiently as possible. In particular, your independent viewpoint gives you the advantage of making sure that the ISMS is not blind-sided by some unanticipated issue that the ISMS management team was unaware of, and the chance to promote generally accepted good risk/security management practices based on the standards or other sound sources.
Implementation tip: this is a learning opportunity for all those involved, including you and your audit colleagues. Sit down with those in charge of the ISMS (both the implementation project managers and the business and information security managers who will run the ISMS in perpetuity, plus your own audit management) to talk about what they have done, what they anticipate you doing now, and how they see the relationship developing over time. An ISMS is a long-term commitment to professional information security management and that surely has to be a positive thing for audit and the organization. You probably should consider some training or familiarity with ISMS, ISO27k standards etc. and possibly consultancy support from auditor/s familiar with ISMS internal audits and certification audits to get you off to a flying start, unless you already have experience and skills in this area. You asked about templates for ISMS auditing: I would suggest looking to ISACA, IIA or other professional groups for some support, plus of course the ISO27k standards themselves and your existing audit procedures. In due course, though, I'm sure you would soon pick this up on the job and, by the way, it will not hurt your CV!
FAQ: “I am an inexperienced auditor. How should I go about planning and performing an ISMS internal audit?”
A: You might start by reading ISO 19011, the ISO standard for auditing quality and environmental management systems, for general advice, plus ISO/IEC 27007 for more specific advice on ISMS audits. Your Internal Audit function, if you have one, is another obvious place to seek help and the IT audit FAQ offers more detailed guidance. ISACA is another recommended resource. ISO/IEC 27008:2011 is available as a desperate last resort!
Meanwhile, the typical audit process goes something like this in my professional experience as an internal IT auditor:
- Agree the scope (what's in and just as importantly what's out of scope?), purpose/objectives and criteria for the audit (e.g. man-days or elapsed time available, expected audit deliverables) with audit and maybe business management. [Each audit normally flows from some form of risk-based annual audit planning and scheduling.]
- Review the situation and the background to the audit, considering the risks potentially of concern in the area of scope and any concerns or loose ends arising from prior audit reports, management reviews etc. You may need to do some initial scoping/feasibility work on the job, and check any previous ISMS-related audit reports and maybe the audit files to get a feel for the likely problem areas. Either way, try not to lose sight of your independence, in other words think about the risks and issues in broad, fairly theoretical terms, assuming nothing about the controls that one would naturally expect to be in place just in case they aren't.
- Draw up an audit work program, Internal Controls Questionnaire (ICQ), checklist (or whatever you call it) showing the issues you intend to check and indicating in what level of detail you will check them. Leave yourself some space for notes to record findings and your initial analysis while things are still fresh in your mind.
- Consider and plan the audit fieldwork i.e. how you will actually check the things of interest on your ICQ e.g. through interviews, observation, data analysis, sampling, testing ... Draw up your shopping list of things you will need, people you want to speak to etc. and reconfirm the timescale for the audit assignment: you will often have lined yourself up more work than you can reasonably complete in the time available, so revisit the scoping for clues about management’s priorities for the audit.
- Identify and contact your lead contact/s for the audit and work with them to line up and prepare for the fieldwork, hopefully sorting out many of the items on your shopping list (e.g. arranging initial interviews, obtaining reports, policies etc. that you will want to review). It's best to contact the contact as early as possible in the process: good contacts can help with the planning too, but be cynical if they try to steer you away from anything!
- Perform the audit fieldwork, keeping your contact up to date with developments, preliminary findings, concerns, any problems conducting the audit etc. A helpful audit contact can act as a sounding board for emerging audit concerns and possible recommendations, and a source of additional inside knowledge. Work systematically through your ICQ.
- Analyze the findings, generating a list of priority issues (must-fix items) and ‘additional items’ (often included in reports just for information, but that depends on audit working practices). My preference is to draw up a “SWOT” analysis identifying the key Strengths, Weaknesses, Opportunities and Threats - no more than about 5 or 6 items per category to keep things at a high level. You may need to revisit certain parts of the ICQ to confirm significant findings, collect additional evidence, and generally substantiate the key issues. Try to stay objective, for instance basing your work on facts backed by audit evidence.
- Prepare a draft audit report and recommendations addressing the priority issues, and get this reviewed within the audit function, or by your manager at least. A ‘file review’ is normal in order to confirm that everything reportable is being duly reported, and everything reported is traceable to sound audit evidence. This requires sorting and indexing the audit evidence, cross-referencing it to the ICQ etc.
- Work with senior and middle management to clarify any audit concerns and recommendations, and to align priorities and timescales with business objectives and constraints. Normally, as part of this phase, you would present and discuss the SWOT analysis, the draft audit report and the key findings and recommendations with client management. Discuss the recommendations, and seek their outline agreement to the actions arising. It's important to give management some time and space to consider anything serious, particularly if they would have to juggle priorities and assign resources to this. You may need to meet senior managers individually to explain and discuss things further, and sometimes to consider alternative approaches (business managers generally know best how to implement improvements, but you should by now have established your credibility and hence have influence).
- Finalize the report, ideally including a firm action plan with dates and responsibilities for resolving the issues and even better something from management formally confirming that they accept the report and intend to carry out the recommendations.
- Issue the report to the appropriate people. It may help to create and circulate a brief executive summary (maximum 1 or 2 sides) for senior management but make the full report available to those who need the details.
- Decide whether and how to follow-up to ensure that the action plans are in fact completed properly, if this is audit's responsibility [it varies between organizations: in some, management is entirely responsible for completing recommended and agreed actions]. In others, management request audit's help to check for completion.]
- Follow-up and if necessary escalate any outstanding issues to (more) senior management. If appropriate, revisit the findings and risks to confirm if the issues raised are still of concern, and apply pressure through management to get the job done.
- Close the audit file. Prune out the irrelevant information, keeping relevant evidence, reports, feedback from management etc. and making notes for the next ISMS audit. Store the audit file securely as the contents are probably somewhat sensitive.
For pure compliance audits (such as ISO/IEC 27001 certification audits), the key risks and issues relate to non-compliance with mandatory requirements laid out in the standards of course, and ISO/IEC 27006 may help. For pure management systems audits, the focus is self-evidently on the management system and processes, which are driven by ISO/IEC 27001. For more broadly-scoped ISMS internal audits, there may well be other more or equally important issues worth reviewing for the business ... like for example the small matter of whether the information security controls are adequate (see ISO/IEC 27008).
Implementation tip: personally, I use mind-maps to help me think through the likely risks and anticipated controls, and to structure each audit job. Process diagrams, flowcharts, swimlane charts, Ishikawa (fishbone, cause-and-effect) diagrams and so on may suit you better. Don’t forget to include sufficient contingency time in your audit plan, for instance allowing you to delve more deeply into any areas of serious concern that emerge from the audit.
FAQ: “How can we confirm the implementation of controls selected in the Statement of Applicability?”
A: Auditors should check that your identified ISMS controls are truly in operation, not merely listed as such in some dusty old policy manual or intranet website. Evidence is key! For example, you need to have experienced at least one incident to confirm that the incident management process actually works in practice and is not just a fine set of words in your ISMS policies. This is analogous to the situation with ISO 9000 where the auditors typically check that genuine quality issues have been identified through quality reviews etc., addressed following the stated QA processes and resolved, not just that you say you will deal with them in a certain way should they ever happen.
Clearly, it is not reasonable to wait until there has been a complete disaster to check that your contingency planning processes function correctly - there are pragmatic limits to this principle, thankfully! But you should probably have completed at least one contingency planning exercise or Disaster Recovery test including the vital post-test washup to identify things that need fixing. For common information security controls that are in action all the time (e.g. antivirus, access controls, user authentication, security patching), the auditors will want to check the evidence (they may call them “artifacts” or “records”) relating to and proving operation of the information security management processes.
Remember, an ISMS is for life, not just for the certificate.
Implementation tip: it's best if possible to hold off the certification auditors for a few months after the ISMS is considered “done”, in order to build up your stock of evidence demonstrating that the processes are operating correctly, in addition to letting the processes settle down a bit. Your implementation project plans should therefore show a short hiatus after the implementation should be finished but before the certification auditors are due to arrive, supplementing the usual contingency allowance in case of implementation delays.
FAQ: “How can we ascertain whether the control objectives are fulfilled?”
A: Fulfillment of security control objectives can be determined by management, by auditors or by others checking the controls to decide the extent to which the corresponding objectives are satisfied.
Security incidents obviously suggest that the controls are less than perfect ... so one way to identify controls and objectives worth a close look is to rummage through your information security incident records and reports for evidence or hints about missing or ineffective controls. Make a special effort to tease out and re-evaluate longstanding issues. Don’t be hoodwinked into ignoring issues that “have always been a problem” or “will never be solved”: if they are in scope of the audit or review, they are almost certainly worth checking. An experienced, competent IT auditor’s unjaundiced eye and techniques for assessing and reporting on such issues might just unblock the drains and help the organization achieve real progress.
Control objectives that are not sufficiently satisfied are obvious candidates for security improvement, but the prioritization or urgency or necessity of that work depends on the significance of the risk and the degree of noncompliance. For example, a control objective to minimize malware risks may require “up-to-date antivirus software running on all applicable systems”. The antivirus software used, the updating process, the range of systems to be protected, and the realities of implementing the control on a wide range of systems mean that some systems may not be fully protected right now for a variety of practical reasons, but so long as all the main/most important systems and a large proportion of the remainder are adequately protected, the organization may (or may not) be willing to accept the residual risk. Management may even make a conscious risk management decision not to insist on full implementation of antivirus if the costs of doing so on every single system outweigh the benefits.
Implementation tip: this is primarily a risk management or business decision for the Information Asset Owners who are accountable for protecting information assets. Information security and risk management people can advise them, of course, but should avoid going beyond their brief and, in effect, accepting accountability for information security matters that rightfully belong to management.
FAQ: “Will the certification auditors check our information security controls?”
A: To a limited extent yes but the primary purpose of the certification audit is to confirm whether you have an effective ISMS in operation, not whether you have secured your information assets. It’s a subtle but important difference. As Patrick Morrissey put it on the ISO27k Forum, “An ISO/IEC 27001 certificate does not mean that your organization is secure: it states that your ISMS is working. Period.” The underlying principle here is that if you have an effective ISMS in operation, then the ISMS will ensure that there are adequate security controls in place. This approach also means that strictly speaking you needn’t necessarily have a completely comprehensive suite of information security controls to pass the certification audit, just so long as your ISMS is adequate to ensure that it will improve in due course. The vital concern is that the organization should have information security under management control and be proactively directing and controlling it.
The certifications auditors may, however, need to do some substantive testing of the information security controls to confirm that you are in fact doing what you say you are doing, just as they may check that, for example, you have undertaken an information risk analysis and duly considered the risks in you specific context in order to specify your control requirements. In other words, they will seek evidence that the ISMS processes are operating correctly and in many cases that will involve confirming that certain security controls are operational.
Implementation tip: regardless of whether the certification auditors do or do not audit the controls, the organization should still be checking its own information security controls routinely, typically through management reviews and internal audits since this is one of the “Check” processes within the PDCA cycle in the ISMS. The certification auditors may therefore ask to see some evidence that you are routinely checking your controls, for example management review or internal audit reports, along with agreed action plans to address any improvement recommendations (i.e. the “Act” part of PDCA).
FAQ: “How will the certification auditor check our ISMS internal audit processes? I’m nervous! What are the typical questions we should expect?”
A: Assuming they represent an accredited certification body that has adopted ISO/IEC 27006, the certification auditor/s will have been trained and will act professionally, diligently checking compliance with the ISO/IEC 27001 standard following a standardized audit process derived from the ISO/IEC auditing and certification standards.
ISMS internal audits are a relatively small but quite important element of the ISMS in terms of continuous improvement and assuring compliance with your security policies, laws etc., so you can expect the auditor to explore your internal audit practices a little, more or less depending on how much time they have and how much risk they consider is associated with the internal audits as compared to other aspects of the ISMS.
A certification auditor’s prime objective is self-evidently to check your organization’s compliance with the standard’s formal specifications, so at its most basic they will look at what ISO/IEC 27001 specifies for ISMS internal audits under clause 6 and ask you to demonstrate how you do it, using the evidence from past ISMS internal audits as proof.
The auditor will probably review and question you regarding your ISMS audit plans, procedures and report/s, exploring aspects such as:
- How you audited: did you perform the audit in accordance with your own audit policy/standard/process? Are your ISMS internal auditors competent (what are their their qualifications and experience at ISMS or other types of audit)? Are they truly independent of the areas being audited (independence is the critical distinction between audits in section 6 of ISO/IEC 27001 and management reviews in section 7)?;
- What you audited: did the scope of the audit match that of the ISMS, or was it more limited in scope, in which case are you planning to fill in the gaps later?
- What you found: this will give the auditor clues about the state of your ISMS and may identify issues/concerns deserving further investigation;
- What was the outcome, in other words what did the audit achieve? Did all agreed audit recommendations (including corrective actions arising from non-conformities but possibly also more creative improvement suggestions) get fully actioned and signed-off on time and was your ISMS actually improved? More generally, how does management react and respond to audits? Do they take them seriously? Do ISMS internal audits add value to the organization?
Listen carefully to any summing up or findings or recommendations the auditor makes as there may well be some helpful suggestions about how to improve your ISMS, and if they are stated by an independent, competent external auditor, they tend to carry weight with management. Even if the final audit report officially says “No issues, fully compliant”, the auditor may raise minor concerns, snags or improvement suggestions informally. A good auditor will also compliment your organization on certain aspects of its ISMS, and those kinds of comment make good security awareness materials. It's nice to be given a clean bill of health and to be certified compliant, but a positive comment about something your organization is doing well can really make someone's day!
Implementation tip: take it easy, don't fret! Like taking an examination, the audit should go smoothly provided you have done your homework. Preparing your paperwork in advance of the auditor's visit will help you both. Sort out your ISMS policies, audit plans, audit files, audit methods, audit reports etc. - get them straight and be ready to offer relevant information promptly if/when the auditor asks for it (be nice: don't just dump everything on them in a big pile and say “Help yourself”!). If you are well organized and helpful, it will make the auditor’s job easier, reduce stress and increase confidence in how you conduct your internal audits.
FAQ: “What are our options if we dispute the findings or have an issue with the certification auditors?”
A: The accredited certification auditors hold almost all the cards in respect of certification audits. To a large extent, what they say goes since they can steadfastly refuse to issue a certificate if they believe their client is noncompliant with a mandatory requirement. ISO27k certification auditors must audit strictly against the formal specifications in ISO/IEC 27001 (no more, no less). The accreditation process, plus the standards relating to audit processes and certification, are designed to ensure that that is exactly what happens. The whole certification scheme hinges on it. Any doubt that the certification auditors have followed proper procedures and audited strictly against the formal requirements could discredit the issued certificates and, by implication, all of ISO27k. Concerns about certification audits are an order of magnitude more serious than for internal audits, and two orders more than for internal management reviews/assessments.
If a client has a genuine concern about a certification audit finding, recommendation, or auditor, they should first discuss it with the auditor and/or the assignment manager. Most things can be addressed at this informal level, with reference to the relevant standards, procedures and audit evidence. [This happens fairly often in practice. Discussion and clarification of this nature is a normal part of any audit. Thankfully it is usually the end of the matter: although one or both parties may feel a little aggrieved, they normally reach “an understanding” - a delicate agreement or a truce at least - and move on.]
If the concern has not been resolved or cannot be taken further at the informal level (for example, the client believes the auditor is incompetent or misguided or plain wrong about something, but the auditor and/or the audit manager disagrees), they can complain formally to the audit company senior management about the situation and try to negotiate a mutually acceptable settlement. They should of course expect a robust response from the auditor and the company management (including the re-examination and re-presentation of the audit evidence and analysis), but if there is merit to the complaint, the company should have an internal process for dealing responsibly with it. It may be handled as a supplier-customer complaint, or as an audit issue, or a certification issue, or a legal issue (more below) or all of the above. [This is quite rare but I'm quite sure it happens. I believe partners in audit partnerships are jointly liable for their work, so they will take complaints seriously if they are raised to that level, but the potential conflict of interest is obvious.]
If that complaint process fails - for example if the response is still unsatisfactory to the client, or if they feel they have not been treated professionally - they can potentially complain to the accreditation body that accredits the certification company. To get anywhere, the client would need to provide sound evidence concerning the dispute, essentially having to prove that the certification company and/or its auditors are not worthy of being accredited. The accreditation body should have a formal procedure for dealing with such complaints. [I personally have never heard of such a case, but it's certainly possible.]
The client can also complain to the professional bodies that certify and represent individual auditors - for example ISACA for CISAs. Again, they are likely to get a robust response from the professional body who will probably have a standard process to review the complaint, assessing evidence from both sides before siding with the auditors, their members (!). It would take very strong, hard evidence of professional misconduct or incompetence to persuade them to find against their members, coupled with a highly professional ethics or professional standards committee. [I am aware of occasional complaints of this nature, but most probably never see the light of day. Vanishingly few cases go beyond a temporary suspension of the member concerned, but expulsion is their ultimate threat.]
At some point in this escalation, the dispute is likely to be handed to the lawyers, implying that they will look at the standards, contracts, policies, procedures and so forth with a strict legal eye, as well as assessing the evidence relating to the dispute. Any ambiguity in ISO/IEC 27001 that led to the dispute will be brought to the fore, with each side's auditors making their case. Ultimately, it may come down to the opinion of a judge in court. [It would be an extremely serious matter if a dispute ever got to this stage, clearly, since losing accreditation would be a huge commercial setback to an audit or certification company, as well as a knock to the accreditation and auditor professional bodies (since it is implied that they should not have accredited or certified the auditors) and again to ISO27k as a whole.]
Implementation tip: auditors and auditees are mere mortals. We all have our ‘off days’ on which we make more than our normal number of mistakes and errors of judgment, but none of us likes to admit to being wrong. Handling disputes sensitively can make a huge difference, for example by focusing on the factual evidence and explicit requirements in the standard rather than the personalities and subjective opinions, passions or prejudices of those involved. It’s perfectly reasonable to ask “Show me” - and that goes equally for both auditees and auditors (e.g. if an audutor is asking you for or to do something that you do not believe is required by the standard). Avoid highly emotive words such as “incompetent” (even though that might be perfectly accurate!). If things are getting fraught, take a break to chill out. If all else fails, clients can choose different certification companies, and certification companies do not have to bid for every single sales opportunity ...
FAQ: “How does my organization get certified against ISO/IEC 27002?”
A: It cannot - for reasons best known to ISO/IEC, organizations can be assessed or audited or reviewed but not formally certified against ISO/IEC 27002.
One reason is that ISO/IEC 27002 is a “code of practice” (whatever that means!) containing general good practice guidance rather than prescriptive requirements. Certification auditors who are essentially compliance auditors would therefore have to apply their judgement and discretion when checking compliance with the standard, which is evidently beyond them :-) In truth, the variation that would arise in practice to reflect each organization’s specific context and information security needs would detract from the value of a generic certification scheme. Context is all-important.
Your organization could be reviewed informally or even audited against ISO/IEC 27002 by competent IT auditors, consultants or indeed experienced information security professionals familiar with ISO27k, and indeed this is the “gap analysis” activity common to many ISMS implementations. Information security controls currently in operation in the organization are compared against those recommended by ISO/IEC 27001, looking for gaps that will probably have to be addressed at some point during the ISMS implementation project (if the missing controls are judged necessary to mitigate risks).
ISO/IEC 27001 lays out a formal specification for an ISMS, with the emphasis very much on ‘management system’ rather than ‘information security’. The management system element of an ISMS is more easily specified in a generic yet formal way than the information security controls, and therefore ISO/IEC 27001 is the standard against which organizations are formally certified (see below).
This does however leave us with a problem: how can organizations place confidence in the actual information security controls of their business partners? Their ISO/IEC 27001 certificate only tells us that they have a working and compliant management system, and we assume that therefore they have assessed their information risks, implemented appropriate information security controls, and are proactively managing them ... well in fact that’s quite a lot of assurance when you think about it. Business partners can still opt to disclose more information about their actual information security controls, for example by sharing their information security policy manuals or by permitting third parties to audit their information security controls (perhaps using ISO/IEC 27008).
Implementation tip: read the standards!
FAQ: “OK then, how do we get certified against ISO/IEC 27001?”
A: DNV has a helpful overview of the process.
First obtain and read the standard. We recommend obtaining ISO/IEC 27000 (provides a glossary of terms and an outline of the whole ISO27k series, useful for explaining them to management), ISO/IEC 27001 (the ‘certification standard’ which summarizes the process of implementing an Information Security Management System ISMS) plus ISO/IEC 27002 (which gives more detail on the nature of the ISMS). ISO/IEC 27002 contains a reasonably comprehensive set of key control objectives for information security and lists a whole load of good practice security controls that are commonly used to satisfy those control objectives. I tend to speak of ISO/IEC 27002 as a menu of information security controls from which you need to pick your meal. You make your order (select the specific controls) using a risk analysis process - see ISO/IEC 27005.
Next you need to plan and conduct some form of information risk analysis. In reality, you first need to set the scene with management and then line the relevant parts of the organization and people up to ensure they engage with the risk analysis process. They need to be reasonably open to the concept of improving their information security controls and you will probably need to engage suitable risk and security experts to make this process as painless and effective as possible (hopefully you are lucky enough to have the resources on board already, otherwise you have to choose between building the competence in this area or buying-in expertise in the form of contractors or consultants). The risk analysis may be called a 'gap analysis' or 'ISO27k review' since it may make sense to compare your existing controls against the advice in the standard, looking for weaknesses and omissions as you go, or you may prefer to do a zero-base risk analysis, assuming that there are not controls in place. The advantage of the latter approach is that you might identify unnecessary controls that can perhaps be deinstalled later.
By the way, “the relevant parts of the organization” relates to the scope of your intended certification. You have the option to certify the whole shootin’ match or only parts. This is a critical decision for management. You will need to work closely with management to clarify what is in and out of scope, with the important proviso that everything declared as out-of-scope is inherently untrusted from the perspective of the in-scope elements, therefore suitable security controls (both technical and non-technical e.g. contracts or SLAs) are probably needed for data flows, systems, networks, processes etc. that cross the scope boundary. Cutting the scope right down is not necessarily the easy option!
Having completed the risk or gap analysis, you have the challenge of persuading senior management that they really do need to invest in information security, and of explaining the issues and risks that your analysis has identified in terms they appreciate. This is a tricky step, a balancing act: over-egg your dire predictions and they may back away saying you are being sensationalist. Underplay the security issues and they may not pay much attention to the need for improvements. It really helps to lean on someone with prior experience in this area. Management's appetite for addressing the issues you identify will determine the financing and priorities for the next step. If management say “no” at this point, you might as well reconsider your career options.
With management backing, you now implement the security improvements. Easier said than done! It could be a mere formality if your setup is already very security aware and competent in this area. It could be an extremely arduous job if you are starting from a low base, such as an organization which has habitually underinvested in information security, has made strategic changes in its use of, and dependence on, IT (e.g. it has started using the Internet for business processes/transactions and communications, rather than simply for promotional websites), or where there are no clear accountabilities for information security. It is impossible for me - or indeed for you - to say how long or how costly this phase will be for you until you have completed the previous steps, and even then you can only estimate.
With the improvements well under way and security gradually becoming an inherent part of business-as-usual, it's time to think forward towards ISO/IEC 27001 certification. Like other management systems standards from ISO, ISO/IEC 27001 is process-focused - it helps set up a management system for information security comprising a suite of management processes.
Certification involves contacting a suitable accredited certification body to review your Information Security Management System ... [continues below]
Implementation tip: establish contact with the certification auditors as soon as you like. They don’t bite and most will happily answer basic questions about the process if it means a smoother audit for both of you in the long run.
FAQ: “What is really involved in becoming ISO/IEC 27001 certified?”
A: See the overview ISMS implementation and ISO/IEC 27001 certification process diagram or grab the Visio original or a higher-resolution PDF (and check the ISO27k Toolkit for other languages):
The flow chart gives a high level view of the major steps in the process. This is a generic summary - the details will vary from situation to situation. The main activities are as follows:
- Get management support - easier said than done! This typically involves raising management’s awareness of the costs and benefits of having an ISO/IEC 27001 compliant ISMS. A great way to start is to raise management’s awareness of some of the key current information risks and potential good practice controls (drawn from ISO/IEC 27002) that are not yet in place, perhaps through a “gap analysis” (an outline risk assessment and overview of the work needed to achieve compliance) followed by a business case and/or strategy for the security improvement (ISMS implementation) program.
- Define ISMS scope - what businesses, business units, departments and/or systems are going to be covered by your Information Security Management System?
- Inventory your information assets - the inventory of information systems, networks, databases, data items, documents etc. will be used in various ways e.g. to confirm that the ISMS scope is appropriate, identify business-critical and other especially valuable or vulnerable assets etc. (more below).
- Conduct an information risk assessment - ideally using a recognized formal method but a custom process may be acceptable if applied methodically. There’s more advice in the risk management section of this FAQ.
- (a) Prepare a Statement of Applicability - according to ISO/IEC 27000, the SoA is a “documented statement describing the control objectives and controls that are relevant and applicable to the organization’s ISMS”. Which of the control objectives from ISO/IEC 27002 are applicable to your ISMS, and which are irrelevant, not appropriate or otherwise not required? Document these management decisions in your SoA; and in parallel ...
(b) Prepare Risk Treatment Plan - ISO/IEC 27000 describes the information security RTP as “a plan that identifies the appropriate management actions, resources, responsibilities, timeliness and priorities for managing information security risks”.
- Develop ISMS implementation program - given the scale, it is generally appropriate to think in terms of an overall program of individual projects to implement various parts of ISO/IEC 27002, for example one project for each of the main sections of the standard. Which resources can you call upon, direct, use, borrow or persuade to build or supplement your core ISMS implementation team? You will probably need experienced information security professionals (particularly a team leader) and support from related functions such as Internal Audit, Risk, Compliance, HR, Finance and Marketing, not just IT. You are advised to plan the work in risk-priority-order where possible i.e. tackle the biggest risks early so that, whatever happens to your program of work in practice, it has had a good go at knocking down the main issues and can demonstrate real progress, even if it then falters for some reason. Also, early wins are a source of helpful positive feedback: this is an important aspect to the program which as to be seen to be effective by management, as well as actually being effective. If all the program does is interfere with business, annoy managers and cost a packet, it is hardly going to be on the shortlist of “things we really must keep doing next year”!
- Run the ISMS implementation program - through the individual project plans, the implementation team sets to work to implement the controls identified in the RTP. Conventional program and project management practices are required here, meaning proper governance, planning, budgeting, progress reporting, project risk management and so forth. If the program is large, seek professional program management assistance.
- Operate the ISMS - as each project in the program fills in part of the ISMS, it hands over a suite of operational security management systems and processes, accompanied by a comprehensive set of policies, standards, procedures, guidelines etc. Operating the ISMS has to be an ongoing routine activity for the organization: this is not a one-shot project! The Information Security Management function needs to be established, funded and directed, and many other changes are likely to be required throughout the organization as information security becomes part of the routine.
- Collect ISMS operational artifacts - the ISMS comprises your framework of security policies, standards, procedures, guidelines etc., and it routinely generates and uses security logs, log review reports, firewall configuration files, risk assessment reports etc. ... all of which need to be retained and managed. These artifacts are crucial evidence that the ISMS is operating correctly. You need to build up sufficient artifacts to prove to the auditors that the system is operating, stable and effective.
- Audit the ISMS - internal auditing of the ISMS will be a routine part of it. The idea is to have competent and independent reviewers (ideally trained and experienced IT auditors) take a good look at the ISMS, review the evidence (ISMS operational artifacts plus other documentation such as information security policies and procedures), consider that in relation to the risks and opportunities to the organization, and make recommendations. Compliance with the formal requirements of ISO/IEC 27001 (see step 11) may be a major part of the audits but a competent internal audit function will generally be more interested in how well the ISMS meets the organization’s requirements as a whole: gaining an ISO/IEC 27001 compliance certificate is probably just one of several business reasons for implementing the ISMS and investing in information security management. Identifying and addressing the organization’s information risks in a structured, systematic, comprehensive, prioritized and coherent manner is the bigger goal.
- Review compliance - are you actually doing what you said you were going to do? ISO/IEC 27002 covers compliance with both internal requirements (corporate policies etc.) and external obligations (such as laws and industry regulations). The ISMS itself needs to incorporate compliance testing activities which will generate reports and corrective actions.
- Undertake corrective actions - to improve the ISMS and address risks. The ‘management system’ part of the ISMS should result in continuous alignment between business requirements, information risks and capabilities for information security. As with quality management systems, the idea is to give management a means of controlling information security management processes systematically such that they can be continually monitored and improved, not least because perfect security is an unattainable goal in any real world situation.
- Conduct a pre-certification assessment - when the ISMS has stabilized, an accredited certification body or other trusted, competent and independent advisor is invited by management to check whether the ISMS is functioning correctly. This is largely a compliance assessment but should ideally incorporate some independent review of the scope, the SoA and RTP to make sure that nothing important has been missed out of the ISMS, especially as the business situation and information risks have probably changed in the months or years that it will have taken to implement the ISMS. It is a golden opportunity for your organization to identify and tie up any remaining loose ends before the actual certification audit. It’s also a good low-impact way to get to know the auditors.
- Certification audit - when management is happy that ISMS is stable and effective, they select and invite an accredited certification body to assess and hopefully certify that the ISMS complies fully with ISO/IEC 27001. The auditors will check evidence such as the SoA, RTP, operational artifacts etc. and will attempt to confirm that the ISMS (a) is suitable and sufficient to meet the organization’s information security requirements in theory i.e. it is correctly specified; and (b) actually meets the requirements in practice i.e. it is operating as specified.
- Party party - seriously, getting certified marks the end of the implementation phase, a substantial milestone for the team and the organization so celebrate your success. You’ve earned it! More than that, your ISO/IEC 27001 compliance certificate is a valuable asset. The organization should be proud of what it has achieved, knowing of course that information security is never really “done” ...
- Operate the ISMS - it should be business as usual now. Other things to consider as your ISMS settles becomes routine and gradually matures include (1) taking a good look at the information risks and security arrangements in place elsewhere in your business network: are your suppliers, partners and customers also certified? Are they certifiable? Do they need your encouragement? (2) Using and maturing your security metrics to continue identifying and making improvements. (3) (4) If you haven’t already done so, please join the ISO27k Forum to share your experience with others and participate in the global community.
Implementation tip: genuine management support is the sine qua non. Time invested in explaining to managers what the ISMS is and more importantly how it benefits the organization is time well spent. At the same time, listen hard to find out what managers really need from information security and pick up opportunities for strategic alignment. If the ISMS supports or enables key business objectives, it is less likely to be seen as an impediment to progress, and is harder for reluctant managers to resist.
Q: “Will the security controls we have already implemented be sufficient for the final ISO 27001 certification?”
A: Unlikely, unless your organization already has a full suite of mature good practice security controls, supporting a comprehensive ISMS! Controls already in place won’t be wasted but (in my experience) some will probably need improvements, most likely documentation for a start and probably some extensions to cover the entire breadth of ISO/IEC 27002. Identifying and initiating any necessary security improvements is the first step towards a true self-sustaining ISMS. This process will eventually become a routine part of your ISMS.
Implementation tip: look for alignment between internally-driven information security requirements (particularly those that directly support the organization’s business and risk management objectives) and those imposed by compliance obligations such as SOX, PCI DSS, privacy laws etc.
FAQ: “Are there levels of compliance with ISO/IEC 27001, or are organizations simply compliant/noncompliant?”
A: In reality, there are ‘degrees of compliance’ with ALL laws, rules, regulations and standards ... but not as far as the laws, rules, regs and standards themselves, and perhaps the authorities normally behind them, are concerned. ISO/IEC 27001 for instance is worded as if organizations absolutely must without any dispute fully comply with all its core mandatory requirements concerning the management system. The intention was to leave no wiggle-room.
When certifying an organization in practice, however, the certification auditors will accept all the management system elements or processes that are clearly fully compliant with the standard, and will consider and discuss with management any aspects that are not quite so clearly or fully compliant, before making a decision as to whether or not to issue the certificate. At the end of the day, the certification auditors must decide whether the standard’s requirements are satisfied sufficiently to issue or renew a certificate.
Implementation tip: aspects of the standard that seem most challenging are likely to be the ones that the organization needs to put most effort into getting right prior to the certification audits. The auditors may probe more deeply into those same areas if there are concerns, but occasionally organizations are tripped up by things that seem relatively straightforward or easy: this is where the auditors’ independence and competence come to the fore. Experienced auditors know the standards well and see many organizations struggling with various aspects, so they can often spot issues and maybe even suggest solutions that the organizations themselves may fail to see.
FAQ: “Who can certify us against ISO/IEC 27001?”
A: Anyone. You can even do it yourself! However, the certificate only has real meaning and value if it is issued by a recognized Certification Body (CB - also known as registrars etc. in some countries), which in practice means they should have been accredited by a recognized accreditation organization. “Accredited” means their certification practices have been checked to ensure that the certificates issued are legitimate, trustworthy and meaningful. If compliance certificates were issued by anyone who felt like it, the certificates and potentially ISO27k as a whole would soon lose value and be discredited. The formality in the process builds and maintains confidence and trust. The accreditation process (i.e. checking that CBs are competent and suitable to assess clients against ISO/IEC 27001) is itself the subject of ISO/IEC 27006.
Aside from CB companies, individual auditors may be accredited by bodies such as the International Register of Certificated Auditors (IRCA). They generally work for large consultancies or system integrators, though some are self-employed or work in small companies.
Implementation tip: find your national accreditation body or bodies listed here. Contact an accreditation body for details of the CBs they have accredited in your area. Read on for advice on choosing between the CBs ...
FAQ: “How do we choose a Certification Body?”
A: Choosing a CB is like selecting any service supplier, so you should follow your standard vendor selection, procurement and contracting practices. In short, figure out what you want (your criteria), review available service offerings on the market against the criteria, select the best fit and then make the purchase.
These are examples of the kinds of criteria you might consider:
- Vendor quality, standing, reputation etc., in particular their accreditation status (see below);
- General vendor selection criteria such as their ethics, policies and practices for health and safety, equality, corporate responsibility, environment etc.;
- Technical competence, qualifications and experience of the ISMS auditors they will actually assign to the job;
- Their working practices, procedures etc. (e.g. will they permit your ISMS internal auditors to shadow and support their auditors?);
- The quality, breadth and utility of typical/example/sample/template reports and other outputs (aside from the formal compliance certificate, you may for example find value in the completed assessment checklists or improvement suggestions and advice from the CB auditors if they will share them with your management or ISMS internal auditors);
- Value for money (there’s more to this than price!);
- Availability e.g. timescales within which they can complete the job;
- Past performance e.g. previous jobs for your organization, credible customer references, or suggestions from industry peers, local contacts or other auditors and trusted advisors;
- Their information security and privacy arrangements (see further below);
- Other factors - develop your own unique criteria.
You may prefer to prioritize or weight your criteria and prepare a scoring spreadsheet, but it’s hardly worth the effort for such a simple activity with, probably, a rather limited shortlist of candidate suppliers from which to select. Check the vendors’ marketing and sales collateral though, as differences in their proposed approaches to the job may help you choose between them.
The accreditation status of your chosen CB is important if you are expecting your ISO/IEC 27001 compliance certificate to be credible to, and hence trusted by, third parties such as your suppliers and business partners. Anyone can issue you with a compliance certificate - you can even self-certify if you like, or ask your implementation partners for one - but third parties who will rely on the certificate normally insist on certificates issued by CBs that are independent, competent and trustworthy. In practice, this means the CB must have been properly accredited by trustworthy bodies such as the UK Accreditation Service (UKAS). To be accredited by the likes of UKAS, CBs are formally assessed or audited against applicable, internationally recognised standards regarding their competence, impartiality and capability. Accreditation reduces the possibility of selecting an incompetent CB, and increases the value of the certificate. Oh and by the way, don’t forget to confirm their actual accreditation status with the accreditation body, as anyone may claim to have been accredited.
ISO/IEC 17021 lays out the principles and requirements for the competence, consistency and impartiality of the audit and certification of management systems of all types (such as management systems for quality, environmental protection and information security), while ISO/IEC 27006 offers additional, more specific advice for ISMS CBs.
Information security should be one of your CB selection criteria. It is not unreasonable to assume that ISMS auditors should have the professional knowledge and expertise to protect your sensitive information, but since they will be given privileged access to your organization's ISMS (and perhaps to the facilities and other assets) you need to assess the risks and treat them in the normal way. Its up to your management to determine whether these risks are material in relation to the information risks associated with other suppliers, business partners, customers etc., and other risks, and so whether and how to treat them.
Legitimate, accredited ISO/IEC 27001 CBs are forbidden from auditing customers of their ISMS-related consultancy services in order to avoid the obvious conflict of interest. Your ISMS implementation consultants and advisors may, however, be able to help you find and select suitable CBs if you wish.
Implementation tip: at the very least, be sure the contract with your chosen CB incorporates a suitable nondisclosure, confidentiality or privacy clause. An ISMS CB can hardly object to you taking an interest in their information security arrangements after all, and they might just give you credit for asking!
FAQ: “How does the certification process work?”
A: The ISO/IEC 27001 certification process is essentially the same as that for ISO 9000 and other management systems. It is an external audit of the organization’s ISMS (Information Security Management System) in three main phases:
- Pre-audit - having engaged an accredited certification body, they will request copies of your ISMS documentation, your policy manual etc. and may request a short on-site visit to introduce themselves and identify contacts for the next phase. When you are ready, they will schedule the certification audit itself by mutual agreement.
- Certification audit - this is the formal audit itself. One or more auditors from the accredited certification body will come on site, work their way systematically through their audit checklists, checking things. They will check your ISMS policies, standards and procedures against the requirements identified in ISO/IEC 27001, and also seek evidence that people follow the documentation in practice (i.e. the auditors’ favorite “Show me!”). They will gather and assess evidence including artifacts produced by the ISMS processes (such as records authorizing certain users to have certain access rights to certain systems, or minutes of management meetings confirming approval of policies) or by directly observing ISMS processes in action.
- Post-audit - the results of the audit will be reported formally back to management. Depending on how the audit went and on the auditors’ standard audit processes, they will typically raise the following (in increasing order of severity):
- Observation - information on minor concerns or potential future issues that management is well advised to consider;
- Minor noncompliance - these are more significant concerns that the organization has to address at some point as a condition of the certificate being granted. The certification body is essentially saying that the organization does not follow ISO/IEC 27001 in some way, but they do not consider that to be a significant weakness in the ISMS. The certification body may or may not make recommendations on how to fix them. They may or may not check formally that minor noncompliances are resolved, perhaps relying instead on self-reporting by the organization. They may also be willing to agree a timescale for resolution that continues beyond the point of issue of the certificate, but either way they will almost certainly want to confirm that everything was resolved at the time of the next certification visit;
- Major noncompliance - these are the show-stoppers, significant issues that mean the ISO/IEC 27001 certificate cannot be awarded until they are resolved. The certification body may recommend how to resolve them and will require positive proof that such major issues have been fully resolved before granting the certificate. The audit may be suspended if a major noncompliance is identified in order to give the organization a chance to fix the issue before continuing.
They will also issue your certificate of course, assuming you passed the test!
Following the initial certification process there are periodic follow-ups (usually called “surveillance audits”, sometimes CAVs “Continual Assessment Visits”) for as long as the organization chooses to maintain its certification. The certificates are valid for three years so there is a formal recertification every three years, but these additional interim reviews are common, especially in larger organizations.
Implementation tip: like exams, certification audits get more familiar if not easier with practice. Treat readiness reviews, internal audits and pre-assessment reviews as opportunities to learn about the audit process as well as sources of information about areas needing improvement, prior to the main certification audit. During and after the process, talk to managers and others involved in the process about how things are going, and share any good news. We’d love to hear how it went on the ISO27k Forum for instance! Treated sensibly, the external reviews are all valuable opportunities to confirm that your ISMS remains effective, and to pick up benchmarking tips from the consultants and auditors with experience of other compliant organizations.
FAQ: “Do we need to address or achieve all of the control objectives in ISO/IEC 27002?”
A: Not necessarily for certification. Remember that organizations are certified against ISO/IEC 27001, not ISO/IEC 27002. While compliance with the main body text of 27001 (the bits concerning the management system) is considered mandatory for certification, the control objectives in annex A (the bits concerning information security, summarized from ISO/IEC 27002) are optional: organizations choose whichever of those security control objectives they deem relevant and necessary to address their information risks, then select the security controls (or indeed other risk treatments e.g. avoiding or transferring some risks) that they feel are applicable. As well as not necessarily selecting the whole of annex A, organizations may well introduce additional control objectives and controls, including those from other standards, laws, regulations and good practices. It’s a flexible approach that caters for quite different organizations and risks.
Strictly speaking, certification does not even depend on the organization fulfilling all the security control objectives that it has selected, just so long as the management system complies with the requirements of ISO/IEC 27001. It is presumed that a compliant ISMS will successfully ensure that the security control objectives will be satisfied in due course, and indeed this is in the organization's interests, regardless of certification, since failing to meet those objectives implies a failure to mitigate unacceptable risks.
Implementation tip: be careful when scoping your ISMS, considering your information risks and selecting applicable control objectives, because there are costs involved in meeting those objectives. The ISMS may encompass additional control objectives beyond those listed in the SoA, no problem, but must ensure that the listed objectives are addressed. Information security professionals tend to want to include and manage all the security objectives and controls, but the business is likely to be most concerned about a smaller subset, implying a useful focus that can be used to prioritize the essential elements.
FAQ: “This is all very complicated and uncertain. There are so many variables! Isn’t there just a simple checklist we can follow, like PCI-DSS?”
A: No there isn’t. Protecting an organization’s information assets is inevitably a complex challenge, considering that there are so many possible threats, vulnerabilities and impacts, so many assets to protect, so many factors to take into consideration.
PCI-DSS (the Payment Card Industry Data Security Standard) has a narrower scope than ISO27k, purely concerning the IT systems and processes for handling credit and debit card data, but even there it could be argued that the prescriptive checklist approach is patently inadequate (witness the number of significant card date breaches in the headlines, affecting organizations that had evidently passed their independent PCI-DSS compliance audits). Achieving and maintaining PCI-DSS compliance may seem like a substantial challenge for many organizations but in reality, PCI-DSS is barely adequate for its intended purpose. It mandates a basic, minimal suite of information security controls, some of which are known to have significant flaws (e.g. WEP, not recommended but still permitted under version 1.2 of PCI-DSS). Bare PCI-DSS compliance may be sufficient to get the QSA auditors off your back but it is not enough to protect all your valuable information assets.
An effective ISO/IEC 27001 ISMS using a comprehensive suite of controls drawn from ISO/IEC 27002 (and/or indeed other security standards such as SP800-53 FISMA) should satisfy and in fact exceed PCI-DSS and other externally-imposed security compliance obligations, while simultaneously generating additional business benefits through satisfying internally-derived security requirements (e.g. protecting valuable but sensitive proprietary data against damage or unauthorized access by competitors).
Implementation tip: 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 need to identify and protect all your information assets against all significant security risks. If you examine the costs and benefits honestly, investing in a comprehensive security management system is the most professional and effective way to deal with this.
You can start by restricting the scope of your ISMS to certain business units, functions or departments. This simplifies the problem space somewhat and gives 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.
FAQ: What if things change after we are certified?
A: That depends on the nature and scale of the change. Relatively small changes to the ISMS are expected to occur as it naturally evolves in line with changing business needs for information security, for example through the action of various internal reviews triggering corrective and preventive actions: these should have no effect on your certification status since they are an anticipated and normal part of any ISMS. Larger scale business or organizational changes may involve significant changes to the scope of the ISMS, for example other parts of the business being integrated with the ISMS, mergers/acquisitions or downscaling/divestments: these may be substantial enough to invalidate your original certificate without at least a surveillance visit from your certification auditors, but it's impossible to give hard-and-fast rules. Whether your ISMS changes are deemed substantial enough to invalidate your certificate, or to warrant recertification, depends on several factors such as:
- The scale or size of the change/s;
- The nature or type of change/s;
- The likely impact of business and organizational changes on your ISMS and/or information risks and hence risk treatments required;
- How long it has been since your last certification or surveillance audit, and how long before the next one; and
- The certification body's policies and practices in this regard.
Aside from the certification angle, you should definitely update your information asset and information risk/control registers and maybe your Statement of Applicability. You may need to update your security policies and perhaps restructure the team managing and running the ISMS, which may well imply the need for a new budget. Don’t forget to check your ISMS internal audit plans too, and if appropriate adapt your metrics to take account of the full ISMS.
Implementation tip: arguably the best advice is to stay in touch with your certification body, keeping them updated with (significant) changes and giving them the opportunity to say whether further surveillance visits or compliance audits are in order. Building a good working relationship with your auditors has the distinct advantage of "no surprises" on both sides, but it takes a little effort to establish and maintain the relationship, as indeed do all relationships (business or otherwise!).
FAQ: “What do we need to do in preparation for a re-certification audit?”
A: Unlike the six-monthly or annual surveillance audits which tend to focus on specific areas, a re-certification audit will give the entire ISMS a thorough once-over. Since your ISMS has been in operation for some time (at least 3 years), the auditor will expect to see a mature ISMS that is nevertheless moving forward, proactively responding to the inevitable changes using the PDCA/continuous improvement processes embedded in the ISMS.
This is a formal audit and can be tough for organizations that have let their ISMS drift or decay after the elation of their initial certification. Re-certification is not a forgone conclusion! The audit’s prime focus will, of course, be to confirm strict compliance with the current version of ISO/IEC 27001. The key issue is that you still have an effective and compliant management system to manage your information security.
Use this simplified 8-point checklist as a basis for planning the main things you need to get done before the auditor turns up (you will probably need a more elaborate and comprehensive plan):
- Check that your ISMS internal and external audits are fully up to date, with plans in place for future audits. Are all audit findings/observations, recommendations and agreed actions either completed and closed off, or currently in progress (with clear signs of that actually happening, in practice)? Use the results of recent audits to drive forward any necessary changes and to reinforce the concept that the audits are all about making justified improvements. (It is worth double-checking that any other similar audits covering information risks, controls and compliance are also addressed.)
- Collate evidence of continuing management commitment to the ISMS such as minutes of management committee meetings, decisions and actions taken, preventive and corrective action plans and the results of follow-up or close-out actions, and budgets.
- Complete a full management review of the ISMS, including your Statement of Applicability and Risk Treatment Plan. Document all findings and recommendations as preventive or corrective actions and ensure all actions are suitably initiated, allocated and managed. Try to get all significant issues closed off, or at least well under way, before the audit.
- Review your information risks. If there have been significant changes in the external business environment (e.g. new legal or regulatory compliance obligations, new ISO27k standards, new security partners), internal situation (e.g. reorganizations) or IT (e.g. new platforms and application systems), redo your information risk assessment from scratch using the documented methods, and update your RTP. All risks should be treated, in other words avoided, controlled, transferred or explicitly accepted by whoever is accountable and, for significant risks, there should also be contingency plans in place in case the mitigating controls fail.
- Review all the ISMS documentation (policies, standards, guidelines, procedures etc.) to ensure it is up to date, complete, formally approved/mandated/signed off, version controlled and made available to those who need it (e.g. uploaded into the ISMS area on your intranet). Ruthlessly seek out and destroy old or outdated ISMS documentation.
- Get your information security awareness and training activities right up to date and ensure a plan is in place for future activities. Ensure everyone knows where to find the ISMS policies and related materials and is aware of the content (a useful tip is to give everyone a shortcut to the information security documentation on their desktops). Ensure everyone is familiar with, and in fact actively complies with their responsibilities towards information security, for example any obligations arising from privacy legislation and relevant information security procedures.
- Check the documentation relating to any recent information security incidents, for instance to confirm that corrective/preventive actions were documented and duly completed. Step back from the detail to confirm that the process is operating smoothly.
- Review your information security metrics. Given that your ISMS has matured, are they still relevant and useful or do they need adjusting? Have you in fact been reporting and measuring against them (collate recent evidence to prove it) and have any actions necessary been taken (again, check the preventive and corrective action plans)?
Get yourself round each area of the business and grill likely audit interviewees (both managers and staff) regarding their part in the ISMS. Ask them some searching questions (try the auditors’ favorite “Show me...” to check that they can actually produce solid evidence substantiating what they claim) and try to find where the weaknesses are before the auditor finds them - not to hide them but to address them! This is invaluable preparation or training for the auditees. Tell them up front that you are not being harsh with them but are asking stiff questions to help them prepare and make the actual re-certification audit go more smoothly.
Implementation tip: email employees shortly before the recertification audit reminding them of their responsibilities towards both information security and the ISMS audit. Give them information and tips on how to conduct themselves during the audit (‘Be frank, be open, be honest and use the policies, procedures, records and other documentation to demonstrate what you do’). This is a classic security awareness opportunity!
Remember that the ISMS is a living thing, constantly adapting to changing business needs arising from evolving information risks. It will never be perfected or finished as such but, so long as it is properly managed, reviewed and fully supported by management and indeed other employees, you will be fine. Good luck!
< Previous FAQ section FAQ index