Planning the scope of a basic compliance program

Scoping is one of the keys to a successful compliance program. Irrespective of company size, you have to decide what to include and what to leave out. When scoping the requirements, take into account all the relevant business, legal, regulatory, and contractual compliance requirements. Requirements will vary from industry to industry and from country to country. Most countries have business accelerators or government agencies providing free advice; make the most of any available service to collect information for your compliance program.

Getting ready

To determine compliance requirements, different information sources can be included to assist program development during the scope-definition phase. The following list provides some potential resources:

• Company resources: They can include the company lawyer and internal stakeholders, such as business unit managers from the Human Resources, Finance, Operations, and Information Technology departments; they should know regulatory and contractual compliance requirements for their specific areas.
• External resources: They include the following:
  • Private organizations: This may include the Financial Accounting Standards Board, the IT Compliance Institute, or the IT Governance Institute that offer advice and information.
  • National organizations: They represent the industry interests and/or legal structures of a company
• Internet resources: Generally, they will be specific to each country; the following are some examples:
  • US: The Sarbanes-Oxley act is mandatory in the US and includes the regulation of financial practice and corporate governance (http://www.soxlaw.com/index.htm).
  • For small business administration: A dedicated site is available that includes all the government contacts for compliance (http://www.sba.gov/).
  • UK: Companies Act 2006 (http://www.legislation.gov.uk/ukpga/2006/46/pdfs/ukpga_20060046_en.pdf). More information for UK businesses including information on tax or export compliance can be found on the government website at https://www.gov.uk/.
  • Australia: The following website may offer a starting point: http://www.standards.org.au/Pages/default.aspx.
  • Germany: Basic information is offered by the following guide: www.bitkom.org/files/documents/BITKOM_Leitfaden_Compliance.pdf.

How to do it...

In order to define a scope, the following steps have to be taken:

• Understand your business compliance requirements and focus on the most critical business processes. Ask yourself the question: What is the primary product or service the business offers? Understand what is relevant to achieve any process or deliver products and/or services, for example, business units, people, applications, systems, data, and devices.
• Research the regulatory, contractual, and internal requirements using external resources and internal stakeholders.

Based on the information collected, define your in scope and out of scope objectives.

How it works...

There are two aspects to scope definition. The first aspect is, "What company assets should you include?" The second aspect is, "Which regulatory requirements or standards to include in your compliance program?"

Scope definition defined by the business

From a company perspective, the scope definition will include assets, such as physical locations, business units, equipment, application systems, and so on.

For a small or medium-sized company, defining a scope based on the compliance requirements shouldn't be a problem. Most likely, everything has to be included because data of critical applications are directly used in day-to-day business operations. In this case, separating your in scope part of the company and the out of scope part of the company might prove impossible or impractical.

Many smaller companies view compliance as a daunting task and don't start it at all. To avoid this problem, a phased approach is possible. The only consideration for a successful execution of this approach is the ability to define a self-contained scope. The benefit is that results from the first step can be incorporated into the next phase to improve on the compliance process.

For larger or more complex businesses, your decision as to what to include should be based on the following considerations:

• Physical scope: This includes locations or business units that have to adhere to compliance obligations.
• Logical scope: This includes all networks, application systems, data, and devices up to endpoint devices that use/process data that are part of the compliance obligation.

In addition, avoid situations where business units, applications, systems, or devices are both in scope and out of scope, because these could lead to breaches in your compliance program. For example, if some users are processing transaction data within an application but have limited privileges, they may be considered out of scope, whereas the IT administrator may have privileges to change data and that needs to be in scope.

That means that physical or logical separation must be possible.

Scope definition defined by regulatory, standard, contractual, or internal requirements

The other question that has to be answered for scope definition is, "What requirements have to be met in order to be compliant?"

Questions that should be asked are as follows:

• What are the basic regulatory, standard, or contractual requirements that have to be met? (This will determine which authority documents to focus on as a priority.)
• Which regulatory or standard requirements create a high risk for the business in the event of a failure?

The first question is based on the size and legal structure of a business and the industry the company is based in. The following list provides three examples of compliance areas that have to be considered:

• Tax compliance: Regardless of the business size, tax compliance starts with creating the business and complies with controls used in most countries that demand registration of your business and regular tax declarations. These controls will include the creation of orders and invoices that show relative tax information and the recording of payments.
• Accounting compliance: Just as before, regardless of size, most countries have regulatory or standard requirements demanding integrity or accuracy displayed in an annual financial statement, where the type and content depend on the size and legal structure of your company.
• IT compliance: As with contractual requirements, these can be in the form of software license compliance or regulatory requirements, such as data protection.

As an example of IT data protection compliance, let's look at the example from the preface, where we talked about the purchase process and systems holding customer and purchase information. To most companies, the business process that requires this information or data will be critical. Therefore, it should be considered for in scope.

The next question that has to be answered is, "Which regulatory, standard, contractual, or internal requirements must be met?" Data protection laws are one of those basic requirements focusing on protection of the personal data held on individuals. The financial information you hold on your customers, such as their identity information, credit card, or bank information, will fall under this category. Data protection laws vary from country to country; however, they all focus on protecting the data. Ensure that you review the respective laws; information on these laws is generally available and is easy to understand. For example, the authority document of the German protection law Bundesdatenschutzgesetz (BDSG) makes it fairly easy to understand the scope as it states in Appendix to §9 paragraph 1:

1. Prevent unauthorized access to data processing systems that process or use personalized information (physical access control)
2. Prevent unauthorized usage of data processing systems (access control)

Based on those two requirements, all locations (or just rooms), applications, networks, and devices that process, transmit, or store that information should be in scope.

The Payment Card Industry Data Security Standard (PCI DSS) is an example of high risk for businesses that accept, process, transmit, or store credit card data. In the event of failure in complying with PCI DSS, credit card companies, such as Visa, American Express, or MasterCard, may revoke the right to process credit card data. This could prove fatal for businesses relying on credit card payments from their customers. For those businesses, PCI DSS will definitely be in scope for fulfillment of an authority document.

An example on how to start with scope definition

Creating a network or architecture map is a great help in order to decide what to include to fulfill the BDSG or PCI DSS requirements. Even if you include everything in your scope, it is important to understand the relationship between your application systems, data flow, and connection points to the outside, meaning everything that is beyond your company network (for example, Internet connections). As shown in the previous example, regulatory requirements focus on specific areas. The data protection laws define certain requirements that have to be met by people (user accounts), applications, systems, and devices that handle the data. You can limit the scope of those requirements to only the relevant systems, devices, or business units.

Using a phased approach, you can start simple and then add details as you move forward with your compliance program. After the initial creation, start adding details of the systems in the network map. An important piece of information is the application used (for example, Exchange), the operating system, and the data flow of your in-scope application systems.

There's more...

You can use a degree of automation to create a network map. System Center Operations Manager is one of the tools that will help to create such a map. This will ensure that an automated diagram of your network and device landscape is created in an efficient and time-saving manner. In addition, this provides dynamic updating of your network map.

System Center Operations Manager offers different views. The Network Vicinity Dashboard view shows the relationship between network devices and computer (Windows Server) systems. It is a good starting point for a network map.

To view the Network Vicinity Dashboard, perform the following steps:

1. Open System Center 2012 R2 Operations Manager console.
2. Select the Monitoring workspace.
3. Expand the Network Monitoring folder.
4. Choose the device class you want to see; here, we choose Network Devices.
5. Go to the Tasks pane and click on Network Vicinity Dashboard.
6. The dashboard opens. Select Show Computers in the toolbar on top of the dashboard to view network and computer systems.

   Note

   Optionally, to change the level of connections displayed in the dashboard, change the value of Hops in the toolbar.