This post will pick up from clause 5. All the other parts of this series can be found here.
Clause 5 is titled Leadership. This is a bit of a red herring. It really should have been called Governance. What clause 5 is trying to ensure, is that senior management within the scope of the ISMS, have an active governance role and can allocate budget and resources appropriately in support of the ISMS.
Within clause 5.1, the term “Top Management” is introduced and not explained. The term can easily be misinterpreted for different scopes of ISMS. And this is where linking this section to Governance helps.
Top Management is a reference to the top of your Governance structure for the ISMS.
For a small company, this is likely to be the Directors of the company. For an SME (Small to Medium Enterprise) this might be a CEO. For a large Enterprise, it may be the CISO.
Top Management should be taken as the day-to-day accountable senior management for the operation of the ISMS. Essentially, who has been given accountability for Information Security to the Board of Directors of the company.
This “Top Management” may be a single person (e.g. a CISO) or in more complex organisations, it may be some form of Security Oversight Committee, made up of senior members of the organisation.
This is why the Governance bit is really important to get sorted right at the beginning.
You need to have a capability to fund the ISMS and make improvements to the ISMS. And you need to have risk approval for the ISMS risk mitigations that you may propose.
These two things may have different approval paths in your organisation. The funding may need to flow from the COO, whilst risk approvals may come from the Audit and Risk Committee.
From an ISMS Governance point of view, it is important to show that you have a set of governance meetings that escalate upwards for decisions until it reaches the appropriate sign off, and then flows back down through a set of operational meetings to implement those approvals.
Your leaderships commitment to this Governance process is basically what is being asked for in Clause 5.
Information Security Objectives
Clause 5.1.a lumps together Information Security Policy and Information Security Objectives, to the detriment of the Objectives. The Objectives should have taken priority as they logically come first.
Once you have figured out what the Organisation wants to achieve with the ISMS, you can then formalise that in a set of Information Security Objectives. This then becomes the charter that the ISMS has to work to. The Objectives are what will determine if the ISMS is working or not.
The Information Security Policy is a high-level way of turning those Objectives into things that the Organisation has to do. If the Organisation adheres to the Policy, then it will be moving towards achieving the Information Security Objectives.
Clause 5.2 states that an Information Security Policy should be established. Clause 5.2.b however seems to imply that the Policy can set Information Security Objectives, which is just bizarre. Your Policy set should be directed explicitly to achieving the Information Security Objectives of the ISMS. The creation of your Policy flows from the Information Security Objectives.
Clause 5.2.e states that your Information Security Policy should be documented information and it should be available to interested parties. The term “Documented Information” is a glossary term that means something specific to the standard that we will cover as part of Clause 7. I prefer the term, “Controlled Document”, which gives a better clue as to what you are trying to achieve. This means that the document should be actively managed.
This provides the ISMS with a decision point. You have a Policy set that should be accessible to external third parties (that is what the Standard states in clause 5.2.g), but it may contain confidential information that you do not wish to be disclosed.
There are a few possible options here.
- You could ensure that an Non-Disclosure Agreement or Confidentiality Agreement has to be in place to allow access to the policy set. This would protect confidential information in the policy set, but it is a blunt instrument as far as confidentiality control goes.
- A better option would be to not put confidential information in the Policy set in the first place. However, the further down you go in the Policy, Standards, Guidelines, Standard Operating Procedures hierarchy, the greater the likelihood is of requiring confidential information to be contained within the document. The Standard Operating Procedure for firewall rule changes most probably does need the firewall hostname and IP address in the document. Otherwise the procedure will not be prescriptive enough to get the job done.
So there is a balance to be drawn between what documentation is allowed outside the tent and what documentation is retained inside the tent.
This could be that policy documents are allowed externally to clients and third parties, but the rest of the document set is not.
This is a choice that the ISMS must make and approved through Governance. It may be different for various organisations depending on the visibility requirements of industry regulators and other interested parties. This is a real choice that needs to be made by the ISMS as all the Standard is looking for is a consistent approach and a rationale to be documented for that approach.
Clause 5.3- Roles and Responsibilities
This clause does very little to structure governance processes and to describe roles and responsibilities. It is left to the ISMS Manager to outline how ISMS Governance breaks down into a set of roles and responsibilities and how these are applied through the governance process for the ISMS.
The ISMS needs to show how decisions are made and recorded that impact the intended outcomes of the ISMS. This means how decisions are made at different levels of authority within the organisation and how those decisions are implemented.
An operational change to a control that does not require additional budget or resource, may be approved by your lowest Governance level. A significant change that requires additional budget and headcount is likely to need approval from your highest Governance level.
Clause 6 – Planning
The key elements to understand in clause 6 – Planning, are well hidden in a long list of risk management items and concerns. The two key elements in Planning are:
- You need to plan to implement the Information Security Objectives (6.2)
- You need to plan to integrate the ISMS into all of the existing relevant Organisational processes that will be modified by it. (6.1.1.e.1)
I will deal with risk management separately as it deserves its own post. I have never understood why it was bolted into Planning and not a clause in its own right.
In order to satisfy the planning elements of clause 6, you should end up with a resourced project plan of all the elements that need to be completed to get you to a minimum viable product ISMS. The ISMS will continuously be improved over its lifetime. What we need to understand in Planning is when will we be ready for certification. When will the ISMS be “good enough”? At what point will we have all the mandatory components in place such that we can achieve certification.
For this assessment, it is best to rely on your external auditor as part of a certification pre-assessment. Different auditors have different ideas on what is mandatory to achieve compliance and what can still be in the process of completion.
If you think this through, there will always be occasions where your controls are in flux. If you implement a new system, some of your controls may need to change and there will be a period of adaptation before your ISMS controls are back to full force.
This is an additional element that really should be in clause 6 under Planning, but is not there today. Best practice would require that as part of change management, consideration is given to how the ISMS itself may need to be adapted as a result of a change.
Significant changes to the Organisation
Take for example a major change such as the implementation of a new HR system. The adoption of this new system may fundamentally change the controls applied by the ISMS in this area. Some old controls may no longer be possible, and some new controls may now be available for consideration. This activity needs to be planned within the ISMS to intercept the new system implementation.
You need to run through your plan with the external auditor and agree when it would be acceptable to go for certification, given your control implementation schedule. The auditor may highlight a particular control that they want in place and you may have to juggle the plan to bring that control forward. But your auditor’s opinion here is crucial as every auditor does it slightly differently.
The general guidance should be that if you have nailed all of clauses 4-10, then all the other controls in Annex A could be considered discretionary in the plan of implementation. Clearly, they cannot all be on the floor, but no control individually is any more important than any other control. Your planning for control implementation will give your external auditor confidence that you have an appropriate distribution of initial controls and a plan to enhance these over time.
Basic tips for an Effective Audit
- Take extra care if your auditor is swapped out at the last minute for the certification audit. You would have spent a significant period of time convincing the initial auditor that you know what you are doing, and the new auditor may have a different view entirely. Retain minutes of auditor meeting religiously, as you may need to show a new auditor why you have done something in a particular way. If you can show this was previously agreed with your original auditor, you have some leverage.
- Take extra care if the auditor brings a junior as part of audit training. The junior is there to impress and is likely to spot all sorts of small points that you may have got away with otherwise. Particularly during the guided tour of the workplace.
- Take extra, extra care if the auditor is being re-certified themselves as part of your certification audit. Each auditor has to be regularly re-assessed as part of their ongoing certification to be an ISO auditor. The auditor will be out to impress their certification body and this will take priority over what you are trying to achieve. Stones will be lifted. Details will be examined. Problems will be found.