Before you begin your decision process about which controls you want to add to your organizational framework, you should have a clear understanding and agree within your team about the rules of engagement for deciding which controls can be ignored, which controls should be based upon risk management, and which controls must be implemented.
In order to determine if a mandated compliance control is reasonable and appropriate for your organization, you need to be able to document what “reasonable and appropriate” means to you. This is called “scoping” the control, meaning that you are defining which controls you should leave in and which you should take out of your framework. You’ll want to set the groundwork for scoping before you begin your project.
The best document we’ve read to date on scoping controls is from the United States’ National Institute of Standards and Technology. NIST 800-53 is the Recommended Security Controls for Federal Information Systems, and it provides a baseline set of security controls that it mandates all United States federal organizations employ. With that aside, § 3.3 also has the best definition for the tailoring and scoping of controls that we’ve seen.
As NIST 800-53 points out, there are six considerations that can impact whether or how controls are applied. These considerations are related to 1) technology, 2) infrastructure, 3) public-access, 4) scalability, 5) common security control, and 6) risk. While NIST 800-53 speaks directly to security controls, we’ve modified the language to fit all controls.
Technology related considerations
Controls that refer to specific technologies (e.g., wireless, cryptography, public key infrastructure) are only applicable if those technologies are employed or are required to be employed within the information system.
Controls are only applicable to the components of the information system that typically provide or support the capability addressed by the control. In other words, if the system in question doesn’t have the processing capability dealt with in the control, the control can be ignored. As an example, a single user system wouldn’t need any networking controls because they don’t apply to that system as everything is already self-contained.
For off the shelf products, if an automated mechanism isn’t built in to support a control, it doesn’t need to be developed. In other words, if the control states that after three failed password attempts the user should be kicked out of the off-the-shelf application, but the application doesn’t have that capability already built into it, you can ignore the control for that application because there’s nothing you could develop to make the control work. You need to document this, and explain why you made the decision to purchase the product if it did not have this required control.
Infrastructure related considerations
Controls that refer to organizational facilities (e.g., physical controls such as locks and guards, environmental controls for temperature, humidity, lighting, fire, and power) are applicable only to those sections of the facilities that directly provide protection to, support of, or are related to the information system (including its information technology assets such as electronic mail or web servers, server farms, data centers, networking nodes, controlled interface equipment, and communications equipment) under consideration.
Public access considerations
Controls associated with public, customer, or third party access information systems should be carefully considered and applied with discretion since some controls (e.g., two-factor identification and authentication, personnel security controls) may not be applicable to users accessing information systems through public interfaces. For example, you might not want users to have to sign in when obtaining certain publicly available information while ensuring that they do so in order to change their account information.
Scalability related considerations
Controls must be scalable to match the system under consideration’s size and complexity as well as its level of impact to the organization. Organizations should use discretion in scaling the controls to the particular environment of use to ensure a cost-effective, risk-based approach to control implementation. In other words, don’t spend $10,000 protecting a $1,000 system. See risk related considerations for downgrading controls.
Risk related considerations
Controls that uniquely support the confidentiality, integrity, or availability objectives may be downgraded to the corresponding control in a lower baseline (or appropriately modified or eliminated if not defined in a lower baseline) if, and only if the downgrading action: 1) is consistent with the categorization for the corresponding objectives of confidentiality, integrity, or availability before moving to the high water mark; 2) is supported by an organizational assessment of risk; and 3) does not affect the relevant information within the information system.
Common control related considerations
Controls designated by the organization as common controls should be managed by an organizational entity other than the information system owner. As an example, access controls that support the entire network and all systems in it should not be managed by an information system manager responsible for a single system. Organizational decisions on which controls are viewed as common controls may greatly affect the responsibilities of individual information system owners with regard to the implementation of controls in a particular framework. This does not exempt the organization from implementing the control (i.e., letting it fall through the cracks). Every control in the framework must be addressed either by the organization or the information system owner.