HIPAA Collaborative of Wisconsin
Administrative Safeguard Scorecard
Disclaimer
This document is Copyright  2008 by the HIPAA Collaborative of Wisconsin (“HIPAA COW”). It may be
freely redistributed in its entirety provided that this copyright notice is not removed. It may not be sold for profit
or used in commercial documents without the written permission of the copyright holder. This document is
provided “as is” without any express or implied warranty. This document is for educational purposes only and
does not constitute legal advice. If you require legal advice, you should consult with an attorney. HIPAA COW
has not yet addressed all state preemption issues related to this document. Therefore, this document may need to
be modified in order to comply with Wisconsin law.
Acknowledgements
The development of this document was a consolidated effort by many people between 2005 and 2008. The
following people have contributed to this document:
Joan Benson
Cathy Boerner
Julie Coleman
Mindy Daley
Nancy Davis
Claudia Egan
Todd Fitzgerald
Bonnie Goins
Mary Koehler
Chrisann Lemery
Beth Malchetske
Susan Manning
Pete McCartney
Allen Mundt
Patti Pate
Wayne Pierce
Karl Radke
Keisha Sabelko
Holly Schlenvogt
Jim Sehloff
Kirsten Wild
Effectiveness and Controls
For each security standard and their related implementation specifications, each organization will need to
establish security controls. These controls are established to reduce or eliminate vulnerabilities. NIST Special
Publication 800-53, Recommended Security Controls for Federal Information Systems, is an excellent resource in
helping you establish your baseline controls. (Refer to the reference section):
The table below is an example of a control type and its related control levels:
Control Type
Physical
Access
Control and
Validation
Procedures
None
No control
mechanisms
used
Related Control Levels
Low
Moderate
All physical access points All physical access
are controlled through the points are controlled
use of cipher locks or key twenty-four hours per
locks during working
day, seven days per
hours and are guarded or
week through the use of
locked during non-work
entry devices such as
hours.
key card or biometrics.
High
All physical access
points are controlled
twenty-four hours per
day, seven days per
week through the use
of guards or
monitored alarms.
Once the initial set of security controls are determined, they can be fine tuned and adjusted based on specific
organizational policy and requirements documents, particular conditions and circumstances, known threat and
vulnerability information, or tolerance for risk to the organization’s operations and assets. The controls should be
phrased in the form of a question and measure the progress of effectively implementing them. We recommend a
five level approach, which is defined as:
Level 1
Level 2
Level 3
control objective documented in a security policy
security controls documented as procedures
procedures have been implemented
1. 3/20/2008
Level 4
Level 5
procedures and security controls are tested and reviewed
procedures and security controls are fully integrated into a comprehensive program
The following grid functions as a scorecard for the administrative safeguards in the security rule. Refer to the
Physical Security Work Group Whitepaper for a scorecard relative to the HIPAA Physical Security requirements.
How to Use the Grid
Perhaps the most important thing about using the grid (scorecard) is that it is essentially an interactive checklist:
as the user responds to one of the levels associated with a security control question - those questions listed under
the Control Objectives and Techniques - they can indicate completion by checking the appropriate box at the
intersection of the security control question and level. The user can also establish degrees of completeness for
one or more of the levels as they see fit. This is not an all-inclusive list.
For example, suppose we want to address the Emergency Mode Operation Plan implementation specification
listed under the Contingency Plan HIPAA Security Standard, as seen below:
HIPAA Security
Standard
Implementation
Specification
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
7. Contingency
Plan –
164.308(a)(7)
7.3 Emergency Mode
Operation Plan
7.3.1 Are resources
supporting critical operations
identified?
7.3.2 Have processing
priorities been established
and approved by
management?
Level 1-Write the Policy To begin, we need to establish an Contingency Plan Policy that addresses all of the
Implementation Specifications listed under that standard: 7.1 Data Backup Plan, 7.2 Disaster Recovey Plan, 7.3
Emergency Mode Operations Plan, 7.4 Testing and Revision Procedure, 7.5 Applications and Data Criticality
Analysis. Once the policy is complete, the form of which will differ from organization to organization, we can
check-off (show completion by dating and/or color coding, or annotating in some fashion) the Level 1 Policy box
and move on to Level 2.
Level 2-Write the Procedures At this Level, there is one security control question prompting us to write
procedures that relate to the Emergency Mode Operations Plan. Question 7.3.1 asks if resources are supporting
critical operations identified in the plan. If not, then best practices according to NIST tells us that we should have
a resource support process in place. Assuming we follow this recommendation, we need to write procedures on
how we are going to do align those resources. Question 7.3.2 should be addressed in the same manner. Once
these two control questions are completed, a Level 2 status will have been reached with respect to the Emergency
Mode Operation Plan Implementation Specification under the Contingency Plan HIPAA Security Standard.
Level 3-Implement the Procedures Achieving Level 3 status means implementing the policy and procedures
established thus far for the Emergency Mode Operation Plan. Remember, both control questions need to be
addressed for Level 3 status to be achieved.
Level 4-Procedures and Security Controls are tested and reviewed A great policy and set of procedures
related to Emergency Mode Operation Plan may have been written and implemented, but to reach Level 4 status,
the policy and procedures need to be tested to see that they work. Be diligent here and make sure that everyone
involved knows and understands their role as the plan is tested! Once done, check it off and move to Level 5.
2. 3/20/2008
Level 5-Procedures and Security Controls are fully integrated into a comprehensive program Addressing
this Level begs questions like, “Are the measures we have created, implemented, and tested consistent with the
overall information security policy and philosophy of the organization?” and “Does this control compliment other
controls we have in place or is it inconsistent with them?” These are heady questions, but the idea is that
effective security must be holistic. That is, information security strength is less about the individual the pieces
and more about how well they fit together.
Maintaining information security strength is a never-ending process, requiring ongoing assessments of system
security controls and adjustments or changes to those controls as needed. The scorecard is a great tool for
benchmarking, documenting, and tracking those adjustments and changes over time.
There are few other things worth noting when following the scorecard. First, the methodology of the scorecard is
based largely on the NIST Special Publication 800-26 Self Assessment Guide (see References listing at the end
of this document for the URL). Be sure to review that document to gain greater understanding of the
methodology. Second, many of the questions used in the scorecard come directly from NIST Special Publication
800-26. They are identifiable with superscripted numbers and are cross-referenced to 800-26 in the Footnotes
section toward the end of this document. Note: as of March 2008 the NIST 800-26 publication is obsolete and is
superseded by 800-53A.
Finally, NIST intends for those using this process to do it in sequence. That is, policies should be written before
procedures, policies and procedures should both be written before implementing the procedures, and so forth. It
should be obvious as to why this is the case, but most of us have tried and failed to uphold tested procedures
without a policy only to have someone come along and implement a “better” way, thereby leading to confusion,
workarounds, and other assorted headaches.
2008 And Beyond: The Centers For Medicare & Medicaid Services (CMS) direction CMS has long
recognized that the largest information store of Personal Health Information (PHI) is contained within the systems
of those companies contracted by the government to process Medicare claims. As such, CMS has required
stringent security requirements structured to the NIST requirements for “HIGH” criticality and sensitive systems.
For the past several years, compliance has been evaluated using the level 1-5 scale specified by NIST, with the
expectation that contractors attain at least a level 3 (implemented) to be compliant, and preferably to have some
controls at level 4 (tested).
However, for 2008 and beyond, Medicare contractors must conduct an annual evaluation indicating that 1/3 of the
controls have been tested. For the controls failing the testing criteria specified in the NIST Special Publication
800-53A, corrective action plans must be submitted. In other words, the expectation is that all Medicare
contractors will achieve level 4 testing over the next 3 years.
Why is this important? Because over time, the Medicare security provisions tend to be viewed as the ‘defacto
requirements’ for healthcare, and with the extension of HIPAA Security audits into the Healthcare/Hospital arena
in 2008, it is advisable to pay attention to the expectation that in the future, it will no longer be acceptable for the
security control to be at compliance level 3. The control will need to be independently tested by another party
(internal/ external) to achieve level 4 compliance, which will become the future expectation. Savvy security
professionals will plan for and integrate this testing process into the infrastructure when designing controls.
3. 3/20/2008
HIPAA
Security
Standard
1. Security
Management
Process –
164.308(a)(1)
Implementation
Specification
1.1 Risk Analysis
1.2 Risk Management
Has each risk been
addressed?
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
1.1.1 Has an inventory of the
components comprising the
organization’s information systems
been developed and maintained?
1.1.2 Are risk assessments
performed and documented on a
regular basis or whenever the
system, facilities, or other
conditions change?1
1.1.3 Has data been classified
according to degree of sensitivity?
1.1.4 Have threat sources, both
natural and manmade, been
identified? 2
1.1.5 Has a list of known system
flaws, vulnerabilities, weaknesses
that could be exploited by the threat
sources been developed and
maintained current? 3
1.1.6 Has an analysis been
conducted that determines whether
the security requirements in place
adequately mitigate
vulnerabilities?4
1.1.7 Is the current system
configuration documented,
including links to other systems?5
1.2.1 Are final risk determinations
and related management approvals
documented and maintained on
file? 6
1.2.2 Has a mission/business
impact analysis been conducted? 7
1.2.3 Have additional controls
been identified to sufficiently
mitigate identified risks? 8
4. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
1.3 Sanction Policy
1.4 Information
Systems Activity
Review
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
1.3.1 Are mechanisms in place for
holding users responsible for their
actions?
1.4.1 Are security alerts and
incidents analyzed and remedial
actions taken? 9
1.4.2 Is there an effective and
timely process for reporting
significant weakness and ensuring
effective remedial actions taken? 10
1.4.3 Are intrusion detection tools
installed on the system? 11
1.4.4 Are intrusion detection
reports routinely reviewed and
suspected incidents handled
accordingly? 12
1.4.5 Is the system performance
monitoring used to analyze system
performance logs in real time to
look for availability problems,
including active attacks? 13
1.4.6 Is the activity involving
access to and modification of
sensitive or critical files logged,
monitored, and possible security
violations investigated? 14
1.4.7 Does the audit trail provide a
trace of user actions? 15
1.4.8 Can the audit trail support
after-the-fact investigations of how,
when, and why normal operations
ceased? 16
1.4.9 Are audit trails reviewed
frequently? 17
1.4.10 Are automated tools used to
review audit records in real time or
near real time? 18
2. Assign
Security
Responsibility –
164.308(a)(2)
5. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
Control Objectives and
Techniques
2.1 Assign Security
Responsibility
2.1.1 Has a person been identified
that will be responsible for the
development and implementation
of HIPAA Security requirements?
3.1 Authorization
and/or Supervision
3.1.1 Are duties separated to
ensure least privilege access and
individual accountability? 19
3.1.2 Are there documented job
descriptions that accurately reflect
assigned duties and responsibilities
and that segregate duties? 20
3.1.3 Are mechanisms in place for
holding users responsible for their
actions? 21
3.1.4 Is there a process for
requesting, establishing, issuing,
and closing user accounts? 22
3.1.5 Are there processes in place
for the authorization and/or
supervision of workforce members,
regardless of location, who work
with ePHI?
3.2.1 Is appropriate background
screening for assigned positions
completed prior to granting access?
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
3. Workforce
Security 164.308(a)(3)
3.2 Workforce
Clearance Procedure
23
3.2.2 Are individuals authorized to
bypass significant technical and
operational controls screened prior
to access and periodically
thereafter? 24
3.2.3 Are confidentiality or
security agreements required for
employees assigned to work with
sensitive information? 25
3.2.4 When controls cannot
adequately protect the information,
are individuals screened prior to
access? 26
6. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
3.3 Termination
Procedures
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
3.2.5 Are there conditions for
allowing system access prior to
completion of screening? 27
3.3.1 Are hiring, transfer, and
termination procedures established?
28
3.3.2 Is there a process for
requesting, establishing, issuing,
and closing user accounts? 29
4. Information
Access
Management –
164.308(a)(4)
4.1 Isolating Health
Care Functions
4.1.1 Is the current system
configuration documented,
including links to other systems? 30
4.1.2 Have the security controls of
the system and interconnected
systems been reviewed? 31
4.1.3 Has management authorized
interconnections to all systems
(including systems owned and
operated by another program,
agency, organization, or contractor?
32
4.1.4 Is the operating system
configured to prevent
circumvention of the security
software and application controls?
33
4.2 Access
Authorization
4.3 Access
Establishment and
Modification
4.2.1 Are users individually
authenticated via passwords,
tokens, or other devices? 34
4.2.2 Is a current list maintained
and approved of authorized users
and their accesses? 35
4.3.1 Is there a process for
requesting, establishing, modifying,
and discontinuing user accesses?
7. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
4.3.2 Do job descriptions include
documentation on appropriate
accesses to information and
information systems?
5. Security
Awareness and
Training –
164.308(a)(5)
5.1 Security
Reminders
5.2 Protection from
Malicious Software
5.3 Log-in Monitoring
5.4 Password
Management
5.1.1 Is there mandatory annual
refresher training? 36
5.1.2 Are methods employed to
make employees aware of security,
i.e., posters, booklets? 37
5.2.1 Is malware detection and
elimination installed and activated
on all appropriate devices,
including servers, workstations, and
portable devices?38
5.2.2 Are malware signature files
routinely updated? 39
5.2.3 Are malware scans
automatic? 40
5.2.4 Are malware reports
consistently reviewed and acted on
in a timely manner?
5.3.1 Do the logical access
controls restrict users to authorized
transactions and functions? 41
5.3.2 Can the security controls
detect unauthorized access
attempts? 42
5.3.3 Is access monitored to
identify apparent security violations
and are such events investigated
and documented? 43
5.4.1 Are users individually
authenticated via passwords,
tokens, or other devices? 44
8. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
5.4.2 Are passwords changed at a
time interval determined to be
acceptable by the organization’s
risk analysis? 45
5.4.4 Are passwords not displayed
when entered? 47
5.4.5 Are there procedures in place
for handling lost and compromised
passwords? 48
5.4.7 Are passwords transmitted
and stored using secure
protocols/algorithms? 50
5.4.8 Are vendor-supplied
passwords replaced immediately? 51
6. Security
Incident
Procedures –
164.308(a)(6)
6.1 Response and
Reporting
6.1.1 Is there a capability to
provide help to users when a
security incident occurs in the
systems? 52
6.1.2 Is a formal incident response
capability available? 53
6.1.3 Is there a process for
reporting incidents? 54
6.1.4 Are incidents monitored and
tracked until resolved? 55
6.1.5 Are personnel trained to
recognize and handle incidents? 56
6.1.6 Are alerts/advisories received
and responded to? 57
6.1.7 Is there a process to modify
incident handling procedures and
control techniques after an incident
occurs? 58
6.1.8 Is incident information and
common vulnerabilities or threats
shared with appropriate
organizations? 59
6.1.9 Are security incidents
documented, maintained, and
9. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
analyzed for trends?
7. Contingency
Plan –
164.308(a)(7)
7.1 Data Backup Plan
7.2 Disaster Recovery
Plan
7.1.1 Are critical data files and
operations identified and the
frequency of file backup
documented? 60
7.2.1 Has a comprehensive
contingency plan been developed
and documented? 61
7.2.3 Are responsibilities for
recovery assigned? 63
7.2.4 Are there detailed
instructions for restoring
operations? 64
7.2.5 Is there an alternate
processing site; if so, is there a
contract or interagency agreement
in place? 65
7.2.6 Is the location of stored
backups identified? 66
7.2.7 Are backup files created on a
prescribed basis and rotated offsite often enough to avoid
disruption if current files are
damaged? 67
7.2.8 Is system and application
documentation maintained at a
secured location? 68
7.2.9 Are all system defaults reset
after being restored from a
backup? 69
7.2.10 Are the backup storage site
and alternate site geographically
removed from the primary site an
physically protected? 70
7.2.11 Has the contingency plan
been distributed to all appropriate
personnel? 71
10. 3/20/2008
HIPAA
Security
Standard
Implementation
Specification
7.3 Emergency Mode
Operation Plan
7.4 Testing and
Revision Procedure
7.5 Applications and
Data Criticality
Analysis
Control Objectives and
Techniques
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
7.3.1 Are resources supporting
critical operations identified? 72
7.3.2 Have processing priorities
been established and approved by
management? 73
7.4.1 Are tested contingency/
disaster recovery plans in place? 74
7.4.2 Is an up-to-date copy of the
plan stored securely off-site? 75
7.4.3 Are employees trained in
their roles and responsibilities? 76
7.4.4 Is the plan periodically tested
and readjusted as appropriate? 77
7.5.1 Is there an up-to-date
inventory of applications, with
their assigned level of criticality
and other key attributes?
8. Evaluation –
164.308(a)(8)
8.1 Evaluation
8.1.1 Have the technical and nontechnical security controls been
reviewed periodically? 78
8.1.2 Have systems and network
boundaries been subject to periodic
reviews? 79
8.1.3 Has an independent review
been performed when a significant
change occurred? 80
8.1.4 Are routine self-assessments
conducted? 81
8.1.5 Are tests and examinations of
key controls routinely made, e.g.,
network scans, penetration testing,
analyses of router and switch
settings? 82
8.1.6 Are security alerts and
incidents analyzed and remedial
actions taken? 83
8.1.7 Is there an effective and
timely process for reporting
significant weakness and ensuring
effective remedial action? 84
11. 3/20/2008
HIPAA
Security
Standard
9. Business
Associate
Contracts and
Other
Arrangement.
Implementation
Specification
Control Objectives and
Techniques
9.1 Written Contract
and Other Arrangement
9.1.1 Are there written agreements
with Business Associates regarding
how PHI must be safeguarded in
accordance with HIPAA?
Level 1
Policy
Level 2
Procedures
Level 3
Implemented
Level 4
Tested
Level 5
Integrated
Comments
12. 3/20/2008
Footnotes:
Questions listed in the scorecard above with superscripted numbers come from NIST Special Publication 800-26.
The cross-references to those questions in the 800-26 document are detailed below:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Page A-5, Risk Management, 1.1.2
Page A-6, Risk Management, 1.1.4
Ibid, 1.1.5
Ibid, 1.1.6
Page A-5, Risk Management, 1.1.1
Page A-6, Risk Management, 1.2.1
Ibid, 1.2.2
Ibid, 1.2.3
Page A-8, Review of Security Controls, 2.1.5
Ibid, 2.2.1
Page A-35, Data Integrity, 11.2.5
Ibid, 11.2.6
Ibid, 11.2.7
Page A-50, Audit Trails, 17.1
Ibid, 17.1.1
Ibid, 17.1.2
Page A-51, Audit Trails, 17.1.6
Ibid, 17.1.7
Page A-18, Personnel Security, 6.1
Ibid, 6.1.2
Page A-19, Personnel Security, 6.1.5
Ibid, 6.1.8
Ibid, 6.2
Ibid, 6.2.1
Ibid, 6.2.2
Page A-20, Personnel Security, 6.2.3
Ibid, 6.2.4
Page A-19, Personnel Security, 6.1.7
Ibid, 6.1.8
Page A-5, Risk Management, 1.1.1
Page A-7, Review of Security Controls, 2.1
Page A-15, Authorize Processing, 4.1.8
Page A-30, Hardware and Software Maintenance, 10.1.4
Page A-43, Identification and Authentication, 15.1
Ibid, 15.1.1
Page A-38, Security Awareness, Training, and Education,
13.1.3
Ibid, 13.1.4
Page A-34, Data Integrity, 11.1
Ibid, 11.1.1
Ibid, 11.1.2
Page A-46, Logical Access Control, 16.1
Ibid, 16.1.1
Page A-47, Logical Access Control, 16.10
13. 3/20/2008
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
Page A-43, Identification and Authentication, 15.1
Page A-44, Identification and Authentication, 15.1.6
Ibid, 15.1.7
Ibid, 15.1.9
Ibid, 15.1.10
Ibid, 15.1.11
Page A-45, Identification and Authentication, 15.1.12
Ibid, 15.1.13
Page A-40, Incident Response Capability, 14.1
Ibid, 14.1.1
Ibid, 14.1.2
Ibid, 14.1.3
Ibid, 14.1.4
Ibid, 14.1.5
Page A-41, Incident Response Capability, 14.1.6
Page A-41, Incident Response Capability, 14.2
Page A-27, Contingency Planning, 9.1.1
Ibid, 9.2
Ibid, 9.2.1
Ibid, 9.2.2
Page A-28, Contingency Planning, 9.2.3
Ibid, 9.2.4
Ibid, 9.2.5
Ibid, 9.2.6
Ibid, 9.2.7
Ibid, 9.2.8
Ibid, 9.2.9
Ibid, 9.2.10
Page A-27, Contingency Planning, 9.1.2
Ibid, 9.1.3
Page A-28, Contingency Planning, 9.3
Ibid, 9.3.1
Ibid, 9.3.2
Ibid, 9.3.3
Page A-7, Review of Security Controls, 2.1
Ibid, 2.1.1
Ibid, 2.1.2
Ibid, 2.1.3
Page A-8, Review of Security Controls, 2.1.4
Ibid, 2.1.5
Ibid, 2.2.1
References:
1. CMS Information Security Acceptable Risk Safeguards:
http://www.cms.hhs.gov/it/security/docs/ars.pdf
2. All NIST Special Publications, whether published or in draft, may be accessed from this link:
http://csrc.nist.gov/publications/index.html.
14. 3/20/2008
A. NIST Self Assessment Guide for Information Technology Systems, 800-26
November 2001 (now obsolete).
B. NIST Risk Management Guide for Information Technology Systems, 800-30, July 2002.
C. NIST Recommended Security Controls for Federal Information Systems, 800-53, February 2005.
15. 3/20/2008