The HIPAA Security Rule (at 45 C.F.R. §164.308(a)(1)(ii)(A)) requires an initial security risk analysis according to risk analysis guidance issued by HHS/OCR based on NIST standards. OCR Audit Protocols for Risk Analysis are clear! CMS, as planned, has launched audits of organizations who have attested to Meaningful Use Objectives and Risk Analyses will be audited. Have you completed a bona fide HIPAA Security Risk Analysis?

1. 1
Are NIST standards clouding the
implementation of HIPAA protections?
Part nine of a series
September 2013
Author: Dave Sweigert, M.Sci., CISSP, CISA, PMP
(non-attorney providing scholarly (non-legal) advice)
ABSTRACT
Subcontractors processing protected health information should be aware of legal
liabilities regarding the adequacy of bona fide security risk assessments.
Background
September 23, 2013 is the deadline for
those entities processing “protected
health information” (PHI) to ensure their
subcontractors align their security
practices with the national PHI
protection floor known as the Security
Rule of the Health Insurance Portability
and Accountability Act (HIPAA). The
mechanism to accomplish this objective
is known as the Business Associate
Agreement (BAA). Subcontractors are
considered “business associates” in this
model and their BAA may require their
compliance with the HIPAA Security
Rule; which among other things,
requires a “security risk assessment”;
Title 45 Code of Federal Regulations
(C.F.R.) Section 164.308(a)(1). It would
be an over-simplification to assume that
a 45 C.F.R. 164.308(a)(1) security risk
assessment is open to broad
interpretation, as to adequacy, by the
entity conducting such a security risk
assessment.
NIST Standards Mandated
There is a bright-line test as to the
required level of sufficiency for a 45
C.F.R. 164.308(a)(1) security risk
assessment.
“Federal contractors” have been bound
by pre-existing requirements regarding
the level of quality required of their
information security practices for a
decade.
The Medicare Prescription Drug,
Improvement, and Modernization Act of
2003 (MPDIMA) added information
security requirements for Medicare
administrative contractors (MAC), fiscal
intermediaries, and carriers.
MPDIMA imposed the requirements of
the Federal Information Security
Management Act (FISMA, 44 U.S.C.
3541 et seq.) as the prevailing bright-
line test for information security
practices of CMS “federal contractors”.
See 42 U.S.C. § 1395kk-1.

2. 2
Requirements for NIST compliance
The 1988 Omnibus Trade and
Competitiveness Act (OTCA) gave the
exclusive domain for the promulgation of
federal computer security standards to
the U.S. National Institute of Standards
and Technology (NIST). The NIST
Information Security Laboratory and the
Computer Security Division are the only
pertinent, relevant and chartered (by
Congress), organizations to render
opinions on behalf of the U.S.
Government in matters of computer
security technology and standardization.
Office of Management and Budget
(OMB in the Executive Office of the
President (EOP)) instruction M-10-15,
(OMB M-10-15), entitled, Reporting
Instructions for the Federal Information
Security Management Act (FISMA, 44
U.S.C. 3541 et seq.) and Agency
Privacy Management 13-14 (2010),
requires federal contractors to ensure
the operation of information technology
infrastructure is in compliance with the
security provisions of the FISMA law.
Quoting OMB instructions M-10-15 in
relevant part (at page 15):
“..Agencies are fully responsible and
accountable for ensuring all FISMA and
related policy requirements are
implemented and reviewed and such
must be included in the terms of the
contract. Agencies must ensure
identical, not "equivalent," security
procedures. For example, annual
reviews, risk assessments, security
plans, control testing, contingency
planning, and security authorization
(C&A) must, at a minimum, explicitly
meet guidance from NIST. Additionally,
IGs shall include some contractor
systems in their “representative subset
of agency systems,” and not doing so
presents an incomplete independent
evaluation. [emphasis added]
The U.S. Department of Health and
Human Services (DHHS), Office of
Chief Information Officer (OCIO) policy
regarding Cybersecurity; known as
HHS-OCIO-2011-0003, states: (quoting
in relevant part)
“…This Policy applies to all HHS
organizational components (i.e.,
Operating Divisions [OPDIVs] and Staff
Divisions [STAFFDIVs]) and
organizations conducting business for
and on behalf of the Department
through contractual relationships. This
Policy does not supersede any other
applicable law, higher-level agency
directive, or existing labor management
agreement in place as of the effective
date of this Policy….” [emphasis added];
and,
“…4.1.1 OPDIVs/STAFFDIVs shall use
the National Institute of Standards and
Technology (NIST) Special Publication
(SP) 800-37 Revision (Rev.) 1, Guide
for Applying the Risk Management
Framework to Federal Information
Systems: A Security Life Cycle
Approach (dated February 2010), as the
methodology for the security
authorization of information systems
(formerly known as “certification and
accreditation” or “C&A”), in accordance

3. 3
with FISMA and direction from the Office
of Management and Budget (OMB)…”;
[emphasis added] and,
“…4.1.4 Information assurance and
privacy activities conducted within the
Department shall be consistent with the
guidance, methodologies, and intent
prescribed by the NIST SP series, in
particular NIST SP 800-53 Rev. 3 and
NIST SP 800-53A Rev. 1, Guide for
Assessing the Security Controls in
Federal Information Systems and
Organizations, Building Effective
Security Assessment Plans, and other
relevant Federal laws and guidance
documents. It is incumbent upon each
OPDIV to appropriately follow the steps
in the NIST SP 800-37 Rev. 1 Risk
Management Framework (RMF) to
select, implement, assess, authorize,
and monitor such controls
commensurate with a system’s FIPS
199 categorization….”[emphasis added]
Bona fide risk assessment
The foregoing authorities can be
summarized within the industry term
“bona fide security risk assessment”.
That is, to meet the bright-line test and
legal sufficiency for assessing security
management practices an adequate risk
assessment must be completed (for
those subcontractors supporting HIPAA
“covered entities” that are federal
contractors) to the NIST standard.
Such bona fide assessments will
demonstrate a baseline of adequate
security policies, standards and
guidelines (PSGs) that have been put in
place to protect PHI. A risk assessment
will measure the implementation
maturity of those guidelines (practical
implementation in the I.T infrastructure
with appropriate evidence to
demonstrate compliance) and identify
gaps. Gaps (material weaknesses) will
then be compared with the downstream
consequences of failure or exploit.
These gaps, and consequences, will be
presented to senior management so that
remediation can be planned and
prioritized.
The foregoing represents a significant
departure from the usual check-box
compliance approach of conducting a
network penetration study or red team
dumpster diving and then hoping for the
best. Business associates of federal
contractors processing PHI, especially
on behalf of DHHS, would be prudent to
accurately assess their need to comply
with the authorities cited.
About the author: Dave Sweigert is a
Certified Information Systems Security
Professional, Certified Information
Systems Auditor, Project Management
Professional and holds Master’s
degrees in Information Security and
Project Management. A former
consultant to the U.S. Department of
Homeland Security, he is a practitioner
of developing HIPAA Security Rule
compliant policies, standards and
guidelines that demonstrate compliance
for many organizations (including Delta
Dental, Kaiser Permanente and others).
He can be reached at LINKEDIN.COM.