IT compliance planning: How to maintain IT compliance documentation

Documentation is a key requirement for many IT security regulations. Expert Mike Chapple offers tips for maintaining documentation the right way.

Every information security and IT compliance professional knows, deep down, that compliance documentation is critical

to the ongoing viability of an IT compliance program. Why then, does this important task often slip off the radar and get added to those ubiquitous we-need-to-get-to-that-someday lists that litter the desktops of corporate America?

Maintaining this documentation is one of the most often overlooked IT compliance activities.

Documenting compliance efforts is more than a luxury. While we know that written descriptions of security controls are important to ensure continuity of compliance efforts in large organizations -- where responsibilities often shift from department to department or among individuals as they change positions -- it's equally important to remember that many regulations specifically require the formal documentation of security controls. And, yet, maintaining this documentation is one of the most often overlooked IT compliance activities.

In this tip, we examine ways that enterprises can improve the documentation of compliance controls, develop a sustainable program to maintain security documentation and understand some of the specific documentation requirements that many organizations need to follow.

Documenting security controls

The basic objective of any compliance documentation program is to maintain a list of all the control objectives mandated by the various regulations with which an organization must comply, and then build upon this listing with a description of the specific controls used to meet those objectives. One common method used by organizations is to develop a written compliance plan for each regulation that progresses through the requirements on a point-by-point basis. The complexity of this documentation varies depending upon the level of detail contained within each regulatory requirement. Generally speaking, you should include a description of the requirement, a description of the control, contact information for the individual responsible for the control and information regarding the last time the control was validated as being correctly in place.

For example, a section of a PCI DSS compliance plan dealing with the requirements of PCI DSS section 12.1 might contain the following three components:

Requirement: Establish, publish, maintain and disseminate a security policy that ... addresses all PCI DSS requirements.

Control Description: The corporate Information Security Policy (available in the Policy folder on SharePoint) contains specific language in Section 3 that addresses each PCI DSS requirement.

Responsible Individual: Mary Jones, IT Policy Office, x51242

Source Citation: PCI DSS 12.1.1

Last Validated: 6/1/2013 by Tom Abrams

 

Requirement: Establish, publish, maintain and disseminate a security policy that ... includes an annual process that identifies threats and vulnerabilities and results in a formal risk assessment.

Control Description: The corporate Information Security Policy (available in the Policy folder on SharePoint) contains a requirement for an annual formal risk assessment in Section 4.1. This risk assessment is conducted each May and the results are stored in the Risk Assessment folder of the IT Compliance intranet.

Responsible Individual: Robert Smith, IT Security Office, x58294

Source Citation: PCI DSS 12.1.2

Last Validated: 6/1/2013 by Tom Abrams

 

Requirement: Establish, publish, maintain and disseminate a security policy that ... includes a review at least annually and when the environment changes.

Control Description: The corporate Information Security Policy (available in the Policy folder on SharePoint) contains a requirement for review annually and upon major changes in Section 5.2. This review is documented with a memorandum stored in the Policy Review folder of the IT Compliance intranet.

Responsible Individual: Robert Smith, IT Security Office, x58294

Source Citation: PCI DSS 12.1.3

Last Validated: 6/1/2013 by Tom Abrams

The creation of these plans should be a collaborative effort among all individuals with responsibility for compliance requirements. In many large organizations, this may be the responsibility of an existing compliance or risk management committee. Individual stakeholders may include information security professionals, policy analysts, compliance specialists and legal counsel. Once completed, they serve as a valuable resource for validating an organization's ongoing compliance and will also greatly reduce the amount of effort needed to support any audits that may occur.

Reviewing compliance plans

Annual reviews of an organization's various compliance plans should be scheduled as recurring activities on the IT compliance calendar, scheduled alongside other important compliance deadlines and milestones. Each review should be conducted by an individual with "arm's length" status from the controls under review. At a minimum, the review should not be conducted by anyone who is deemed responsible for the compliance plan.

The reviewer's job is to simply progress through each of the elements of the IT compliance plan and verify that the listed controls are in place and effectively meet the compliance requirement. Upon completion of each verification, the reviewer updates the "last validated" date on the compliance plan.

The second activity that should take place during the annual review is a comparison of the compliance plan with current regulatory requirements. This review is a good check-and-balance to ensure that the control requirements have not changed since the last review, and that each requirement is addressed by the IT compliance plan. Any deficiencies should be remediated with the remediation documented in the updated compliance plan.

Regulation-specific security documentation requirements

When developing an enterprise compliance documentation program, be sure to consult the specific documentation requirements of each regulation governing your activities. These regulations may include specific documentation requirements that you need to incorporate into your program.

For example, both HIPAA and PCI DSS include a requirement that organizations subject to those regulations conduct formal risk assessments to ensure the security of protected information. Your compliance plan should ensure not only that the review takes place, but also that the results are documented and stored in a location where they are easily accessible in the event of a compliance audit. One common approach is to use a SharePoint site to store this documentation.

Additionally, most information security regulations require that you have a written information security plan that includes specific elements. This is true of even somewhat obscure regulations, such as Massachusetts' 201 CMR 17.00, which governs organizations that collect personal information from Massachusetts residents. The regulation lists a number of specific requirements that must be addressed by the written plan. Thus, you may find that you need to adapt your current documentation to meet the requirements of various different regulations.

While documenting IT compliance is certainly not a glamorous task, it is critical to ensuring the smooth and effective operation of your compliance program. In addition to often being a required component of regulatory compliance, documented plans make it easy for the organization to verify that they are currently meeting all obligations and simplify the process of communicating their compliance to regulators, auditors and other third parties.

About the author:
Mike Chapple, Ph. D., CISA, CISSP, is an IT security manager with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to SearchSecurity.com and serves as its resident expert on enterprise compliance, frameworks and standards for its Ask the Experts panel. He previously served as site expert on network security, is a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated.

This was first published in September 2013

Dig deeper on IT Security Audits

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close