NOTE: This section of the Security Standard has been updated in the final Security Rule as of April 21, 2003, and is no longer current - it is provided for reference only.

Subpart C--Security and Electronic Signature Standards

§ 142.302 Applicability and scope.

The standards adopted or designated under this subpart apply, in whole or in part, to the following:

(a) A health plan.

(b) A health care clearinghouse or health care provider that takes one of the following actions:

Processes any electronic transmission between any combination of health care entities listed in this section.

Electronically maintains any health information used in an electronic transmission that has been sent or received between any combination of health care entities listed in this section.

§ 142.304 Definitions.

For purposes of this subpart, the following definitions apply:

Access refers to the ability or the means necessary to read, write, modify, or communicate data/information or otherwise make use of any system resource.

Access control refers to a method of restricting access to resources, allowing only privileged entities access. Types of access control include, among others, mandatory access control, discretionary access control, time-of-day, and classification.

Authentication refers to the corroboration that an entity is the one claimed.

Contingency plan refers to a plan for responding to a system emergency. The plan includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster.

Encryption (or encipherment) refers to transforming confidential plaintext into ciphertext to protect it. An encryption algorithm combines plaintext with other values called keys, or ciphers, so the data becomes unintelligible. Once encrypted, data can be stored or transmitted over unsecured lines. Decrypting data reverses the encryption algorithm process and makes the plaintext available for further processing.

Password refers to confidential authentication information composed of a string of characters.

Role-based access control (RBAC) is an alternative to traditional access control models (e.g., discretionary or non-discretionary access control policies) that permits the specification and enforcement of enterprise-specific security policies in a way that maps more naturally to an organization's structure and business activities. With RBAC, rather than attempting to map an organization's security policy to a relatively low-level set of technical controls (typically, access control lists), each user is assigned to one or more predefined roles, each of which has been assigned the various privileges needed to perform that role.

Token refers to a physical item necessary for user identification when used in the context of authentication. For example, an electronic device that can be inserted in a door or a computer system to obtain access.

User-based access refers to a security mechanism used to grant users of a system access based upon the identity of the user.

§ 142.306 Rules for the security standard.

(a) An entity must apply the security standard described in § 142.308 to all health information pertaining to an individual that is electronically maintained or electronically transmitted.

(b) If a health care clearinghouse is part of a larger organization, it must assure that all health information pertaining to an individual is protected from unauthorized access by the larger organization.

§ 142.308 Security standard.

Each entity designated in § 142.302 must assess potential risks and vulnerabilities to the individual health data in its possession and develop, implement, and maintain appropriate security measures. These measures must be documented and kept current, and must include, at a minimum, the following requirements and implementation features:

(a) Administrative procedures to guard data integrity, confidentiality, and availability (documented, formal practices to manage the selection and execution of security measures to protect data, and to manage the conduct of personnel in relation to the protection of data). These procedures include the following requirements:

1. Certification. (The technical evaluation performed as part of, and in support of, the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a pre-specified set of security requirements. This evaluation may be performed internally or by an external accrediting agency.)
2. A chain of trust partner agreement (a contract entered into by two business partners in which the partners agree to electronically exchange data and protect the integrity and confidentiality of the data exchanged).
3. A contingency plan, a routinely updated plan for responding to a system emergency, that includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster. The plan must include all of the following implementation features:
   1. An applications and data criticality analysis (an entity’s formal assessment of the sensitivity, vulnerabilities, and security of its programs and information it receives, manipulates, stores, and/or transmits).
   2. Data backup plan (a documented and routinely updated plan to create and maintain, for a specific period of time, retrievable exact copies of information).
   3. A disaster recovery plan (the part of an overall contingency plan that contains a process enabling an enterprise to restore any loss of data in the event of fire, vandalism, natural disaster, or system failure).
   4. Emergency mode operation plan (the part of an overall contingency plan that contains a process enabling an enterprise to continue to operate in the event of fire, vandalism, natural disaster, or system failure).
   5. Testing and revision procedures (the documented process of periodic testing of written contingency plans to discover weaknesses and the subsequent process of revising the documentation, if necessary).
4. Formal mechanism for processing records (documented policies and procedures for the routine, and nonroutine, receipt, manipulation, storage, dissemination, transmission, and/or disposal of health information).
5. Information access control (formal, documented policies and procedures for granting different levels of access to health care information) that includes all of the following implementation features:
   1. Access authorization (information-use policies and procedures that establish the rules for granting access, (for example, to a terminal, transaction, program, process, or some other user.)
   2. Access establishment (security policies and rules that determine an entity’s initial right of access to a terminal, transaction, program, process or some other user).
   3. Access modification (security policies and rules that determine the types of, and reasons for, modification to an entity’s established right of access, to a terminal, transaction, program, process, or some other user.)
6. Internal audit (in-house review of the records of system activity (such as logins, file accesses, and security incidents) maintained by an organization).
7. Personnel security (all personnel who have access to any sensitive information have the required authorities as well as all appropriate clearances) that includes all of the following implementation features:
1. Assuring supervision of maintenance personnel by an authorized, knowledgeable person. These procedures are documented formal procedures and instructions for the oversight of maintenance personnel when the personnel are near health information pertaining to an individual.
2. Maintaining a record of access authorizations (ongoing documentation and review of the levels of access granted to a user, program, or procedure accessing health information).
3. Assuring that operating and maintenance personnel have proper access authorization (formal documented policies and procedures for determining the access level to be granted to individuals working on, or near, health information).
4. Establishing personnel clearance procedures (a protective measure applied to determine that an individual’s access to sensitive unclassified automated information is admissible).
5. Establishing and maintaining personnel security policies and procedures (formal, documentation of procedures to ensure that all personnel who have access to sensitive information have the required authority as well as appropriate clearances).
6. Assuring that system users, including maintenance personnel, receive security awareness training.
8. Security configuration management (measures, practices, and procedures for the security of information systems that must be coordinated and integrated with each other and other measures, practices, and procedures of the organization established in order to create a coherent system of security) that includes all of the following implementation features:
1. Documentation (written security plans, rules, procedures, and instructions concerning all components of an entity’s security).
2. Hardware and software installation and maintenance review and testing for security features (formal, documented procedures for connecting and loading new equipment and programs, periodic review of the maintenance occurring on that equipment and programs, and periodic security testing of the security attributes of that hardware/software).
3. Inventory (the formal, documented identification of hardware and software assets).
4. Security testing (process used to determine that the security features of a system are implemented as designed and that they are adequate for a proposed applications environment; this process includes hands-on functional testing, penetration testing, and verification).
5. Virus checking. (The act of running a computer program that identifies and disables:
   1. Another "virus" computer program, typically hidden, that attaches itself to other programs and has the ability to replicate.
   2. A code fragment (not an independent program) that reproduces by attaching to another program.
   3. A code embedded within a program that causes a copy of itself to be inserted in one or more other programs.)
9. Security incident procedures (formal documented instructions for reporting security breaches) that include all of the following implementation features:
1. Report procedures (documented formal mechanism employed to document security incidents).
2. Response procedures (documented formal rules or instructions for actions to be taken as a result of the receipt of a security incident report).
10. Security management process (creation, administration, and oversight of policies to ensure the prevention, detection, containment, and correction of security breaches involving risk analysis and risk management). It includes the establishment of accountability, management controls (policies and education), electronic controls, physical security, and penalties for the abuse and misuse of its assets (both physical and electronic) that includes all of the following implementation features:
1. Risk analysis, a process whereby cost-effective security/control measuresmay be selected by balancing the costs of various security/control measures against the losses that would be expected if these measures were not in place.
2. Risk management (process of assessing risk, taking steps to reduce risk to an acceptable level, and maintaining that level of risk).
3. Sanction policies and procedures (statements regarding disciplinary actions that are communicated to all employees, agents, and contractors; for example, verbal warning, notice of disciplinary action placed in personnel files, removal of system privileges, termination of employment, and contract penalties). They must include employee, agent, and contractor notice of civil or criminal penalties for misuse or misappropriation of health information and must make employees, agents, and contractors aware that violations may result in notification to law enforcement officials and regulatory, accreditation, and licensure organizations.
4. Security policy (statement(s) of information values, protection responsibilities, and organization commitment for a system). This is the framework within which an entity establishes needed levels of information security to achieve the desired confidentiality goals.
11. Termination procedures (formal documented instructions, which include appropriate security measures, for the ending of an employee’s employment or an internal/external user's access) that include procedures for all of the following implementation features:
1. Changing locks (a documented procedure for changing combinations of locking mechanisms, both on a recurring basis and when personnel knowledgeable of combinations no longer have a need to know or require access to the protected facility or system).
2. Removal from access lists (physical eradication of an entity's access privileges).
3. Removal of user account(s) (termination or deletion of an individual’s access privileges to the information, services, and resources for which they currently have clearance, authorization, and need-to-know when such clearance, authorization and need-to-know no longer exists).
4. Turning in of keys, tokens, or cards that allow access (formal, documented procedure to ensure all physical items that allow a terminated employee to access a property, building, or equipment are retrieved from that employee, preferably before termination).
12. Training (education concerning the vulnerabilities of the health information in an entity’s possession and ways to ensure the protection of that information) that includes all of the following implementation features:
1. Awareness training for all personnel, including management personnel (in security awareness, including, but not limited to, password maintenance, incident reporting, and viruses and other forms of malicious software).
2. Periodic security reminders (employees, agents, and contractors are made aware of security concerns on an ongoing basis)
3. User education concerning virus protection (training relative to user awareness of the potential harm that can be caused by a virus, how to prevent the introduction of a virus to a computer system, and what to do if a virus is detected).
4. User education in importance of monitoring log-in success or failure and how to report discrepancies (training in the user’s responsibility to ensure the security of health care information).
5. User education in password management (type of user training in the rules to be followed in creating and changing passwords and the need to keep them confidential).

(b) Physical safeguards to guard data integrity, confidentiality, and availability. Protection of physical computer systems and related buildings and equipment from fire and other natural and environmental hazards, as well as from intrusion. It covers the use of locks, keys, and administrative measures used to control access to computer systems and facilities. Physical safeguards must include all of the following requirements and implementation features:

1. Assigned security responsibility (practices established by management to manage and supervise the execution and use of security measures to protect data and to manage and supervise the conduct of personnel in relation to the protection of data).
2. Media controls (formal, documented policies and procedures that govern the receipt and removal of hardware/software (such as diskettes and tapes) into and out of a facility) that include all of the following implementation features:
   1. Access control.
   2. Accountability (the property that ensures that the actions of an entity can be traced uniquely to that entity).
   3. Data backup (a retrievable, exact copy of information).
   4. Data storage (the retention of health care information pertaining to an individual in an electonic format).
   5. Disposal (final disposition of electronic data, and/or the hardware on which electronic data is stored).
3. Physical access controls (limited access) (formal, documented policies and procedures to be followed to limit physical access to an entity while ensuring that properly authorized access is allowed) that include all of the following implementation features:
   1. Disaster recovery (the process enabling an entity to restore any loss of data in the event of fire, vandalism, natural disaster, or system failure).
   2. An emergency mode operation (access controls in place that enable an entity to continue to operate in the event of fire, vandalism, natural disaster, or system failure).
   3. Equipment control (into and out of site) (documented security procedures for bringing hardware and software into and out of a facility and for maintaining a record of that equipment. This includes, but is not limited to, the marking, handling, and disposal of hardware and storage media.)
   4. A facility security plan (a plan to safeguard the premises and building (exterior and interior) from unauthorized physical access and to safeguard the equipment therein from unauthorized physical access, tampering, and theft).
   5. Procedures for verifying access authorizations before granting physical access (formal, documented policies and instructions for validating the access privileges of an entity before granting those privileges).
   6. Maintenance records (documentation of repairs and modifications to the physical components of a facility, such as hardware, software, walls, doors, and locks).
   7. Need-to-know procedures for personnel access (a security principle stating that a user should have access only to the data he or she needs to perform a particular function).
   8. Procedures to sign in visitors and provide escorts, if appropriate (formal documented procedure governing the reception and hosting of visitors).
   9. Testing and revision (the restriction of program testing and revision to formally authorized personnel).
4. Policy and guidelines on work station use (documented instructions/procedures delineating the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific computer terminal site or type of site, dependent upon the sensitivity of the information accessed from that site).
5. A secure work station location (physical safeguards to eliminate or minimize the possibility of unauthorized access to information; for example, locating a terminal used to access sensitive information in a locked room and restricting access to that room to authorized personnel, not placing a terminal used to access patient information in any area of a doctor’s office where the screen contents can be viewed from the reception area).
6. Security awareness training (information security awareness training programs in which all employees, agents, and contractors must participate, including, based on job responsibilities, customized education programs that focus on issues regarding use of health information and responsibilities regarding confidentiality and security).

(c) Technical security services to guard data integrity, confidentiality, and availability (the processes that are put in place to protect information and to control individual access to information). These services include the following requirements and implementation features:

1. The technical security services must include all of the following requirements and the specified implementation features:
   1. Access control that includes:
      1. A procedure for emergency access (documented instructions for obtaining necessary information during a crisis), and
      2. At least one of the following implementation features:
         1. Context-based access (an access control procedure based on the context of a transaction (as opposed to being based on attributes of the initiator or target)).
         2. Role-based access.
         3. User-based access.
      3. The optional use of encryption.
   2. Audit controls (mechanisms employed to record and examine system activity).
   3. Authorization control (the mechanism for obtaining consent for the use and disclosure of health information) that includes at least one of the following implementation features:
      1. Role-based access.
      2. User-based access.
   4. Data authentication. (The corroboration that data has not been altered or destroyed in an unauthorized manner. Examples of how data corroboration may be assured include the use of a check sum, double keying, a message authentication code, or digital signature.)
   5. Entity authentication (the corroboration that an entity is the one claimed) that includes:
      1. Automatic logoff (a security procedure that causes an electronic session to terminate after a predetermined time of inactivity, such as 15 minutes), and
      2. Unique user identifier (a combination name/number assigned and maintained in security procedures for identifying and tracking individual user identity).
      3. At least one of the following implementation features:
         1. Biometric identification (an identification system that identifies a human from a measurement of a physical feature or repeatable action of the individual (for example, hand geometry, retinal scan, iris scan, fingerprint patterns, facial characteristics, DNA sequence characteristics, voice prints, and hand written signature)).
         2. Password.
         3. Personal identification number (PIN) (a number or code assigned to an individual and used to provide verification of identity).
         4. A telephone callback procedure (method of authenticating the identity of the receiver and sender of information through a series of "questions" and "answers" sent back and forth establishing the identity of each). For example, when the communicating systems exchange a series of identification codes as part of the initiation of a session to exchange information, or when a host computer disconnects the initial session before the authentication is complete, and the host calls the user back to establish a session at a predetermined telephone number.
         5. Token.
2. Reserved.

(d) Technical security mechanisms (processes that are put in place to guard against unauthorized access to data that is transmitted over a communications network).

1. If an entity uses communications or network controls, its security standards for technical security mechanisms must include the following:
   1. The following implementation features
      1. Integrity controls (a security mechanism employed to ensure the validity of the information being electronically transmitted or stored).
      2. Message authentication (ensuring, typically with a message authentication code, that a message received (usually via a network) matches the message sent).
   2. One of the following implementation features:
      1. Access controls (protection of sensitive communications transmissions over open or private networks so that they cannot be easily intercepted and interpreted by parties other than the intended recipient).
      2. Encryption.
2. If an entity uses network controls (to protect sensitive communication that is transmitted electronically over open networks so that it cannot be easily intercepted and interpreted by parties other than the intended recipient), its technical security mechanisms must include all of the following implementation features:
   1. Alarm. (In communication systems, any device that can sense an abnormal condition within the system and provide, either locally or remotely, a signal indicating the presence of the abnormality. The signal may be in any desired form ranging from a simple contact closure (or opening) to a time-phased automatic shutdown and restart cycle.)
   2. Audit trail (the data collected and potentially used to facilitate a security audit).
   3. Entity authentication (a communications or network mechanism to irrefutably identify authorized users, programs, and processes and to deny access to unauthorized users, programs, and processes).
   4. Event reporting (a network message indicating operational irregularities in physical elements of a network or a response to the occurrence of a significant task, typically the completion of a request for information).

§ 142.310 Electronic signature standard.

(a) General rule.

If an entity elects to use an electronic signature in a transaction as defined in § 142.103, or if an electronic signature is required by a transaction standard adopted by the Secretary, the entity must apply the electronic signature standard described in paragraph (b) of this section to that transaction.

(b) Standard.

An electronic signature is the attribute affixed to an electronic document to bind it to a particular entity. An electronic signature secures the user authentication (proof of claimed identity) at the time the signature is generated; creates the logical manifestation of signature (including the possibility for multiple parties to sign a document and have the order of application recognized and proven); supplies additional information such as time stamp and signature purpose specific to that user; and ensures the integrity of the signed document to enable transportability of data, interoperability, independent verifiability, and continuity of signature capability. Verifying a signature on a document verifies the integrity of the document and associated attributes and verifies the identity of the signer.

The standard for electronic signature is a digital signature. A "digital signature" is an electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters so that the identity of the signer and the integrity of the data can be verified.

(c) Required implementation features.

If an entity uses electronic signatures, the signature method must assure all of the following features:

1. Message integrity (the assurance of unaltered transmission and receipt of a message from the sender to the intended recipient).
2. Nonrepudiation (strong and substantial evidence of the identity of the signer of a message, and of message integrity, sufficient to prevent a party from successfully denying the origin, submission, or delivery of the message and the integrity of its contents).
3. User authentication (the provision of assurance of the claimed identity of an entity).

(d) Optional implementation features.

If an entity uses electronic signatures, the entity may also use, among others, any of the following implementation features:

1. Ability to add attributes (one possible capability of a digital signature technology; for example, the ability to add a time stamp as part of a digital signature).
2. Continuity of signature capability (the concept that the public verification of a signature must not compromise the ability of the signer to apply additional secure signatures at a later date).
3. Countersignatures. (The capability to prove the order of application of signatures. This is analogous to the normal business practice of countersignatures, where a party signs a document that has already been signed by another party.)
4. Independent verifiability (the capability to verify the signature without the cooperation of the signer).
5. Interoperability (the applications used on either side of a communication, between trading partners and/or between internal components of an entity, are able to read and correctly interpret the information communicated from one to the other).
6. Multiple signatures. (With this feature, multiple parties are able to sign a document. Conceptually, multiple signatures are simply appended to the document.)
7. Transportability of data (the ability of a signed document to be transported over an insecure network to another system, while maintaining the integrity of the document, including content, signatures, signature attributes, and (if present) document attributes).

§ 142.312 Effective date of the initial implementation of the security and electronic signature standards.

(a) General rules.

Except for a small health plan (defined at § 142.103), each entity designated in § 142.302 must comply with the requirements of this subpart by [24 months after the effective date of the final rule in the Federal Register].

A delay in an effective date for using a standard transaction described in this part does not delay the effective dates described in paragraphs (a)(1) and (b) of this section.

The requirements of the security standard may be implemented over time. Implementation must be completed by the applicable effective date.

(b) Small health plans.

A small health plan must comply with the requirements of this subpart by [36 months after the effective date of the final rule in the Federal Register].

Go to TOP

HIPAA SECURITY MATRIX