How to Pass Every Audit - Scope

Audit
Written By Andrew Alaniz

Scope is everything in an audit. If you don’t define a scope, one is going to be defined for you. In banking you’ll usually be measured against NIST CSF, FFIEC, and/or SOX control expectations. In other places it may be something else. That is your framework, though, not your scope. Your scope is specifically where a particular policy, standard, or control statement applies. This tells the auditors where they’re allowed to test your compliance. This doesn’t mean they won’t look for something that should apply, but isn’t in the scope, but we will cover how to get ahead of that in a future post. For now, we’re going to use the MFA example from the first post. Here is a visual that explains why, with MFA, since the scope has to do with identity, the way it is written is so important.

Identity Scope & MFA
All identities Human identities Employees Contractors Third parties MFA policy applies here NIST 800-63 + CIS Controls v8 Standard: NIST 800-63 (on-prem) Standard: CIS Controls v8 (cloud) Controls: CIS 6.3, 6.4, 6.5 Controls: NIST 800-53 IA-2, IA-5 Scope: explicitly human only Non-human identities Cloud IAM roles (AWS, Azure, GCP) Service accounts API keys Kerberos / service tickets Machine identities / certs Workload identities MFA does not apply here, or applies differently. Separate standard. "All users must use MFA" Scope: ambiguous — covers everything? Auditor: "Your service accounts don't have MFA — you're out of compliance." No scope = no defense. vs "All human users must use MFA" Scope: explicit — employees, contractors, third parties only. Non-human: separate standard. Auditor has no foothold.

When writing scope statements, you should pause if you ever see absolutes like: all, never, none, always, every. These words without any conditions often spell trouble. Think of any of your programs and consider how they could end up causing you to stumble:

Network security: All what?

  • All firewall rules? What about networks that aren’t behind a firewall?

  • All firewalls? What about the firewalls at remote locations that are managed by a third party?

  • All third parties? What about the SaaS providers you have no control over?

  • All networks? What about your guest wifi?

Data

  • All files? What about backups, encrypted storage, operating system files?

  • All email? What about auto generated messages from third party tools?

  • All data transfer? What about money transfer, backups, internal network comms?

Endpoint security

  • All endpoints? What about servers, what about network devices, what about IoT?

  • All servers? What about AIX, ESX, AS400, audio/video servers?

As you see, if you aren’t careful, you can bring things into scope that should probably just be carved out. You want your in scope statements to be as broad as possible, but also specific. The more specific you get, the more statements and exceptions you’ll have to manage and explain. However, if they are too broad, then you’re going to bring things into scope that shouldn’t be. It’s a balance between those two.

Andrew Alaniz https://www.alaniz.io
Previous

How to Pass Every Audit - Out of Scope
Next

How to Pass Every Audit - Policies & Standards