impossible for ideas to compete in the marketplace if no forum for
their presentation is provided or available." Thomas Mann, 1896
HIPAA - FINAL SECURITY RULE
Information Security Reference Guide
By Gary Swindon
Contributed by Sygate Technologies, Inc.
The HIPAA Final Security Rule is divided into three
broad categories of safeguards; administrative,
physical, and technical and contains 42 security
specifications. This reference guide lists the
requirements of the Final Security Rule in point
format with the action that needs to be taken in
order to achieve compliance for Healthcare
Operations by April 21, 2005, the final compliance
date. More to the point it provides explanations
for each specification in plain English.
The HIPAA Final Security Rule is the third of the
“big three” HIPAA rules (Transactions and Code
Sets, Privacy, and Security). Although the title
tends to invoke thoughts of technical or
computer based security techniques alone, it is
much more focused on security as a business
process. The rule itself is broken down into three
broad areas of safeguards; administrative,
physical, and technical. In each of these areas the
Federal Government has created a set of
standards that healthcare organizations must
meet in order to be compliant with the rule.
Some standards must be implemented exactly as
the rule states and the balance of the
requirements can be met in a way that the
organization judges is appropriate for the
prevailing conditions. However, organizations do
not have the latitude to ignore any of the
In addition to being a law aimed at the
healthcare industry, the Health Insurance
Portability and Accountability Act of 1996, or
HIPAA, has the potential to cause far-reaching
impacts on enterprises in unrelated industries,
such as banking, accounting, and financial
services. This extraordinary reach originates with
the HIPAA provision governing the “business
associates” of healthcare organizations. Basically,
any entity that provides services involving
patient-confidential data for a healthcare
organization is required to adhere to the same
standards of security and protection that the
healthcare organization must follow for the use
and disposal of confidential data. Of the several
rules that comprise the law, two contain the
“heart” of the regulation: the Privacy Rule,
already in effect, and the Final Security Rule, with
a compliance date of April 21, 2005.1 These rules
are mutually supporting; the Privacy Rule
addresses the necessary parameters of protecting
and using personal healthcare information; and
the Security Rule addresses the security posture
needed to support the Privacy Rule.
The Security Rule has a strong element of
common sense attached to it in that covered
organizations are specifically charged with
considering how large the organization is, how
complex, what resources are available and how
much remediation efforts will cost. The basis for
the regulation is the consideration of the business
risk associated with the information processes
and the relationship that they have in supporting
patient privacy. Specifically, organizations are
charged with evaluating their risk, taking steps to
mitigate it, and accepting the residual risk as a
cost of doing business.
The focus of the rule while technical in flavor,
does indeed address how computer and other
information systems are to be used and managed.
It also addresses such things as the physical
security of the devices, the buildings that they are
housed in and the methods that are employed to
manage the workforce. Taken as a whole, the
Security Rule compliments the Privacy Rule and
extends a management framework that makes
ongoing support of Privacy efforts feasible and
The rule emphasizes policies and procedures for
its compliance deadline of April 21, 2005.
Specifically, we must ensure that our policies and
procedures are properly documented, internally
consistent, and enforced (when violations occur).
In addition, we must make some physical and
technical efforts to ensure the safety and security
of our information assets. The rule is not
intended to be a punitive standard but rather a
framework for a safe patient care environment.
1 There is an exception to the Final Security Rule compliance
date for small covered entities that extends the compliance
date one year.
Since breaches in patient confidentiality and
privacy involve lapses in security practices,
the Final Security Rule is covered by the same
penalties as the Privacy Rule, both civil and
criminal, and is enforced through action taken by
the Office of Civil Rights, Department of Health
and Human Services. The mechanism is simple, if
a patient believes that their privacy has been
breached, they may file a complaint with the
Secretary of Health and Human Services who then
provides the compliant to the Office of Civil
Rights for investigation and determination of
necessary action. This determination can include
remanding the complaint to the Justice
Department for suspected criminal activity.
Should the complaint be validated, a company
can face either civil penalties of up to $25,000 a
year for each type of incident or, when criminal
liability is proven, fines ranging from $50,000 and
1 year in prison, up to $250,000 and as much as 10
years in prison for the people found guilty.
The Privacy and Security Rules both require an
active and aggressive risk management program
that includes the assessment of risk, risk
mitigation activities and acceptance, in writing, of
the residual risk that the organization is willing to
accept as a part of “doing business.” This
program is a fundamental requirement and must
be done on a continual basis (164.308(a)(1)(i)).
The notion of risk in this context involves both
administrative (policy and procedure) activities
and technical infrastructure blended in such a
way as to facilitate the enterprise achieving
HIPAA compliance therefore, must be continuous
and testable at any time — with an emphasis on
the testable part. In addition, the regulation is
forever; short of the Federal Government
changing its collective mind, these rules and their
requirements are not going away. Thus, the
HIPAA rules require a level of governance that up
to this point has not been commonplace. Boards
of Directors, outside auditors, corporate
management, and corporate executives must be
able to assert and prove compliance at any time.
Specifications, and Impact
on Healthcare Operations
In the table below, standards or specifications
with an (A) or an (R) mean:
(A) ADDRESSABLE - We must assess whether
each implementation specification is a
reasonable and appropriate safeguard in
our environment based on the likely
contribution it would make to the
protection of electronic health
information. If so, then we must
implement the specification as written. If
not, then we must document why it is
inappropriate for us and implement an
equivalent alternative measure that is
reasonable and appropriate. We may take
any steps to achieve compliance in
our size, complexity, and capabilities;
current infrastructure and our
the costs of security measures
the probability and criticality of
potential risks to protected electronic
health information that we generate
(R) REQUIRED - When a standard is marked as
required then we must implement the
The policies and procedures that we implement
must be maintained for six years after the
effective date of the policy or six years from the
date the policy is no longer in force; whichever is
Items with an asterisk (*) below are security
specifications that can be addressed for
compliance by having the Sygate solution running
in the network. The distillation of all of the
requirements, rules, and efforts leads directly to a
security program that will be heavily dependent
upon knowing, at any time, with certainty, that
the organization is secure, compliant, and ready
to support governance efforts.
HIPAA Final Security Rule: Administrative Safeguards
We must implement policies and procedures to prevent, detect,
contain, and correct security violations.
Risk Analysis (R) * We must conduct accurate and thorough assessments of the
potential risks and vulnerabilities to the confidentiality, integrity,
and availability of electronic protected health information held by us
whether or not we created it — such as with information that we
come to have through referrals etc. from an outside party. This also
includes the potential impact on our business.
Risk Management (R) * We must implement security measures sufficient to reduce
vulnerabilities to a reasonable and appropriate level to comply with
section 164.306(a). The bottom line is that we must take steps to
protect against any and all threats and hazards to protected
information in our possession or that comes to us from outside
associations. The key phrase in risk management is “reasonably
anticipated” and the requirement applies to managing our
workforce when they might come into contact with the protected
information. It also requires us to consider cost, complexity, and
ability in determining what we do to protect this information.
Sanction Policy (R) This requirement is directed at our workforce and obliges us
or invoke appropriate sanctions against anyone who willingly
violates our security policies and procedures.
Activity Review (R) *
We must regularly review records of information system activity such
as audit logs, access reports, and security incident tracking reports. Sygate Technologies, Inc.
164.308(a)(2) We must assign a person, or persons, to be responsible for the
development and implementation of policies and procedures
required by the regulation.
Workforce Security 164.308(a)(3) We must implement policies and procedures to
ensure that those
members of our workforce who need access to protected
information obtain it and that we deny access to those with no “need to know”.
We must implement procedures to authorize and/or supervise
workforce members who work with protected information or might
work in a location where they could come into contact with it.
We must take proactive steps to ensure that the access accorded a
workforce member to protected information is appropriate.
We must implement procedures for terminating access to protected
information when a workforce member leaves our employ or no
longer needs access, such as might be the case if they accept another
job inside of the organization that does not use the information.
164.308(a)(4) We must implement policies and procedures for authorizing access
protected information. This requirement stipulates that our policies
and procedures must be internally consistent with the requirements
of the broad security rule and its specific parts that deal with access.
Clearing House Function
If we have a healthcare clearinghouse as part of the enterprise then
the clearinghouse must implement policies and procedures to protect
the electronic protected healthcare information from unauthorized
access by the larger organization.
and Modification (A)
This requirement obliges us to “establish, document, review, and
modify a userâ€™s right of access” based on our adopted body of
policies and procedures.
Training 164.308(a)(5) We must implement a security awareness and training program for
all workforce employees including management and executives.
Security Reminders (A) We must provide periodic security updates to our
may already be doing much of what should be done with
publications, logon screen notices etc.
Malicious Software (A) *
This refers to taking action to detect, guard against, and report
software that has as its purpose the destruction of data,
communications, or infrastructure that we rely on to conduct
business. Normally this would include such things as viruses, worms,
Login Monitoring (A) * We must take steps to monitor logins and login attempts
the discrepancies where appropriate.
Password Management (A)
We must take steps to create, change, and safeguard passwords.
164.308(a)(6) We must implement policies and procedures to address security
incidents. Some of this work could already be being done in the
form of policies that deal with the Risk Management Departmentâ€™s
operations and Privacy efforts taken to comply with the Privacy Rule.
A normal step that this suggests is that we need to create a security
incident response team and insure that it includes other departments
such as corporate media, protective services etc.
Response and Reporting
This specification requires us to identify and respond to suspected or
known security incidents; mitigate to the extent practical to minimize
damage, and document these incidents and their outcomes.
Contingency Plan 164.308(a)(7) This requirement is straight-forward: “establish
and implement as
needed, policies and procedures for responding to an emergency or
other occurrence such as fire, vandalism, system failure, or natural
disaster that may damage systems containing protected
Data Backup Plan (R) We must establish and implement procedures to create and
retrievable exact copies of electronic protected health information.
This also requires that we test to see if we can in fact recover the
data from a backed up version at some later date.
Disaster Recovery Plan
We must establish, and implement as needed, procedures to restore
any loss of data. By implication this means the systems that process
the data or replacement systems if that is appropriate.
Operation Plan (R)
We must establish and implement, as needed, procedures to enable
the continuation of critical business processes for protection of the
security of electronic protected health information while operating
in emergency mode.
Testing and Revision
Basically, we have to test and revise our plans on a regular basis to
ensure that they work reliably.
Evaluation (R) * 164.308(a)(8) This part requires us to periodically evaluate
and assess both
technical and non-technical measures that we take to achieve
compliance with the regulation and to be prepared to continue to
ensure that we meet the requirements for compliance should
changes in our environment occur.
Arrangements 164.308(b)(1) This section requires that in cases where we have organizations
outside of the corporation who create, receive, maintain or transmit
electronic protected healthcare information on our behalf, give us
satisfactory assurances that they will protect the information in
accordance with the requirements in the Final Security Rule. In other
words, they are bound by the same standard as we are but do not
necessarily have to use the same methods to protect the information.
Written Contract or
Other Arrangement (R)
This provision requires us to document arrangements with those who
qualify as Business Associates and obliges us to take action if we
know that the Associate is not safeguarding the information as
agreed to in the contract. The actions that may be/must be taken
involve contacting the offending Associate and getting them to fix
the problem or, if that fails, terminating the contract with them if
feasible, or reporting them to the Secretary of DHHS. The bottom
line is that any organization wishing to do business with us that
involves protected information must comply with the rule as if they
were a covered entity themselves. This part of the Security Rule also
applies to their subcontractors, if any, and obliges us to terminate
the contract with the Associate if one of their agents or
subcontractors violates the Rule and doesnâ€™t return to compliance.
Facility Access Controls 164.310(a)(1) This portion of the Security Rule
requires that we create
policies and procedures to limit access to any facility that
houses any kind of information system that processes or
stores protected information. This includes such things as
servers, PCs, terminals or any other computer based device
such as the new Computers On Wheels (COWs) that are a
part of newer clinical systems that are being fielded. The rule
further cautions us to provide for access by those personnel
who must have access in order to do their jobs.
As part of our required Disaster Recovery Plan and
Emergency Mode Operations Plan, we must establish
procedures that allow facility access in support of restoration
efforts. This part is really focused on ensuring that access
controls do not get in the way of getting back into business
as soon as possible.
Facility Security Plan (A) This specification requires that we implement
procedures to limit or control access to facilities where
protected information is processed on computer and related
Access Control and
We must implement procedures to determine someoneâ€™s
need for access to protected information based on their role
or function in the organization. This also applies to any
possible access that might be needed to do maintenance or
install revisions of the software itself. This portion of the
Security Rule specifically includes visitor control, as in the case
of outside maintenance personnel.
This requires us to implement policies and procedures to
document repairs and changes to the physical components of
a facility which are related to security. Some examples would
include: hardware, walls, doors, and locks.
Workstation Use (R) 164.310(b) This standard has several pieces; we need to
following with policies and procedures: • Specify the proper functions or uses of a workstation
(PC, terminal etc.) • Specify how the function will be performed • Specify the physical attributes of the area in which
the PC or terminal device is located; This covers such things as whether or not the PC monitors
should face away from personnel who have no need to see
the protected information being processed, room should
have locking doors, and visitors should be handled.
164.310(c) We are required to implement physical safeguards for all
workstations that may access protected information and to
restrict access to only authorized users.
Device and Media
164.310(d)(1) We are required to implement policies and procedures that
govern the receipt and removal of the hardware and
electronic media that contain protected information when it
moves into and out of a facility. Further, we have to extend
this set of rules to cover the movement of these items within
the facility, such as moving PCs from a nursing station on one
floor to another floor or clinic area.
Disposal (R) We must implement policies and procedures to address the
final disposition of protected information and the hardware
and electronic media (such as floppy disks, CDs, etc.) on
which it is stored. This does not mean that we cannot reuse
the hardware or media with suitable controls and procedures
being in place.
Media Reuse (R) We can reuse media if we implement policies and procedures
that require the removal of any protected information prior
to the media being reused elsewhere for some other purpose.
Accountability (A) We must maintain a record of the movements of hardware
and electronic media and any person responsible for them.
The “person” in this case could include the person who
physically moved the items and the person authorizing the
Data Backup and
We must create a retrievable, exact copy of electronic
protected health information, when needed, before the
movement of equipment. This applies to situations where
we move a device with the intention of placing it back into
service to continue processing or remove a device from
service but still have a need to recover the information that
may be stored on it.
164.312(a)(1) This section requires that we implement technical policies (those
that can be set in software on a machine for the machine to
enforce) to ensure that only those people who are supposed to
have access to the software (such as System, Network, and Security
Administrators) are allowed such access. This also covers situations
where software on a machine needs access rights to other parts of
the system or network just as a person would.
We must assign a unique name or number to identify a person who
has any level of access to our systems and that can be tracked over
We must establish and implement, as needed, procedures for
obtaining necessary protected health information during any
Automatic Logoff (A) * Implement electronic procedures that terminate an
session after a predetermined time of inactivity. For example, this
situation occurs when anyone connected to our network leaves
their PC to conduct other business or in situations where staff may
go home for the night and forget to log off.
Decryption (A) *
We must implement a mechanism to encrypt and decrypt electronic
protected health information. This applies to transmitting the
protected information to any legitimate person or organization
outside of our network.
Audit Controls (R) *
164.312(b) We must implement hardware, software, and/or procedural
mechanisms that record and examine activity in systems that
contain or use electronic protected health information.
Integrity (A) * 164.312(c)(1) We must implement policies and procedures to
protected health information from improper alteration/destruction.
This requirement specifies that we have to take steps to verify that
electronic protected health information has not been altered,
tampered with, or destroyed in an unauthorized manner.
Person or Entity
164.312(d) We must provide a mechanism to verify that the person seeking
access to protected information is in fact the person that they claim
164.312(e)(1) We must ensure that protected information that travels inside our
network or is transmitted to an authorized person or organization
outside our network is protected from outside access or intercept.
Integrity Controls (A) * We must implement measures that ensure that
transmitted electronic protected health information is not
improperly modified without detection until it reaches its
destination and is used as needed.
Encryption (A) * We must implement a mechanism to encrypt protected information
whenever we deem it appropriate. This section of the rule speaks
directly to our dealings with Business Associates.
Sygate and HIPAA
Practitioners who truly pay attention to the
implied as well as explicit regulatory
requirements will quickly realize that only with
appropriate technology to complement their
efforts will they be able to manage successfully a
compliant security program. The primary
requirement for any technology solution is that it
supports compliance and governance with an
ability to continuously adapt, enforce, and
maintain an integrated security posture for the business. A review of available technologies
yields a clear choice — the Sygate product suite.
Sygate can give the business the ability to
put into place a security framework of continuous
compliance that provides a pervasive discovery
capability, adaptive security, and an ability to
continuously enforce the companyâ€™s policies,
irrespective of the means of connection to the
company's network. The ability to move policy
and procedure from written documents to
network-enforced mechanisms is a powerful
enabler for enterprises, which can be sure, at any
time, of their security postures.
This enforcement capability works under all
conditions and applies to users inside the
organization as well as those connected from
outside the network. The Sygate product line is
cost-effective and effort-efficient to both manage
and maintain. The security practitioner no longer
has to depend upon hope or assumptions for
reporting on the up-to-the-minute security status
of the precious communications means that is the
lifeblood of the business.
The rich feature set and broad capabilities,
particularly policy enforcement, make the Sygate
solution indispensable for dealing with HIPAA
security compliance issues, especially those
requiring that we maintain positive control over
our network. The ability to determine how the
network is running and, just as important, what is
running on it enables us to evaluate the
effectiveness of security measures and contributes
to maintaining a sound compliance program.
About the Author:
Gary Swindon, CISM, is the Corporate Information Security Officer for Orlando
responsible for all aspects of information security. Orlando Regional Healthcare
is a large, private, not-for-profit
healthcare organization with 8 hospitals and ancillary clinical activities
spread throughout central
Florida. Prior to his tenure at Orlando Regional Healthcare, Gary held positions
as Principal of his own
security consulting practice; Vice President, Chief Security, and Privacy
Officer for WebMD Corporation; and
Director, Office of Computing and Telecommunications for the State of Michigan.
In addition, he spent
several years in the Department of Defense as an Intelligence and Security
Officer. He has a BA from the
University of Dayton and an MBA from Boston University.
Search the ENTIRE Business
Forum site. Search includes the Business
Forum Library, The Business Forum Journal and the Calendar Pages.
The Business Forum, its Officers, partners, and all other
parties with which it deals, or is associated with, accept
absolutely no responsibility whatsoever, nor any liability,
for what is published on this web site. Please refer to: