Planning the scope of a basic compliance program

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:

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.

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:

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:

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:

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.

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.