search:
               

• Say What You Do Products
• Effective Technical Communication
• Inclusive modeling -- how to diagram your processes
• Audience, clarity, logic, and brevity
• Word choices
• Does you use correct grammar?
• Eats, shoots, and leaves
• Frameworks
• The major frameworks used for establishing IT controls
• Analyzing the acceptance of framework controls
• A guideline for scoping controls
• Why it is a bad idea to cut and paste from the standards
• How capability maturity relates to frameworks
• Policies
• Effective Technical Communication
• Creating policies
• Should we (and do we) label media appropriately?
• Procedures
• Documenting your procedures
• Standards
• Documenting organizational standards
• Authors
• Rebecca Herold, CISSP, CISA, CISM, FLMI
• Dorian J. Cougias
• Marcelo Halpern
• Say What You Do eBook bundle
• Free IT policy guide
• Say What You Do eBook Edition
• Forms, Templates, and Samples
• Say What You Do toolkit
• Systems and Information Classification Standards
• Change Management
• Information Assurance Compliance Maturity Model Index (IACMMI)
• The Language of Compliance
• Systems and Info Classification

Many organizations get confused when trying to create their own control framework to meet compliance with the externally mandated authority documents. A common mistake is to try and rip off or cut and paste from these authority documents verbatim (or as close to verbatim as possible) in order to create what is often mislabeled as an organizational "security" or "compliance" policy or standard. More often than not, this will create problems for you.

The typical lack of specificity within the authority documents often do not harmonize well with organizational de facto standards. For example, consider the HIPAA regulation from § 164.312 Technical safeguards:

“A covered entity must, in accordance with § 164.306:(a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).”

Do you see any problem with trying to use this exact statement as an organizational policy or standard? Would your IT folks know what this means? If you copied and pasted this into your own policy or standard, would this lead to consistent implementation of access controls within your organization, or would it open the door to inconsistent use of technology and inconsistent access control implementations? If you tried to include the referenced text from § 164.308(a)(4) you would end up including all the following:

“(4)(i) Standard: Information access management.

Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.

(ii) Implementation specifications:

(A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.

(B) Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.

(C) Access establishment and modification (Addressable). Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.”

Huh? Did this help? More likely all this verbiage just muddied the waters. And, since it references yet another part of the regulatory text, there are still more passages from this regulation that would need to be included if we continued to follow this logic. We have seen organizations actually try to do this, though, and they ended up with the following:

1. The authority document that was dropped-in covers more topics than applies to the organization, confusing those who must follow them. For example, if the organization is not a clearinghouse, those reading this standard will wonder how they are supposed to comply with the “required” clearinghouse statement.

2. Documenting a control statement as “addressable” usually gets incorrectly interpreted as meaning “optional.” If the people who must follow the standard think an action is optional, nine times out of ten they will choose not to follow it.

3. Authority documents typically read more like a laundry list of required controls that could include policies, standards, procedures, training programs, testing programs, etc. There are no specific solutions provided in authority documents (such as this one from HIPAA), leading to multiple solutions being implemented throughout an organization that all do basically the same thing. This not only wastes your organization’s money, it leads to a maintenance and compatibility nightmare - it completely undermines our goal of commonality.

4. The writing style does not match the other control documents within the organization, making them seem strangely out of place to the readers who must follow them.

5. Your organization’s control documentation can not be harmonized for multiple authority documents if you take the statements verbatim from each of the regulations. You thus leave it to the individual readers to attempt to interpret and harmonize these standards in a way that they believe makes sense for their own jobs without knowing the impact of their interpretations on other parts of the business. This harmonization is important for making organizational standards as succinct and understandable as possible while complying with multiple regulatory requirements.