As it relates to audit, scope refers to all the components that are included in the audit. This can include but is not limited to:

• data,
• information, 
• software/tools, 
• personnel, 
• resources, and 
• documents. 

The audit scope, ultimately, establishes how deeply an audit is performed. The scope is used to define the boundaries of the audit and will likely include a Company’s core product, the data ingested by that product, and any supporting personnel, tools, and services.

Why is scope important? 

Scope is important because it determines what is “fair game” for the auditor to look at, ask about, request, and dig into. There’s a temptation to make the scope as small as possible to limit evidence requests, however it is more critical that the scope is accurate than small. 

How scope is determined and who should be in scope?

Whoever is leading the compliance and readiness efforts for a customer/company should determine the scope. Scoping must be done at the very beginning of your audit readiness journey so that you can properly prepare for your audit and provide accurate evidence. It is recommended to confirm scope with your auditor as soon as communications begin with them to ensure everyone is on the same page and there is no scope creep. Scopes should be adjusted if changes occur to personnel with access to customer data and/or the tools and software where the data flows.

For SOC 2, scope is determined by customer data. Any tools/software where customer data resides, moves through, or is stored is in scope. Any personnel that have access to customer data are also in scope.

For ISO, an org-wide scope is ideal if possible. It doesn't need to be determined if everything is in an information security management system (ISMS) or not. All people, processes, and tech that go into the service or product are in scope.  

Which tools/software need to be in scope? 

If customer data passes through or is contained in a tool or software, then it should be in scope. This will likely include:

• Any product(s) that the company has developed.
• Any supporting version control tools and deployment tools which carry source code and/or are used for code development (e.g., Github, Gitlab, Bitbucket, Azure DevOps).
• Any databases that hold customer data.
• Any supporting tools provided by the cloud service provider that are used to support the business (e.g., AWS, Azure, GCP tools).

Scoping personnel

Scoping does not change based on employment status. If the employee or contractor has access to customer/sensitive data then they are in scope. If any personnel have access to source code and/or the ability to deploy changes to production, they should be in scope as well. 

However, in the case of contractors the third party firm that hired them is responsible for ensuring their compliance with controls, not necessarily the company undergoing the audit. 

Framework-specific scoping guidance

The general guidance above is consistent across frameworks, however each framework addresses a unique type of data and relevant personnel. The types of tools/software that should be in scope will be determined based on what type of data they process, store, and/or transmit. This section includes more specific details about the systems that are relevant in each framework.

SOC 2

Customer data is unique and relevant to SOC 2. Any personnel, softwares, and/or tools which have access to, transmit, store, process, carry, or handle customer data are in scope for SOC 2. 

ISO

People, processes, or tech that go into the service(s) are in scope. If possible, an org-wide scope is recommended so there is no need to determine what is in ISMS or not. If an org does one product as a subsidiary, just that subsidiary is in scope. 

Additionally, any data deemed sensitive by the org could be in scope. This usually includes both customer and company data like IP or trade secrets). 

PCI

It’s important to determine if the customer is a merchant or service provider. Merchants vs service providers determine which type of Self-Assessment Questionnaires (SAQs) need to be completed for compliance. 

Merchants take payments directly for goods and services either via e-commerce, over the phone, or on-site with terminals. If an organization signs a merchant agreement with a back, they are definitely a merchant. 

Service providers impact the security of cardholder data by being involved in the processing, storage, or transmission of that data, but are not a payment brand. 

Then determine if the customer stores, processes, or transmits cardholder data. Any systems within or connected to the cardholder data environment (the network or systems that directly store, transmit or process cardholder data) are in scope. Any person that can view cardholder data or impact the security of cardholder data is also in scope.

HIPAA

HIPAA is applicable to covered entities, business associates and subcontractors who are storing, processing or transmitting protected health information (PHI). Any systems or personnel that have access to or hold that data would be in scope.

Covered Entities are either healthcare plans (e.g., insurance carriers, corporate health plans, HMOs, etc.), health care clearinghouses, and/or health care providers (e.g. hospitals) who electronically transmit any health information in connection with transactions for which HHS has adopted standards.

Business Associates are any individuals, vendors, or organizations that come into contact with a healthcare organization's PHI. Business associates typically work with covered entities to perform services, store, transmit, and/or process PHI.

Subcontractors are the entities that business associates use to process, create, or store PHI.

GDPR

GDPR is for any company, regardless of location, that collects EU citizen data. Any systems or personnel that have access to or hold that data would be in scope.

CCPA

CCPA is for any company that collects, stores, processes, or sells the personal data of California residents or has over $25M in revenue.

Any systems or personnel that have access to or hold that data would be in scope.

NIST 800-53

Systems and personnel with access to federal data are in scope. 

CMMC

Systems and personnel with access to CUI and/or FCI are in scope.

NIST 800-171

Systems and personnel with access to CUI and/or FCI are in scope.

CJIS

Systems, personnel, and processes that handle Criminal Justice Information (CJI) are in scope.