Mike Knapp | Compliance 101: Understanding Scope

Compliance 101: Understanding Scope

Compliance 101: Understanding Scope

Posted by Mike Knapp in Compliance 11 Feb 2011

Developing and adhering to compliance processes is a maturing process for most companies.  It requires that departments move from ad-hoc to structured and documented processes.

While many auditors would like to see every system within the compliance framework, the key to success is to manage the scope and scale.  For the first year (or phase) of implementation, only include what absolutely has to be included.  Use it as an opportunity to mature your processes and ensure all the compliance requirements are being met. 

Scope of Compliance
Limiting the scope of compliance is one of the best things you can do to help your compliance project succeed.  While the natural thought is that all systems and processes within the company should be compliant, it’s not the requirement of most standards.

  • ISO 27001 specifies the requirement for a defined scope
  • PCI’s scope is the systems and environment with access to credit card holder data
  • Sarbanes Oxley’s scope is focused on the accounting/financial systems (and anything that helps to generate the financial statements)

In the initial compliance project, limiting scope to what must (not should) be covered should be a key requirement.  Scope can be extended in future years when your processes are more mature and stable.

Selecting what systems must be compliant is a process that requires significant thought and planning. Trying to tell your auditor that System X is not part of scope “just because” will never work.  Defining scope well in your documentation and justifying any exclusions will reduce the questions asked.  Use simple process and network diagrams (these are required for PCI and helpful for SOX).

Hint for risk-centric compliance frameworks – include inclusions in your risk assessment to justify and demonstrate management sign-off.

Prepare a multi-year plan for your scope and use this to guide your compliance project:

  • Year 1 includes only required systems and processes
  • Year 2 includes a broader range of systems and processes
  • Year 3 includes …

This way you have a plan to roll more and more of the company’s systems into the framework and best practices.

As your processes mature and the company rolls out new business process, it’s easy to roll them into the scope of the security framework.  Remember: Compliance provides a structured methodology to implement best practices.  Secure, documented, well thought out processes that meet regulatory requirements from the start?  Novel concept!

Developing Compliance Processes
When developing your compliance processes, keep in mind the risk and scale of the process.  Why engineer the Titantic when a zodiac will do?  Scaling can make the difference between creating a manageable long-term solution and a bureaucratic nightmare.

Understanding the level of risk and scaling processes appropriately is very important.  When I was learning about ISO 27001, I found some excellent sample processes (and associated documentation) online.  As I spent more and more time with the framework, I found the processes were significantly over-engineered for our requirements.

In talks with ISO auditors, we discovered this is a common problem.  Brilliant technical engineers build the ultimate processes that meet every possible eventuality. Wise compliance leads build the simplest processes required.

Do you want a success compliance project?  Then repeat after me:  Keep it simple.

Post a comment