Key scoping factors when pursuing ISO 27001 certification

Jimmy Dilz, Senior Consultant, ISO Assurance, Coalfire

Service providers that seek the most recognized implementation of an information security baseline and governance structure should consider the ISO/IEC 27001:2013 (“ISO 27001”) standard. The information security management system (ISMS) prescribed by this widely adopted publication engages personnel at every level of an organization to ensure information security-focused processes and controls are implemented, maintained, and continuously improving. Rather than focusing solely on the establishment of information security controls, the ISMS challenges service providers to first consider risks and then develop processes that enable an effective control environment.

To reap the benefits from an ISMS – and to avoid wasting valuable personnel capacity and monetary resources – management should engage in targeted scoping discussions prior to initiating development activities. A proper understanding of ISMS scoping factors and considerations should result in a beneficial initiative that meets the needs of the organization and its intended users.

ISMS scoping – where to start?
The ISO 27001 standard offers extensive scoping flexibility. The service provider implementing the ISMS is responsible for scoping its management system and for identifying the people, processes, systems, applications, and facilities to include in that scope. As part of this flexibility, the service provider is permitted to carve out functions of the business that will not interact with the ISMS, as well as indicate areas where responsibilities may be partially transferred to other parties, such as a public cloud provider.

Scoping discussions should focus on determining the key functions for developing, operating, or securing the critical systems, service offerings, and processes of the organization. The scoping exercise can begin broadly across a multitude of locations, but scoping factors may then be applied to narrow and refine the scope to provide maximum value.

What are the scoping requirements prescribed by the standard?
The standard includes a few required considerations for establishing scope. The first of these requirements is to evaluate the impetus behind the ISMS initiative. The drivers for implementing an ISMS may include customer requests for certification, identified revenue growth tied to ISMS certification, reduced response time to vendor questionnaires, or a push for the Board of Directors (BoD) to implement leading information security governance practices. The ISMS pursuit likely has clear internal and external issues that could inform the scoping evaluation.

After determining drivers for the ISMS implementation, the next requirement is to consider the internal and external parties that are interested in the success of the ISMS. These may include the service provider’s employees, BoD, investors, and current or prospective customers, as well as regulatory bodies. It is important to solicit feedback from interested parties to ensure the ISMS scope meets the needs and expectations of these stakeholders.

Lastly, the ISO 27001 standard requires the consideration of both internal and external interfaces and dependencies to the ISMS. These factors are critical, especially for organizations that plan to carve out organizational functions and rely on third-party tooling or infrastructure for development operations, systems hosting, or control operation. Internal interfaces and dependencies include departments that support key operations of the ISMS, such as in a control ownership or budgetary capacity.

Human resources (HR) and sales teams are common internal interfaces and dependencies. While HR may not directly interact with critical systems, applications, or processes typical of an in-scope department, they do engage in control activities such as onboarding personnel, facilitating security awareness training, establishing management responsibilities, and enforcing disciplinary actions for information security violations. Similarly, the sales department interfaces with the ISMS through its customer engagement role. Sales team members are responsible for appropriately representing the ISMS scope to customers. They are commonly viewed as a risk for unintentionally alluding to conformity to ISO 27001 for the entire organization when only a sub-set of the company’s functions or locations are certified via third-party inspection.

External interfaces and dependencies include public cloud providers, colocation facilities, ticketing systems, intranet solutions, and identity and access management offerings utilized by the service provider. These auxiliary vendors may interface with the ISMS via hosting responsibilities or tooling solutions deployed in the service provider’s control environment (e.g., a ticketing solution that supplements the change management process). By considering interfaces and dependencies, management can identify the service provider’s responsibilities and the activities transferred to other parties under a shared responsibility model of micro-tasking that supports control design.

ISMS drivers, interested parties, and interfaces and dependencies should all be documented for periodic evaluation. Each factor introduces nuanced considerations for establishing the ISMS scope and can act as an effective “stress test” for management when determining whether the scope is broad enough prior to resuming the establishment of the ISMS.

Are all offices required to be in scope?
The ISO 27001 standard does not impose prescriptive physical site requirements as an inclusion to the scope of certification. In fact, there is no requirement for an organization’s headquarters to be included in scope for the ISMS. Moreover, the service provider determines the office locations, data centers, or call centers to include within the ISMS boundaries while considering the drivers for certification, the needs of its identified interested parties, and its interfaces and dependencies. Interestingly, service providers with a fully remote workforce are not precluded from implementing a certifiable ISMS. It is uncommon, but there is flexibility to carve out physical locations altogether and maintain an entirely virtual scope of certification.

Organizations with highly centralized operations often include at least one physical site within the ISMS scope. The primary in-scope location is referred to as the “central office.” While the central office may be synonymous with an organization’s headquarters, it is not a requirement and could be representative of another critical site for the company, such as a regional hub or main IT site. Other factors for a service provider to designate a central office external to its headquarters may include the existence of information security operations or management representation at alternate sites.

The intention of the central office is to represent where centralized ISMS governance occurs. International Accreditation Forum (IAF) Mandatory Document (MD) 1:2018 defines the “central function” as being where operational control and authority from the top management of the organization is exerted over other sites. What this central function is for the ISMS should be carefully evaluated and locations that support it fully considered.

What sites are typically included in scope?
Management may elect to add sites to the scope based on the context of the organization and the needs and expectations of interested parties. Office locations that support central functions are commonly referred to as “satellite offices.” These may be included in the certificate scope when functions at the location support the ISMS, such as development operations supporting an in-scope application. Similarly, a service provider may consider data centers and call centers for inclusion in scope, though these sites often are outsourced and may operate independent compliance programs that suffice the needs of interested parties without the need to explicitly include them in the ISMS scope.

Adding sites to the scope is a business decision that should be based on risk and justified by additional value received because of the inherent investment. Service providers with international or highly dispersed operations are the most common candidates for a multi-site ISMS scope. The organization should always consider the auditing implications, in addition to the costs, before adding sites to scope. Certification bodies sample in-scope sites across the three-year certification cycle based on IAF MD 1:2018 guidance. Adding sites not only increases the number of sites to be visited, but it may also increase the organizational headcount used to calculate audit time, discussed in more detail below. Sites that are included in scope can be listed on the final ISO 27001 certificate award issued by a certification body. This conformity deliverable is then requested from interested parties or proactively shared as a method to demonstrate compliance as a differentiator.

Should colocation facilities or public cloud providers be listed as in-scope sites?
With myriad colocation facility options and the omnipresence of the public cloud, it is rare for a service provider to host critical applications on-premise. Rather, service providers are heavily dependent on their hosting and secure infrastructure vendors. Under the colocation and cloud models, physical and environmental security controls are managed by the infrastructure provider. Colocation vendors, such as Equinix and Digital Realty, maintain active compliance programs, including ISO 27001 certification that encompasses global operations, enabling them to handle requests from their external interested parties. Public cloud providers maintain the same – if not significantly more robust – compliance programs and continue to pursue new information security and privacy frameworks as they become available and adoption becomes apparent within the marketplace.

While there may be value in communicating the reliance of a colocation facility or the critical infrastructure provided by a cloud provider within the ISMS scope statement that is listed on a certificate award, a service provider may find an insufficient business case for also including these sites within its own inspection program. In fact, a public cloud data center location is prohibited from being formally listed as an in-scope site given that many of these facilities cannot be visited by a service provider’s external auditor. To test this, try to persuade Amazon Web Services to provide addresses for its us-east-1 region. While a colocation facility can be visited and listed in scope, the service provider should evaluate the needs of interested parties before committing resources to include the colocation site.

How do I determine organizational headcount?
Determining the appropriate in-scope departments and related headcount is critical for operating the ISMS, ensuring resources are available, and calculating onsite audit time requirements for certification audit activities. The starting point for calculating the in-scope headcount is the enterprise headcount, globally inclusive of all employees and contractors. From the enterprise headcount, management considers carved-out functions (i.e., functions not relevant to ISMS operation), interfaces and dependencies, and the in-scope locations to derive an organizational headcount – the true in-scope headcount utilized by certification bodies to determine level of effort.

The organizational headcount considers departments that operate the ISMS across in-scope locations. These departments may be involved in information security risk identification and treatment, information security control ownership, development operations, governance processes, or other functional areas affecting the ISMS. Full-time and contractor personnel who flow into identified departments at in-scope sites comprise the organizational headcount calculation. An important clarification is that departments categorized as internal interfaces and dependencies to the ISMS, discussed above, are excluded from organizational headcount, as these departments (e.g., sales) are not directly involved in the operations or continual improvement of the ISMS.

Organizational headcount should be carefully calculated. Certification bodies determine onsite audit time requirements per ISO/IEC 27006:2015 based on the organizational headcount value. Audit fees may increase with a rising organizational headcount due to increased audit effort. Determining in-scope sites and departments is a balancing act between meeting interested party expectations and reducing compliance costs in an effort to not “over-scope” the boundaries of the ISMS.

Conclusion
There are many factors to consider when refining a scope to best meet the intended purpose of the ISMS implementation. As a general rule, people, processes, applications, and sites should not be included in scope without first considering costs and expected benefits. Upfront time allocated to the scoping exercise should both minimize resource waste while maximizing the value of the resulting ISO 27001 certification.

Jimmy Dilz

Author

Jimmy Dilz — Senior Consultant, ISO Assurance, Coalfire

Recent Posts

Post Topics

Archives

Tags

Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS
Top