HIPAA Security Implementation, Version 1.0

15.2 SECURITY POLICY

Any organized and well coordinated risk management effort should begin with a security policy. The term 'Security Policy' can mean many things to different people. However, a security policy is in essence an organization's written stance on security issues and security management. Often, a security policy is envisioned by many as a long, complicated document and it is also often associated with a monumental effort that no one really wants to take on. This may be an accurate assessment if the organization chooses to tackle this effort using the monolithic approach in which they do just that: Create a long and complicated document that is both difficult to read and difficult to manage. Like anything else, a security policy creation effort is best done in a structured and organized manner.

The security policy itself should be a relatively short document with some broad language that describes the organization's general stance on security and security management. Then, the organization can use a series of supporting documents to further define and articulate more specifically how it will carry out and enforce the messages stated in the overall security policy document. Examples of security policy supporting documents include the following:

• Standards-The standards document can be used to specify certain operating standards that the organization has decided best suits its needs. Examples might be system configuration standards or application standards. Having a set of standards that the organization can refer to can greatly reduce costs in terms of expending resources on managing and supporting a series of disparate systems.

• Baseline Documents-Baselines provide minimum levels of security for an organization.

• Guidelines-This type of documentation provides basic recommendations and guidance for general users, IT staff, operations staff and others. Guidelines are most often used when a specific standard or process does not apply. Guidelines are not usually mandatory as standards and baselines are, but are intended as a tool for orienting the organization in the absence of a documented standard.

• Processes and Procedures-Processes and procedures document exactly how operations which support policies, baselines and standards will be carried out in the enterprise.

• Other Policy Documents-In addition to the security policy document, there may be other supporting documents that outline other important high-level policy considerations. For example:

  • User or Acceptable Use Policies

  • Privacy Policies

  • Customer Policies

Collectively, all the documents listed above are generally considered to be the organization's security policy in addition to the security policy document itself. Having a distinct set of documents has substantial benefits in terms of managing policy and providing a high degree of flexibility such that policies, practices and procedures can be customized to suit the needs of the various entities in the organization.

15.2.1 Characteristics of a Good Security Policy

Listed below are several points that characterize a good security policy:

• It should be drawn up by a core team that is involved in the entire process

• It should take into account the needs of the users as well as the philosophy and operating practices of the organization

• It should be clearly written, using positive language that specifically identifies the roles and responsibilities of the individuals within the organization

• Education and training should be provided for the users where required

• Approval of the security policy should be obtained from management at the highest levels of the organization, and management should be seen to enthusiastically endorse and support the policy

• General users should be encouraged to accept the policy