Who is in audit scope?

Every employee and/or contractor who has access to customer data, production, and/or develops code should be considered in scope and should go through employee onboarding. Contractors may fall outside of scope if they do not have access to customer data or any source code.

The scope of an audit is based primarily on the relevant customer data. Something or someone is in scope if they handle, have access to, or deal with the relevant data in any way, shape, or form.

Relevant data will be de dependent based on the frameworks in play. Relevant data for SOC 2 & ISO 27001 are customer data. PCI cares about cardholder data. HIPAA & HITRUST care about PHI. GDPR, CPRA, ISO 27001 all care about personal data.

Contractors

Contractors will be in scope if they have access to customer data and/or source code.

Outsourced employees

In the cases where a businesses’ primary service is to provide staffing services (people) for other businesses, those personnel are not considered in-scope employees of the business’ that is providing that service.

Example: Secureframe hires company x to provide additional personnel resources. Company x’s personnel work solely for Secureframe - they have access to Secureframe’s systems, have a Secureframe email, etc.

These personnel would not be in scope of company x’s audit, and they should be treated as a vendor. Secureframe is responsible for ensuring proper third-party dilligence and controls are implemented for these contractors.

Frequently Asked Questions (FAQ)

So for SOC 2, what should I consider the most important for employee scope?

• For SOC 2 and ISO, the most important factor is Customer Data. 

How do I know who is in scope when it relates to Personal Data?

• When it comes to Personal Data, GDPR, CPRA, ISO are all relevant.

We have several contractors who are no longer very active and never had significant access to our systems or a high level of security clearance. When I onboarded them, I initially marked them as 'in-scope.' Can I simply update their designation to 'Contractor: Out of Scope,' or is additional documentation or procedural work required to support this change?

• If they are indeed out of scope for your particular framework, then yes you can mark them out of scope.
• It's important to also have documentation or evidence to explain why these users are out of scope, should an auditor inquire about this during a future audit.