NIST SP 800-70 REV. 3 NATIONAL CHECKLIST PROGRAM FOR IT PRODUCTS:
GUIDELINES FOR CHECKLIST USERS AND DEVELOPERS
16
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-70r3
Checklist Revision indicates that something has changed even if the version identifier did not change.
For example, if the organization does not change the version number on the document, but the content has
been updated (e.g., patches were added for a given month), the current checklist will be listed as archived
and the checklist with the updated patch content will show as the current checklist. Likewise, if the
submitting organization updates the version identifier, then the NCP will list the current checklist as
archived and link to the new checklist. From the checklist detail page, a user can navigate to the checklist
history via the “Archived Revisions” link.
4.3 Reviewing, Customizing and Documenting, and Testing Checklists
Checklist users should download all documentation for the checklist and review it carefully. The
documentation should explain any required preparatory activities, such as backing up a system. Because a
checklist may not exactly match a user’s specific requirements, reviewing a checklist is useful in
determining whether the checklist may need to be tailored
13
and whether the system or product will
require further changes after applying the checklist.
The user’s review can identify the impact on an organization’s current policies and practices if a given
security checklist is used. An organization may determine that some aspects of the checklist do not
conform to certain organization-specific security and operational needs and requirements. Organizations
should carefully evaluate the checklist settings and give them considerable weight, then make any
changes necessary to adapt the settings to the organization’s environment, requirements, policies, and
security objectives.
14
This is particularly true for checklists intended for an environment with significantly
different security needs. Organizations should tailor the checklists to reflect local rules, regulations, and
mandates; for example, federal civilian agencies would need to ensure that checklists reflect compliance
with Federal Information Processing Standard (FIPS) 140 encryption requirements. Because the checklist
may be used many times within the organization, the checklist itself might need to be modified. This is
especially likely if the checklist includes a script or template to be applied to systems.
At this point, all deviations from the settings in the checklist should be documented for future reference.
The documentation should include the reason behind each deviation, including the impact of retaining the
setting and the impact of deviating from the setting. This documentation helps in managing changes to the
checklist over the life cycle of the product being secured. Feedback on the checklist can be sent to NIST
as well as to the checklist developers. Feedback is especially important to developers in gauging whether
the checklist is well written and the settings are applicable to the targeted environment.
Before applying a checklist that will be used to alter product settings, users should first test it on non-
critical systems, preferably in a controlled non-operational environment. Such testing may be difficult for
home or small business users who do not have extra systems and networks for testing purposes. Each
checklist in the NIST checklist repository has been tested by its developer, but there are often significant
differences between a developer’s testing environment and an organization’s operational environment,
and some of these differences may affect checklist deployment. The testing configuration of the IT
product should match the deployment configuration. In some cases, a security control modification can
have a negative impact on a product’s functionality and usability, or on other products or security
controls. For example, installing a patch could inadvertently break another patch, or enabling a firewall
could inadvertently block antivirus software from updating its signatures or disrupt patch management
software. Consequently, it is important to perform testing to determine the impact on system security,
functionality, and usability; to document the results of testing; and to take appropriate steps to address any
13
If multiple checklists are available for the same product, the checklist user may wish to compare the settings or steps in the
selected checklist to the other checklists to see which settings or steps differ and determine if any of these alternate
recommendations should be used.
14
This may not be applicable to checklists that are mandatory for an organization to adopt.