Defining your ISMS scope (Information Security Management System) is one of the most important and basic requirements for implementing the ISO 27001 standard. While it looks like a straightforward requirement, many organizations get it wrong and as a result, get into more trouble than they bargained for.
What is ISO 27001 scope?
ISO 27001 scope is an important element of any ISMS.
It encompasses the whole ISO 27001 certification and what information, services and subsidiaries need to be protected. For example, a SaaS platform that manages health information for pharmaceutical companies may have a scope that covers the design, maintenance, sales and marketing processes of such a system.
According to the requirements of ISO 27001, the ‘scope’ defines all the information and processes that you intend to protect under ISMS. It doesn’t matter where this information is stored, how many users have access to the information, or how regularly it is updated and backed up. Once you include the information in the scope, it comes into the ambit of ISMS.
Defining the scope is important if you want to get the ISO 27001 certification. The auditor will typically verify whether all the information defined in the scope is duly protected via the elements of your ISMS.
Defining the scope will also help you understand the below security standards and compliance.
What happens when you set a narrow scope?
Companies seem to think that if they keep the scope narrow, it will help them achieve compliance easily. However, that’s far from the truth.
First of all, auditors don’t quite appreciate a narrow ISMS scope. In addition to this, a narrow scope will create too many interfaces to the outside world. And these interfaces will be other departments within the same organization, causing unnecessary overheads and conflicts.
For instance, if you choose that only Department A is in the ISMS scope, every other department becomes an interface. This means every interaction with every other department must be then treated as an interaction with an external supplier. This is not only cumbersome but also difficult to achieve especially when workers in these departments share the same physical space and access the same local network.
Imagine jumping through hoops just to get information to and from the person sitting five cubicles away from you! To ensure seamless information transfer and exchange between the internal departments, avoid building a limited scope that only covers a small part of the organization.
While in some organizations, it might be possible, in most cases, it is just not practical to treat every department as a separate entity. In the long run, achieving and maintaining compliance will be too much of a headache.
The laws, regulations, and guidelines that all stakeholders need to adhere to
- Interfaces and dependencies on other systems, departments, or external parties.
- Business processes and measures to ensure information security
- Internal and external security vulnerabilities that need to be managed.
- Defining the scope will not only help you understand compliance and security better, but it will also help you to demonstrate the establishment of security strategy effectively.
What is the best way to define the ISMS scope?
Even though at the onset it might seem like too much work, extending the ISMS scope to cover the entire organization is the best way. This simplifies the compliance requirements. You need to treat as interfaces only those stakeholders who can actually be considered as belonging to the ‘outside world’ such as external suppliers, clients, partners, etc.
For smaller companies, covering the entire organization is a good idea. Ideally, if you have a few hundred employees and office spaces in one location or a few separate locations, you should include the entire organization in the ISMS scope.
If it is not possible for you to include the entire organization in the ISMS scope, the least you can do is compartmentalize departments that can function independently to a large extent. You will then need to define the relationships of these compartmentalized units through internal documents such as policies, standard procedures, etc. These documents can serve as agreements to specify a unit’s obligation towards compliance in day-to-day operations.
Here are some important considerations for defining the ISMS scope.
1. Identify critical processes to define security policies and goals.
Remember that information security is the primary aim behind ISO 20071 certification. Review the business model to identify business-critical processes, systems, assets, and data.
2. Take into account the physical location details.
When you use office space, the physical security of the assets also falls under ISMS. If you have multiple locations, you need to account for them in the scope as well.
3. Define the interfaces and dependencies.
This can be internal but disparate departments or external stakeholders such as clients, partners, vendors, etc. with whom you might exchange information.
4. Consider integration with other certifications.
If you have other compliance certifications, consider aligning and integrating them with the ISO 20071 certification.
5. Identify supportive processes.
If there are any additional processes that are outside of the internal department, but critical to your business operations, they also need to be considered.
In today’s transient environment, systems, applications, and technologies can all undergo change. The security goals need to be evaluated at regular intervals along with a risk assessment and the ISMS scope needs to be reviewed to include these changes.
What are the benefits of defining ISMS scope?
A well-defined scope helps you align your business goals with security goals. It will help foster more effective security practices in your organization. And of course, it will be the right start to your efforts towards getting the ISO 20071 certifications. Read more about getting the ISO 20071 certification in The Complete Guide to ISO 27001.
Once you have defined the scope, you will also need to document the scope. This will include the organization’s context, the stakeholder details, information security measures being employed, and laws and regulations for security.