How to Pass Every Audit - Out of Scope

Just like we talked about defining what is in scope, we must define what is out of scope. This actually means a few things. Nothing is truly ungoverned, but it may be governed under a different policy or standard than the one you are currently writing. However, it can be out of scope of a program, or standard, or a policy. There may be a different policy or standard that defines this. Be thinking about things like shadow IT, acquisitions, unique systems, SOX, PCI or CDE (customer data environments). These are all things that we want to consider when writing policies and standards and exclude from our primary documents.

There may be a situation where there is a part of your network that your team doesn’t manage (acquisitions) or that has different expectations (CDE). So let’s continue our MFA example. We saw a picture of all identities, and where our policy for MFA applied to humans only. Many times we want to reiterate the out of scope items, and point the auditors to where it does apply. If we don’t, and we just leave it as it is out of scope, they are likely to pull it into scope in the wrong place. They expect to audit it, as they will have an audit scope of controls they need to audit, and so we need lead them to the area where it applies.

Essentially what that means is that for each area where we have said ‘it doesn’t apply,’ we need to tell them where that one does apply. This could look like a few different things. My suggestion is pointing them from the current standard and/or policy to the one that applies specifically. If you don’t define the various types of identities, they will group them together and likely group them non-homogenously.

Within your policy you should define each type of identity. So that could look something like:

Definitions

Human Identities - identity and credential material used by humans. Humans may be of various types including Employees, Contractors, or Third Parties. These identities originate within the corporate IdP.

Cloud Identities - Cloud identities are roles and credentials that are contextually relevant within a cloud service provider account. These identities originate within the cloud service provider and are assigned to workloads, services, or automated processes — not to named individuals.

Service Accounts - These are accounts used by machines and may originate within any approved IdP.

APIs credentials - API credentials are identities and credentials used to authenticate to an API. These credentials are issued to and managed by devices or systems, and originate from an approved secrets management system or IdP

and so on.

In this case you will need to be prepared to educate the auditors that a cloud role is not an identity in and of itself and that a human may access the cloud environment via federation (using their human identity which requires MFA). The assumption of a role is just that a role, not a new identity.

Now, within your standard where you are defining MFA requirements you will maintain your specific standards. When, where, how MFA is required. Somewhere within the standard you will reiterate the implicit out of scope from earlier to say:

Out of Scope

Cloud Identities - see cloud IAM standard xyz-123

Service Accounts - see Service account standard abc-456

API credentials - see API security standard efg-789