We are working towards the transition to ISO 27001:2013 , but they are having problems trying to understand this: We are writing a new Information Security Policy to be used for the whole organization, but I like to keep the ISMS scope just for one system, the one thats is required to be certified ISO 27001. Is this possible?, Can we have a narrow ISMS scope but an Information Security policy for the whole organization? The SoA is extended to include all controls in the annex A, here is my problem, I like to keep the SoA aligned with the scope and they want to all controls marked as applicable even if they are not used in the system in the scope.
Having Information Security Policy that covers a much wider scope than the one specified in the ISMS Scope document is absolutely possible - you just have to make sure that everyone in the ISMS scope complies with all rules defined in the Information Security Policy.
You have to be careful with Statement of Applicability - basically, it should refer only to controls that are applied wit hin the ISMS scope. If you have controls that are marked as applicable and they are not implemented in your ISMS scope, then a certification auditor will raise a nonconformity.
Over the idea to keep SoA aligned with the narrowed scope, I also need to split the ISMS policy in two document; the ISMS policy with a generic over arching scope and the ISMS scope defintion document?, the issue here os the business requires a very small part of the organization certified against ISO 27001, but we want to have all security controls managed under that standar; so we are producing a Information Security Policy aligned with the ISO 27001:2013 and I am producing a transition plan from the old ISMS to the new ISMS; but I find hard to avoid the inclusion of everything else in the certification process.
So far I have these documents
- ISMS policy
- ISMS Scope definition
- Inforformation Security Policy, and
Just to clarify the terminology first: ISO 27001:2013 does not require an ISMS Policy any more - the top-level policy in ISO 27001 is now called an "Information security policy".
So basically, if you plan to certify smaller scope than the whole ISMS policy or Information security policy, you should have the following:
1) Information security policy (top-level policy) - it can cover the wider scope than your ISMS scope
2) ISMS Scope definition - of course, it has to describe the ISMS scope precisely as you will certify it
3) Statement of Applicability - it should cover the controls for your ISMS scope only
4) Other information security policies (e.g. Classification policy, Backup policy, Access control policy) can cover the wider scope than your ISMS scope
Can you clarify point number 3 regarding the statement of applicability. Our business unit is ISO27001:2005 certified as it's a mandatory requirement because of the business we are in. Our shared services (IT, HR etc) which is part of our company are not certified yet so we treat them as external suppliers. The certificate auditor has always had issues with this IT relationship because they are not certified. For the transition to 2013 I have these external suppliers in the SOA as 'In scope but performed by a shared supplier. This way I can manage the relationship with the suppliers as the IT department provide all the IT hardware, network services, anti-virus protection etc to us and this gets cross charged. They have their own risk assessment using the same methodology as we do and we check they have procedures in place that are relevant to the controls in the SOA. Is this the correct approach or should any IT related controls be removed from the SOA as they are not officially part of the scope of registration?
I'm not really clear whether you have included your shared IT and HR services in the scope or not? The ISMS scope needs to be defined in the ISMS Scope document, or some similar document for that purpose.
If you did include those IT and HR departments in your scope, then you should include the controls you implemented in those departments in your Statement of Applicability; if those departments are not in the ISMS scope, then you should not include their controls in the SoA.
Thanks for your reply Dejan.
This is what we are trying to figure out as part of the transition and has always been an issue with the external auditor. Our certificate only covers our business unit as so does the scope. We have service level expectations for the IT department who provide us with all the network services of which we cannot function without. This covers about 50 of the controls mentioned in the SOA. Are you saying that we only need the 20 controls that are directly related to our business unit and not include the other controls like HR and IT that we rely on for our infrastructure and employment services? The auditor already struggles with the fact that IT are not certified.
If I understood well, ca 50 controls you marked as applicable, and they are implemented not by your business unit which is within the ISMS scope, but by a business unit that is outside of the scope.
In such case you should still mark those 50 controls as applicable in your Statement of Applicability (since those controls are obviously needed because of the risks), however when describing the implementation method for each control in the SoA, you should mention that those controls are executed by a third party (in your case the business unit outside of the scope).