HomeMy WebLinkAbout30490COSS MOU No. 15-MOU-00576
DHCS 14-90495
Agreement No. 17-392
GLOBAL MEMORANDUM OF UNDERSTANDING
CHILD WELFARE SERVICES
I. RECITALS
Page 1
This Memorandum of Understanding (MOU) is entered into by and between the California
Department of Social Services (COSS), the California Department of Health Care Services
(DHCS), and those California Counties and Title IV-E Tribes that have agreed to the terms and
conditions of this MOU by becoming signatories to this MOU (hereafter "parties"); to set forth the
terms and conditions for the exchange of confidential data, collected and retained by COSS and
DHCS (Department(s)), for the purpose of matching the confidential data, hereinafter referred to
as 'matched data,' to administer and implement the applicable federal and/or state health and
public social service programs described herein. This MOU also sets forth the terms and
conditions imposed on each Department, when it is necessary for program purposes, to share
identifiable and de-identified matched data with signatory California counties and Title IV-E
Tribes (hereafter "counties or tribes"), authorized entities and de-identified data with the public.
COSS and DHCS, pursuant to Welfare and Institutions Code (WIC), Division 9, § 10000 et seq.,
are responsible for the administration and delivery of public social services.
WIC § 10051 defines 'public social services' as:
" ... activities and functions of state and local government administered or
supervised by the department or the State Department of Health Services and '
involved in providing aid or services or both, including health care services and
medical assistance, to those people of the state who, because of their economic
circumstances or social conditions, are in need thereof and may benefit thereby."
Specifically, COSS is the single state agency under Title IV of the Social Security Act that is
responsible for oversight of county and community agencies in the implementation of child
welfare services programs which includes services for children in foster care and other ~rvices
provided on behalf of children who are or are alleged to be the victims of child abuse, neglect, or
exploitation. COSS responsibilities include, but are not limited to, implementing tt)e state Health
Care Oversight Plan under Title IV-8 and IV-E to ensure that the physical and mental health
needs of children in foster care are identified and met. Pursuant to WIC § 10850, COSS is
.authorized to provide confidential data to county public agencies, private agencies, and Native
American tribes with a Title IV-E agreement pursuant to WIC § 10553.1 (hereinafter Title IV-E
tribe) that are directly connected with the administration of these programs by providing, or
securing, public social services, for or on behalf of applicants or recipients. ·
Specifically, DHCS is the single state agency under Title XIX of the Social Security Act that is
responsible for operating and overseeing the federal Medicaid program in California, hereafter
referred to as Medi-Cal. DHCS responsibilities, include, but are not limited to, ensuring high-
quality and efficient health care services are provided to Medi-Cal beneficiaries, which
categorically include children in foster care and former foster youth who attain age 18 while in a
foster care placement. Pursuant to the Health Insurance Portability and Accountability Act of
1996 (HIPM), DHCS is authorized to provide and exchange protected health information (PHI)
of an individual for the purposes of treatment, payment, and health care operations (See 45
CFR § · 164.502). Health care operations includes: (a) quality assessment and improvement
activities, including case management and care coordination; (b) competency assurance
I
COSS MOU No. 15-MOU-00576
DHCS 14-90495
I. RECITALS
GLOBAL MEMORANDUM OF UNDERSTANDING
CHILD WELFARE SERVICES
Page 1
This Memorandum of Understanding (MOU) is entered into by and between the California
Department of Social Services (COSS}, the California Department of Health Care Services
(DHCS}, and those California Counties and Title IV-E Tribes that have agreed to the terms and
conditions of this MOU by becoming signatories to this MOU (hereafter "parties"); to set forth the
terms and conditions for the exchange of confidential data, collected and retained by COSS and
DHCS (Department(s)}, for the purpose of matching the confidential data, hereinafter referred to
as 'matched data.' to administer and implement the applicable federal and/or state health and
public social service programs described herein. This MOU also sets forth the terms and
conditions imposed on each Department, when it is necessary for program purposes, to share
identifiable and de-identified matched data with signatory California counties and Title IV-E
Tribes (hereafter "counties or tribes"}, authorized entities and de-identified data with the public.
COSS and DHCS, pursuant to Welfare and Institutions Code (WIC), Division 9, § 10000 et seq.,
are responsible for the administration and delivery of public social services.
WIC § 10051 defines 'public social services' as:
" ... activities and functions of state and local government administered or
supervised by the department or the State Department of Health Services an_d 1
involved in providing aid or services or both, including health care services and
medical assistance, to those people of the state who, because of their economic
circumstances or social conditions, are in need thereof and may benefit thereby."
Specifically, COSS is the single state agency under Title IV of the Social Security Act that is
responsible for oversight of county and community agencies in the implementation of child
welfare services programs which includes services for children in foster care and other ¥_rvices
provided on behalf of children who are or are alleged to be the victims of child abuse, neglect, or
exploitation. COSS responsibilities include, but are not limited to, implementing ~~e state Health
Care Oversight Plan under Title IV-B and IV-E to ensure that the physical and rflental health
needs of children in foster care are identified and met. Pursuant to WIC § 10850, COSS is
authorized to provide confidential data to county public agencies, private agencies, and Native
American tribes with a Title IV-E agreement pursuant to WIC § 10553.1 (hereinafter Title IV-E
tribe) that are directly connected with the administration of these programs by providing, or
securing, public social services, for or on behalf of applicants or recipients.
Specifically, DHCS is the single state agency under Title XIX of the Social Security Act that is
responsible for operating and overseeing the federal Medicaid program in California, hereafter
referred to as Medi-Cal. DHCS responsibilities, include, but are not limited to, ensuring high-
quality and efficient health care services are provided to Medi-Cal beneficiaries, which
categorically include children in foster care and former foster youth who attain age 18 while in a
foster care placement. Pursuant to the Health Insurance Portability and Accountability Act of
1996 (HIPAA}, DHCS is authorized to provide and exchange protected health information (PHI)
of an individual for the purposes of treatment, payment, and health care operations (See 45
CFR § 164.502). Health care operations includes: (a) quality assessment and improvement
activities, including case management and care coordination; (b) competency assurance
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Page 2
activities, including provider or health plan performance evaluation, credentialing, and
accreditation; (c) conducting or arranging for medical reviews, audits, or legal services, including
fraud and abuse detection and compliance programs; (d) specified insurance functions, such as
underwriting, risk rating, and reinsuring risk; (e) business planning, development, management,
and administration; and (f) business management and general administrative activities (See 45
CFR§ 164.501 ).
Specifically, pursuant to WIC §10800, the counties are responsible for the administration and
provision of public social services, including child welfare services, in each county of the state.
The provision of public social services in the counties must comply with state and federal laws
including the regulations of the COSS and DHCS. Further, Title IV-E tribes, through their
agreements with either the State or directly with the federal government, are responsible for
ensuring the health and safety of children or non-minor dependents receiving child welfare
services under the jurisdiction of the tribe.
Based on the federal and state authority of each Department, the obligation of the counties and
Title IV-E tribes to administer public social services, and for the purpose of complying with each
Department's respective and mutual responsibilities and requirements as it pertains to children
or non-minor dependents receiving child welfare services and former foster youth, the parties
hereby agree to the following terms and conditions in the exchange of confidential data and use
of matched confidential data.
II. PURPOSE
The parties agree to the exchange of both confidential and non-confidential data. The use and
disclosure of such data shall be limited to the following purposes:
1. Analysis and reporting for the purposes set forth in 42 USC § 622(b)(15) which includes, but
is not limited to:
a) Ongoing oversight of health care services for any children or non-minor dependents
receiving child welfare services;
b) Ensuring a coordinated strategy to identify and respond to the health care needs of
children or non-minor dependents receiving child welfare services; and
c) Ensuring Medi-Cal enrollment for former foster youth up to age 26 and, through data
sharing, facilitating the extension of Medi-Cal enrollment of existing foster care youth up
to age 26 as they exit the program.
2. Analysis, reporting, and auditing to provide ongoing administration, operation oversight,
coordination, program monitoring, and evaluation of health treatment, including mental
health services and pharmaceutical services to children or non-minor dependents receiving
child welfare services.
3. Reporting federal Adoption and Foster Care Analysis and Reporting System (AFCARS) data
elements as described per§ 479 of the Social Security Act and 45 CFR § 1355.
4. To share amongst the parties, as applicable and appropriate, matched data containing
confidential information and de-identified data, reports and analyses based upon matched
data to support the administration and provision of public social services to children or non-
minor dependents receiving child welfare services.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Ill. DEFINITIONS
Page 3
"Breach" shall have the meaning given to such term under HIPAA and the HIPAA regulations
and includes any known or suspected information security incidents (intentional or unintentional,
that cause or may cause loss, damage, destruction, misuse, or unauthorized disclosure of
information, as provided in the Social Security Administration Information Exchange Agreement
(SSA IEA)); the COSS Confidentiality and Security Requirements for California State Agencies;
and the California Information Practices Act.
"Children or non-minor dependents receiving child welfare services" means children or non-
minor dependents on whose behalf the county child welfare agency or probation department is
providing child welfare services as described in WIC § 16501 (a). This includes, but is not
limited to, the following:
1. Children and non-minor dependents who are dependents of the juvenile court or are
receiving voluntary child welfare services.
2. Children and non-minor dependents who are wards of the juvenile court and are in a
foster care placement.
3. Children and non-minor dependents who are receiving child welfare services provided
by a tribe with a Title IV-E agreement.
"Confidential data" means Information that identifies or is substantially likely to identify an
individual and that is exempt from disclosure under the provisions of the California Public
Records Act (Government Code Sections 6250-6265) or has restrictions on disclosure in
accordance with other applicable state or federal laws, including but not limited to WIC 10850.
As used in this MOU Confidential data may include Protected Health Information (PHI}, or
Individually Identifiable Health Information as defined in HIPAA, 45 CFR 160.103; or "Limited
data set (LOS)" as defined in 45 CFR 164.514; or Personal Information (Pl}, as defined in
California Civil Code,§§ 1798.3, 1798.24 and 1798.29; or Personally Identifiable Information
(Pll}, as defined in the Social Security Administration Information Exchange Agreement (SSA
IEA) and DHCS Business Associate Addendum (BAA).
"Counties" means the largest political subdivision of the State having corporate powers (Govt.
Code section 23000). As used in this MOU counties refers to the current 58 counties of
California.
"Data" is a representation of facts, or instructions in a formalized manner suitable for
communication, interpretation, or processing by humans or automated means. As used in this
MOU data would refer to information related to children receiving child welfare services or non-
minor dependents or former foster youth.
"Alcohol and Drug Abuse Patient Records data" covered by 42 CFR Part 2, is excluded from
this MOU.
"De-identified data" means information that does not identify an individual such that there is no
reasonable basis to believe that the information provided can be used to identify an individual.
HIPAA provides that data can be considered de-identified if a person experienced in statistical
methods for rendering information not identifiable determines the risk is small that the
information could be used to identify an individual or specific identifiers identified in the HIPAA
regulations are removed (45 CFR 164.514(a) and (b)(1) or (b)(2)). De-identified data is not PHI.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Page4
"Department(s)" means the California Department of Social Services and/or the California
Department of Health Care Services.
"Former Foster Youth" means a former non-minor dependent, as defined by WIC § 11400(v),
who was in foster care on his or her 18th birthday and is under the age of 26 at the time of any
request for data, regardless of whether the youth is receiving any child welfare service.
"Matched data" means the combining of confidential health and child welfare services
information from a covered entity to a business associate for analyses and use that relates to
the health care and child welfare services operations of the respective entities (also known as
data aggregation under 45 CFR 164.501 ).
"Personal Information" (Pl) means any information that is maintained by an agency that
identifies or describes an individual, including, but not limited to, his or her name, social security
number, physical description, home address, home telephone number, education, financial
matters, and medical or employment history. It includes statements made by, or attributed to,
the individual." (CA Civil Code section 1798.3)
"Personally Identifiable Information" (Pll) is any information about an individual maintained by an
agency, including (1) any information that can be used to distinguish or trace an individual's
identity, such as name, social security number, date and place of birth, mother's maiden name,
or biometric records; and (2) any other information that is linked or linkable to an individual, such
as medical, educational, financial, and employment information. An item such as date and
place of birth, mother's maiden name, or father's surname is Pll, regardless of whether
combined with other data. (Electronic Information Exchange Security Requirements and
Procedures for State and Local Agencies Exchanging Electronic Information with the Social
Security Administration, ver. 6.0.2, (April 2014) p. 9)
"Protected Health Information" (PHI) means individually identifiable health information. (45 CFR
160.103).
"Security Incident" means any event (intentional or unintentional) that causes the loss, damage
to, destruction, misuse or unauthorized disclosure of CDSS/DHCS information assets.
"Use" means the sharing, employment, application, utilization, examination or analysis of data.
(45 CFR 160.103).
IV. CONFIDENTIAL DATA REQUESTS
A. Identification of Confidential Data
The parties agree to identify and share with each other data which is collected and retained
by each party pertaining to children or non-minor dependents receiving or previously
receiving child welfare services. The only data exchanged will be for the stated purposes in
section II, in order to comply with HIPAA. Data will include, but not be limited to, the
following categories of information:
• Eligibility Data,
• Demographic Data,
• Social Services Data,
• Medical Data,
• Mental Health Data, and
• Payment Data.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
B. Tracking Process for Exchange of Data
Page 5
Within 30 days of the execution of this MOU, COSS and DHCS shall develop, following
consultation with counties and tribes, and agree upon a written request and response
process for the exchange of data between the parties. This process shall include a tracking
system for logging each data request, extract, exchange, and match, as applicable.
Development and agreement regarding this process shall not forestall data sharing
consistent with the terms of this MOU in advance of that process; however, formal record of
such data sharing shall be made pursuant to the process once the process has been agreed
upon.
At the time of a request for data, the applicable parties shall mutually assess and agree
upon the purpose of the data and the intended retention period for the data based upon its
purpose and use by the parties. At the expiration of the agreed upon purpose for the data
and matched data sets the data shall be returned or destroyed pursuant to the HIPAA
Business Associate Addendum (Exhibit A) and the COSS Confidentiality and Security
Requirements (Exhibit C) unless the parties mutually agree in writing to a new purpose and
retention period for the data and matched data sets. At minimum, the tracking system shall
include:
1. Identification of the individual(s) responsible in each party to receive data and data
requests, authorize the exchange or provision of data for his/her party, and be
responsible for providing the requested data to the other party.
2. A log that tracks each data set requested, extracted, exchanged and/or matched, under
this MOU. The log must include; at a minimum, the following about the data to be
exchanged:
a) Data elements;
b) Population;
c) Relevant time period;
d) Purpose;
e) Request date;
f) Delivery date;
g) Retention period;
h) Frequency of data provision;
i) Authority; and
j) Person who reviewed and authorized the release, pursuant to the written request.
C. Process for Requesting Data and Matched Data
1. The requesting party shall provide to the providing party's Project Representative
identified pursuant to Section 8(1) of this MOU a written request for data and/or matched
data using prescribed formats and following the agreed upon data request process. The
written request shall describe the information requested, including but not limited to the
purpose and intended use of the requested data; the authority for the intended use of the
data; how the intended use is in accordance with the purposes of this MOU; and who the
intended users are.
CDSS MOU No. 15-MOU-00576
DHCS 14-90495
2. The request shall also include information regarding the following:
a) Population;
b) Relevant time period;
c) Request date;
d) Delivery date;
e) Retention period; and
f) Frequency of data provision;
Page 6
Upon receipt of the written request, the applicable parties will evaluate the request for
completeness, for compliance with this MOU and applicable laws. Requests shall be
prioritized, if necessary, at the sole discretion of the data owner, although reasonable effort
shall be made to accommodate the needs of the requesting party. If the data or matched
data will be provided by the DHCS or COSS to a county or tribe, then COSS will coordinate
the planning, format, and delivery with the requesting party.
D. Data Sharing between the Parties in Compliance With All Applicable Laws
1. Each party shall be responsible for ensuring that any data that is shared, matched,
exchanged or used is done so in compliance with all applicable state and federal laws.
2. When COSS is accessing or using confidential data provided by DHCS, COSS agrees to
comply with the provisions of the DHCS HIPAA Business Associate Addendum
(Exhibit A), the IEA SSA and DHCS Agreement (Exhibit B.1), attached to this MOU and
all Federal and State privacy and security laws.
3. When DHCS is accessing and using confidential data provided by COSS, DHCS agrees
to comply with the provisions of the CDSS Confidentiality and Security Requirements for
California State Agencies (Exhibit C), the IEA SSA and COSS Agreement (Exhibit B.2),
and all Federal and State privacy and security laws.
4. Matched confidential data furnished by COSS and/or DHCS that is transmitted to other
parties to this MOU is subject to the DHCS HIPAA Business Associate Addendum
(Exhibit A), COSS Confidentiality and Security Requirements (Exhibit C), the SSA
agreements, (Exhibits B.1 and B.2), and all federal and state privacy and security laws.
5. Matched confidential data furnished by any party pursuant to this MOU will be used or
disclosed only as specifically provided by this MOU. Matched confidential data furnished
by any party pursuant to this MOU shall not be disclosed for use to any person other
than the authorized parties' staff who is assigned to the use the data for the purposes
authorized under this MOU.
6. Each party shall maintain a written record of staff authorized to access and who have
accessed (users) the confidential data that has been exchanged pursuant to this MOU.
Each party shall provide a copy of its users that have accessed the confidential data
provided pursuant to this MOU, to other parties upon request.
7. Pursuant to this MOU and for purposes of their respective program responsibilities,
either party may transmit confidential data, matched data sets, and reports regarding
children or non-minor dependents receiving child welfare services. Data and matched
datasets containing confidential data may be shared only for purposes directly
connected with the administration of child welfare services or health care services.
CDSS MOU No. 15-MOU-00576
DHCS 14-90495
Page 7
When transmitting confidential data to another party, both the sending and receiving
party shall comply with all appropriate privacy and security requirements and
procedures, including the use of encryption.
E. Data Sharing Activities
The parties shall mutually engage in the following activities to support the data sharing
between the parties authorized by this MOU by:
1. Participating in the planning and design of the exchange of data.
2. Providing access to completed data extracts and matches, in a manner and at a time
mutually agreed upon.
3. Requesting additional information from the data extracts and matched data sets, as
needed by either party for administrative purposes, including verifying and tracking the
provision of information or services to applicants for and recipients of programs.
F. Breach Response Process by the Parties for Matched Data
1. The party in possession of the data when the breach occurs and who experiences the
breach will be responsible for reporting to all pertinent parties, for complying with all
applicable laws, and for all costs and liabilities related to the breach.
2. If CDSS is responsible for a breach, CDSS will report the breach to and comply with
DHCS HIPAA Business Associate Addendum (Exhibit A) and the DHCS' SSA
agreement (Exhibit B.1 ).
3. If DHCS is responsible for the breach of CDSS provided data, DHCS will report the
breach to and comply with CDSS' Confidentiality and Security Requirements (Exhibit C)
and the CDSS SSA agreement (Exhibit B.2).
4. If a county or tribe is responsible for the breach, the county or tribe will be responsible
for the breach notifications and reporting the breach to CDSS and DHCS as set forth in
the DHCS HIPAA Business Associate Addendum, (Exhibit A); the CDSS Confidentiality
and Security Requirements (Exhibit C), and the SSA agreements, (Exhibits B.1 and B.2).
5. The persons to be notified and the process for notice in the event of a breach are
identified in the DHCS HIPAA Business Associate Addendum (Exhibit A) and CDSS
Confidentiality and Security Requirements (Exhibit C) except that the contact information
for CDSS and DHCS are:
Nola Niegel
Acting Information Security Officer
Information Systems Division
California Department of Social Services
744 P Street, M.S. 9-9-70
Sacramento, CA 95814
(916) 654-0694
iso@dss.ca.gov
COSS MOU No. 15-MOU-00576
DHCS 14-90495
DHCS Privacy Officer
Privacy Officer
c/o: Office of HIPAA Compliance
Department of Health Care
Services
P.O. Box 997413, MS 4722
Sacramento, CA 95899-7 413
Email:
privacyofficer@dhcs.ca.gov
Telephone: (916) 445-4646
Fax: (916) 440-7680
Page 8
DHCS Information Security
Officer
Information Security Officer
DHCS Information Security
Office
P.O. Box 997413, MS 6400
Sacramento, CA 95899-7413
Email: iso(@dhcs.ca.gov
Fax: (916) 440-5537
Telephone: ITSD Service
Desk
(916) 440-
7000 or
(800) 579-
0874
V. RESPONSIBILITIES FOR DATA DISSEMINATION OUTSIDE OF THE PARTIES OF THE
MOU
A. De-identified Data Released to Entities Outside of the Parties
De-identified data or reports containing only de-identified data provided pursuant this MOU
to the parties may be transmitted to outside parties. Data shall be de-identified in
compliance with HIPAA and other applicable laws and regulations, and the process for de-
identification of data provided herein.
B. Data Sharing by Parties with Authorized Entities or Contractors
Parties to this MOU may provide confidential or de-identified data, including matched data,
to authorized entities or contractors that have contracted with the parties for the provision of
program services to children or non-minor dependents receiving child welfare services if the
parties have determined that it is necessary for their ongoing, administration, oversight,
monitoring, evaluation, and reporting responsibilities. All such contracts must include the
Exhibits to this MOU. All data provided to authorized entities or contractors shall meet the
minimum necessary requirements of HIPAA.
C. Articles for Publication
1. CDSS/DHCS
COSS and DHCS may participate in the writing and reviewing of each other's reports
and articles that refer to or include information regarding the subject matters of this MOU
that are intended for publication. For the purpose of this MOU, publication means that
an article or report is intended to be provided or made available to the general public.
This includes posting reports, articles or data on the Internet or in any other public
medium or forum. Only de-identified information as defined by HIPAA shall be used for
publishing reports and/or articles that may or are made available to the public. The
process for de-identified data provided herein shall be used by the departments for
reaching mutual agreement on articles and reports for publication. This paragraph does
not apply, and mutual agreement by COSS and DHCS is not required, for reports (such
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Page 9
as outcome measures) that are produced by COSS or DHCS in the ordinary course of
the operation or administration of their own programs using only data in their respective
systems.
2. County or Tribe
Matched confidential data released to counties shall not be used for publications
produced by the counties or tribes. Only de-identified information as defined by HIPAA
shall be used for publishing reports and/or articles that may or are made available to the
public.
D. Other Special Reports and Analyses by the Parties
The parties may develop other special reports such as regional/geographic analyses,
demographic variations, and so forth under this MOU for each party's internal use. Only de-
identified data shall be included in any published analyses or reports.
E. Process for De-identification
1. CDSS/DHCS
Each Department is responsible for determining the sufficiency of the HIPAA de-
identification determination for its intended use of the de-identified data by the
Department. Prior to implementing the intended use of the de-identified data each
Department agrees to provide to the other Department for review, the proposed de-
identified data to be used. If the reviewing Department disagrees with the de-
identification determination that has occurred, the reviewing Department shall notify the
Department of its assessment and objections within five working days of receiving the
de-identified data. If the Departments cannot agree within 10 working days following the
notification of objections to the de-identified data, the matter shall immediately be
referred to the first level of the Dispute Resolution Process using the Form, Exhibit D.
2. County or Tribe
Each county or tribe is responsible for determining the sufficiency of the HIPAA de-
identification determination for its intended use of the de-identified data by the county or
tribe. Prior to the intended use of the de-identified data the county or tribe agrees to
provide to the Departments relevant information related to the de-identification. If either
of the Departments disagrees with the de-identification determination of the county or
tribe that has occurred and the parties cannot agree within 10 working days, the matter
shall immediately be referred to the first level of the County or Tribe Dispute Resolution
Process using the Form, Exhibit D.
F. Miscellaneous Requests for Data -PRA
1. CDSS/DHCS
In the event either Department receives a Public Records Act (PRA) request, a
subpoena, litigation-related request, or any other request for the confidential information
that is the subject of this MOU and not otherwise provided for herein, the Department
receiving the request shall immediately notify the other Department and meet and confer
as necessary on the appropriate response to the request.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
2. County or Tribe
Page 10
In the event that a County or Tribe receives a Public Records Act (PRA) request, a
subpoena, litigation-related request, or any other request for the confidential information
that is the subject of this MOU and not otherwise provided for herein, the county or tribe
shall immediately notify the Project Representatives of both Departments and meet and
confer as necessary on the appropriate response to the request.
G. Consent-CDSS/DHCS
If any issues of whether consent is needed from children or non-minor dependents receiving
child welfare services before confidential data can be used or shared with third parties for
the purposes of this MOU, DHCS and COSS agree to meet and confer, and within 30 days
to mutually agree, on a form or process for gaining the consent of the children or non-minor
dependents receiving child welfare services or the child's representative.
H. Existing Data Use Agreements Between COSS and DHCS
At the time of the execution of this MOU, there are existing data use agreements between
COSS and DHCS directly related to the purposes of this MOU. These existing agreements
shall continue in full force and effect until their expiration, at which time their purposes and
provisions shall be incorporated into and made a part of this MOU as though fully set forth
herein.
VI. TERM
A. CDSS/DHCS
The term of this MOU shall commence upon the approval and signature of the Director of
both Departments and shall continue in effect until cancelled by either Department. Written
notice of cancellation shall be provided by the cancelling Department to the other
Department no later than 180 days prior to the specified cancellation date.
B. County or Tribe
The term of this MOU with each county or tribe shall commence upon the approval and
signature of the County or Tribe and continue in effect until cancelled by the Departments or
County or Tribe. Written notice of cancellation shall be provided by the cancelling party to
the Department(s}, county or tribe or by the Department(s) to the county or tribe no later
than 180 days prior to the specified cancellation date.
VII. PAYMENT
There is no compensation payable to any of the parties in connection with this MOU.
VIII. AMENDMENT PROCESS
A. Non-Substantive Changes by the Parties
Any party may propose written non-substantive changes or revisions to the information,
activities and tasks of this MOU without amendment provided such changes do not alter the
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Page 11
overall goals and basic purpose of the MOU. The changes will be effective upon the mutual
agreement of the affected parties. The addition of individual Counties or Tribes to this MOU,
as provided herein, shall be a non-substantive change and shall not require a formal
amendment.
B. Substantive Changes by the Parties
A party, during the term of this MOU, may propose a substantive change or amendment to
the terms of this MOU. Such changes or amendments shall be proposed in writing to the
other parties, and the parties agree to meet and confer within 10 working days to discuss or
negotiate the proposed changes. The agreed-upon changes to this MOU shall be made
through an expedited amendment process that will be reviewed and approved by each
party's executive, program and legal staff and signed by the party's Director or designee.
The expedited amendment will be completed and processed within 30 days unless this time
is extended by the parties. This expedited amendment shall be binding on all parties upon
the approval and signature of the parties' Directors or their designee.
IX. DISPUTE RESOLUTION PROCESS
A. CDSS/DHCS
If a dispute arises between DHCS and COSS, the Departments must seek resolution using
the process outlined below.
1. The aggrieved department should first informally discuss the problem with the Project
Representative and Contract Manager of the other Department. If the problem cannot
be resolved informally, the aggrieved Department must direct the grievance together
with any evidence, in writing, to the Chief Deputy Director of the other department. The
grievance must state the issues in dispute, the legal authority or other basis for the
Department's position and the remedy sought. The Chief Deputy Director must render a
decision within ten (10) working days after receipt of the written grievance. The Chief
Deputy Director shall respond in writing to the aggrieved Department indicating his/her
decision and the reason(s) therefore. Should the aggrieved Department disagree with
the Chief Deputy Director's decision, the aggrieved Department may appeal to the
second level.
2. When appealing to the second level the aggrieved Department must prepare an appeal
indicating the reasons for disagreement with the Chief Deputy Director's decision. The
aggrieved Department shall include with its appeal a copy of its original statement of
dispute along with any supporting evidence and a copy of the Chief Deputy Director's
decision. The appeal shall be addressed to the Health and Human Services Agency
(HHSA) Secretary or his/her designee within ten (10) working days from receipt of the
Chief Deputy Director's decision. The HHSA Secretary or his/her designee shall meet
with the aggrieved Department to review the issues raised. A written decision signed by
the HHSA Agency Secretary or his/her designee shall be directed to the aggrieved
Department within twenty (20) working days of receipt of the second level appeal.
CDSS MOU No. 15-MOU-00576
DHCS 14-90495
Page 12
B. County or Tribe
If a dispute arises between the Departments and a County or Tribe, the County or Tribe
must seek resolution using the process outlined below.
1. The aggrieved party should first informally discuss the problem with the Project
Representative and Contract Manager of the other party. If the problem cannot be
resolved informally, the aggrieved party must direct the grievance together with any
evidence, in writing, to the Program Branch Chief of the Project Representative for
Department(s) or designee for the Tribe or County, as applicable. The grievance must
state the issues in dispute, the legal authority or other basis for the party's position and
the remedy sought. The party receiving the grievance must render a decision within ten
(10) working days after receipt of the written grievance of the other party. The grievance
shall be responded to in writing to the aggrieved party indicating their decision and
reasons therefore. Should the aggrieved party disagree with the decision, the aggrieved
party may appeal to the second level.
2. When appealing to the second level the aggrieved party must prepare an appeal
indicating the reasons for disagreement with the decision by the other party. The
aggrieved party shall include with its appeal a copy of their original statement of dispute
along with any supporting evidence and a copy of the prior decision of the other
party. The aggrieved party shall address the appeal to the other party's second level
appeal designee within ten ( 10) working days from receipt of the written decision of the
other party. (For the Departments the second level appeal designee will be the Deputy
Director of the division in which the branch is organized, or his/her designee; for the
County or Tribe the second level appeal will be to the County or Tribes designee.) The
second level appeal designee shall meet with the aggrieved party to review the issues
raised. A written decision signed by the second level appeal designee shall be directed
to the aggrieved party within twenty (20) working days of receipt of the second level
appeal.
X. SURVIVAL
The privacy, confidentiality, and security provisions of this MOU survive the termination or
expiration of this MOU.
XI. INCORPORATED EXHIBITS
The following exhibits are incorporated herein, and made a part hereof by this reference:
1) Exhibit A HIPAA Business Associate Addendum 15 pages
2) Exhibit B.1 IEA SSA and DHCS Agreement 74 pages
3) Exhibit B.2 IEA SSA and CDSS Agreement 77 pages
4) Exhibit C CDSS Confidentiality and Security Requirements 6 pages for California State AQencies
5) Exhibit D Form for Dispute Resolution 1 page
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Page 13
XII. PROJECT REPRESENTATIVES AND SIGNATORIES
The project representatives during the term of this MOU from the California Department of
Social Services will be:
Project Representative
Akhtar Khan
Branch Chief or designee
Research Services Branch
(916) 653-1800
Akhtar.Khan@dss.ca.gov
Contract Manager
Alicia Sandoval
Child Welfare and Data Analysis Bureau
Research Services Branch
(916) 653-1812
Alicia.Sandoval@dss.ca.gov
The project representatives during the term of this MOU from the California Department of
Health Care Services will be:
Project Representative
Linette Scott
Deputy Director or designee
Information Management Division
(916) 440-7639
Linette.Scott@dhcs.ca.gov
Contract Manager
Angelique Lastinger
Information Management Division
(916) 332-8573
Angelique.Lastinger@dhcs.ca.gov
Either department may make changes to the project representatives above by giving written
notice to the other party. Said changes shall not require an amendment to this Agreement.
Each County or Tribe signing this MOU will designate and identify to the Departments the
Project Representative for the County or Tribe that will be the single point of contact with the
Departments for County or Tribe to receive and make requests for data to the Departments.
XIII. COUNTY AND TRIBE-PROJECT REPRESENTATIVES AND SIGNATORIES
By signing this MOU, the County or Tribe signatory represents that he or she has authority to
bind and obligate the specific County or Tribe the signatory represents. On behalf of the County
or Tribe the signatory agrees to the terms, conditions and obligations of this MOU including but
not limited to ensuring the integrity, security, and confidentiality of all data provided by the
Departments. In addition, the signatory is responsible for permitting disclosure or any
distributions of the data to other County or Tribe entities or users and to permit only those
disclosures and uses that are consistent with this MOU and as permitted by law.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
This Memorandum of Understanding is not effective until signed by all parties.
California Department of Social Services
By: Date:
Will Lightbourne, Director
California Department of Health Care Services
By: Date: LJ../ S/lS-
Page 14
COSS MOU No. 15-MOU-00576
DHCS 14-90495
SIGNATURE PAGE FOR COUNTY
This Memorandum of Understanding is not effective until signed by all parties.
By:
ATTEST:
BERNICE E. SEIDEL, Cieri<
Board of Supervisors
.,c;h f\~) t "# e uty
Date: CS"uJo I\ 2..0\1 I
Page 15
CDSS MOU No. 15-MOU-00576
DHCS 14-90495
SIGNATURE PAGE FOR COUNTY
This Memorandum of Understanding is not effective until signed by all parties.
By: Date:
Page 15
1 IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the day and
2 year first hereinabove written.
3
4 COUNTY OF FRESNO
5
6
7
By~~~~~~~~~~~~
Brian Pacheco, Chairman
Board of Supervisors
BERNICE E. SEIDEL, Clerk
Board of Supervisors
By~~~~~~~~~~~
APPROVED AS TO LEGAL FORM:
8
9
10
11
12
13
14
15
16
DANIEL C. CEDERBORG, COUNTY COUNSEL
17
REVIEWED AND --=.:=>-· MENDED FOR
18 APPROVAL:
19
20
21
22
23
24
25
26
27
28
Fund/Subclass: N/ A
Organization: 56107001
Account/Program: NIA
DEN:DRP
\
- 1 -Fresno, CA
1 IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the day and
2 year first hereinabove written.
3
4 COUNTY OF FRESNO
5
6
7
8
9
By l4-
Brian Pacheco, Chairman
Board of Supervisors
BERNICE-E. SEIDEL, Clerk
Board of Supervisors
By Cf\. l)q"_, e_, --t~ ' ~ ~ t:s
APPROVED AS TO LEGAL FORM:
10
11
12
13
14
15
16
17
DANIEL C. CEDERBORG, COUNTY COUNSEL
REVIEWED AND ~~, .• MENDED FOR
18 APPROVAL:
19
20
21
22
23
24
25
26
27
28
Fund/Subclass: NI A
Organization: 56107001
Account/Program: NIA
DEN:DRP
- 1 -
Fresno, CA
COSS MOU No. 15-MOU-00576
DHCS 14-90495
SIGNATURE PAGE FOR TRIBE
This Memorandum of Understanding is not effective until signed by all parties.
By: Date:
Page 16
I. Recitals
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 1 of 15
HIPAA Business Associate Addendum
A. This Contract (Agreement) has been determined to constitute a business associate relationship under
the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191 ("HIPAA"), the
Health Information Technology for Economic and Clinical Health Act, Public Law 111-005 ('the HITECH
Act"), 42 U.S.C. section 17921 et seq., and their implementing privacy and security regulations at 45
CFR Parts 160 and 164 ("the HIPAA regulations").
B. The Department of Health Care Services ("DHCS") wishes to disclose to Business Associate certain
information pursuant to the terms of this Agreement, some of which may constitute Protected Health
Information ("PHI"), including protected health information in electronic media ("ePHI"), under federal
law, and personal information ("Pl") under state law.
C. As set forth in this Agreement, Contractor, here and after, is the Business Associate of DHCS acting on
DHCS' behalf and provides services, arranges, performs or assists in the performance of functions or
activities on behalf of DHCS and creates, receives, maintains, transmits, uses or discloses PHI and Pl.
DHCS and Business Associate are each a party to this Agreement and are collectively referred to as
the "parties."
D. The purpose of this Addendum is to protect the privacy and security of the PHI and Pl that may be
created, received, maintained, transmitted, used or disclosed pursuant to this Agreement, and to
comply with certain standards and requirements of HIPAA, the HITECH Act and the HIPAA regulations,
including, but not limited to, the requirement that DHCS must enter into a contract containing specific
requirements with Contractor prior to the disclosure of PHI to Contractor, as set forth in 45 CFR Parts
160 and 164 and the HITECH Act, and the Final Omnibus Rule as well as the Alcohol and Drug Abuse
patient records confidentiality law 42 CFR Part 2, and any other applicable state or federal law or
regulation. 42 CFR section 2.1 (b)(2)(B) allows for the disclosure of such records to qualified personnel
for the purpose of conducting management or financial audits, or program evaluation. 42 CFR Section
2.53(d) provides that patient identifying information disclosed under this section may be disclosed only
back to the program from which it was obtained and used only to carry out an audit or evaluation
purpose or to investigate or prosecute criminal or other activities, as authorized by an appropriate court
order.
E. The terms used in this Addendum, but not otherwise defined, shall have the same meanings as those
terms have in the HIPAA regulations. Any reference to statutory or regulatory language shall be to
such language as in effect or as amended.
II. Definitions
A. Breach shall have the meaning given to such term under HIPAA, the HITECH Act, the HIPAA
regulations, and the Final Omnibus Rule.
B. Business Associate shall have the meaning given to such term under HIPAA, the HITECH Act, the
HIPAA regulations, and the final Omnibus Rule.
C. Covered Entity shall have the meaning given to such term under HIPAA, the HITECH Act, the HIPAA
regulations, and Final Omnibus Rule.
D. Electronic Health Record shall have the meaning given to such term in the HITECH Act, including, but
not limited to, 42 U.S.C Section 17921 and implementing regulations.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 2 of 15
HIPAA Business Associate Addendum
E. Electronic Protected Health Information (ePHI) means individually identifiable health information
transmitted by electronic media or maintained in electronic media, including but not limited to electronic
media as set forth under 45 CFR section 160.103.
F. Individually Identifiable Health Information means health information, including demographic information
collected from an individual, that is created or received by a health care provider, health plan, employer
or health care clearinghouse, and relates to the past, present or future physical or mental health or
condition of an individual, the provision of health care to an individual, or the past, present, or future
payment for the provision of health care to an individual, that identifies the individual or where there is a
reasonable basis to believe the information can be used to identify the individual, as set forth under 45
CFR section 160.103.
G. Privacy Rule shall mean the HIPAA Regulation that is found at 45 CFR Parts 160 and 164.
H. Personal Information shall have the meaning given to such term in California Civil Code section
1798.29.
I. Protected Health Information means individually identifiable health information that is transmitted by
electronic media, maintained in electronic media, or is transmitted or maintained in any other form or
medium, as set forth under 45 CFR section 160.103.
J. Required by law, as set forth under 45 CFR section 164.103, means a mandate contained in law that
compels an entity to make a use or disclosure of PHI that is enforceable in a court of law. This
includes, but is not limited to, court orders and court-ordered warrants, subpoenas or summons issued
by a court, grand jury, a governmental or tribal inspector general, or an administrative body authorized
to require the production of information, and a civil or an authorized investigative demand. It also
includes Medicare conditions of participation with respect to health care providers participating in the
program, and statutes or regulations that require the production of information, including statutes or
regulations that require such information if payment is sought under a government program providing
public benefits.
K. Secretary means the Secretary of the U.S. Department of Health and Human Services ("HHS") or the
Secretary's designee.
L. Security Incident means the attempted or successful unauthorized access, use, disclosure,
modification, or destruction of PHI or Pl, or confidential data that is essential to the ongoing operation of
the Business Associate's organization and intended for internal use; or interference with system
operations in an information system.
M. Security Rule shall mean the HIPAA regulation that is found at 45 CFR Parts 160 and 164.
N. Unsecured PHI shall have the meaning given to such term under the HITECH Act, 42 U.S.C. section
17932(h), any guidance issued pursuant to such Act, and the HIPAA regulations.
Ill. Terms of Agreement
A. Permitted Uses and Disclosures of PHI by Business Associate
Permitted Uses and Disclosures. Except as otherwise indicated in this Addendum, Business
Associate may use or disclose PHI only to perform functions, activities or services specified in this
Agreement, for, or on behalf of DHCS, provided that such use or disclosure would not violate the
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 3of15
HIPAA Business Associate Addendum
HIPAA regulations, if done by DHCS. Any such use or disclosure must, to the extent practicable, be
limited to the limited data set, as defined in 45 CFR section 164.514(e)(2), or, if needed, to the
minimum necessary to accomplish the intended purpose of such use or disclosure, in compliance with
the HITECH Act and any guidance issued pursuant to such Act, the HIPAA regulations, the Final
Omnibus Rule and 42 CFR Part 2.
1. Specific Use and Disclosure Provisions. Except as otherwise indicated in this Addendum,
Business Associate may:
a. Use and disclose for management and administration. Use and disclose PHI for the proper
management and administration of the Business Associate provided that such disclosures are
required by law, or the Business Associate obtains reasonable assurances from the person to
whom the information is disclosed that it will remain confidential and will be used or further
disclosed only as required by law or for the purpose for which it was disclosed to the person,
and the person notifies the Business Associate of any instances of which it is aware that the
confidentiality of the information has been breached.
b. Provision of Data Aggregation Services. Use PHI to provide data aggregation services to
DHCS. Data aggregation means the combining of PHI created or received by the Business
Associate on behalf of DHCS with PHI received by the Business Associate in its capacity as the
Business Associate of another covered entity, to permit data analyses that relate to the health
care operations of DHCS.
8. Prohibited Uses and Disclosures
1. Business Associate shall not disclose PHI about an individual to a health plan for payment or health
care operations purposes if the PHI pertains solely to a health care item or service for which the
health care provider involved has been paid out of pocket in full and the individual requests such
restriction, in accordance with 42 U.S.C. section 17935(a) and 45 CFR section 164.522(a).
2. Business Associate shall not directly or indirectly receive remuneration in exchange for PHI, except
with the prior written consent of DHCS and as permitted by 42 U.S.C. section 17935(d)(2).
C. Responsibilities of Business Associate
Business Associate agrees:
1. Nondisclosure. Not to use or disclose Protected Health Information (PHI) other than as permitted
or required by this Agreement or as required by law.
2. Safeguards. To implement administrative, physical, and technical safeguards that reasonably and
appropriately protect the confidentiality, integrity, and availability of the PHI, including electronic
PHI, that it creates, receives, maintains, uses or transmits on behalf of DHCS, in compliance with
45 CFR sections 164.308, 164.310 and 164.312, and to prevent use or disclosure of PHI other than
as provided for by this Agreement. Business Associate shall implement reasonable and appropriate
policies and procedures to comply with the standards, implementation specifications and other
requirements of 45 CFR section 164, subpart C, in compliance with 45 CFR section 164.316.
Business Associate shall develop and maintain a written information privacy and security program
that includes administrative, technical and physical safeguards appropriate to the size and
complexity of the Business Associate's operations and the nature and scope of its activities, and
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 4of15
HIPAA Business Associate Addendum
which incorporates the requirements of section 3, Security, below. Business Associate will provide
DHCS with its current and updated policies.
3. Security. To take any and all steps necessary to ensure the continuous security of all
computerized data systems containing PHI and/or Pl, and to protect paper documents containing
PHI and/or Pl. These steps shall include, at a minimum:
a. Complying with all of the data system security precautions listed in Attachment A, the Business
Associate Data Security Requirements;
b. Achieving and maintaining compliance with the HIPAA Security Rule (45 CFR Parts 160 and
164), as necessary in conducting operations on behalf of DHCS under this Agreement;
c. Providing a level and scope of security that is at least comparable to the level and scope of
security established by the Office of Management and Budget in OMB Circular No. A-130,
Appendix Ill -Security of Federal Automated Information Systems, which sets forth guidelines
for automated information systems in Federal agencies; and
d. In case of a conflict between any of the security standards contained in any of these
enumerated sources of security standards, the most stringent shall apply. The most stringent
means that safeguard which provides the highest level of protection to PHI from unauthorized
disclosure. Further, Business Associate must comply with changes to these standards that
occur after the effective date of this Agreement.
Business Associate shall designate a Security Officer to oversee its data security program who
shall be responsible for carrying out the requirements of this section and for communicating on
security matters with DHCS.
D. Mitigation of Harmful Effects. To mitigate, to the extent practicable, any harmful effect that is known
to Business Associate of a use or disclosure of PHI by Business Associate or its subcontractors in
violation of the requirements of this Addendum.
E. Business Associate's Agents and Subcontractors.
1. To enter into written agreements with any agents, including subcontractors and vendors, to whom
Business Associate provides PHI or Pl received from or created or received by Business Associate
on behalf of DHCS, that impose the same restrictions and conditions on such agents,
subcontractors and vendors that apply to Business Associate with respect to such PHI and Pl under
this Addendum, and that comply with all applicable provisions of HIPAA, the HITECH Act the
HIPAA regulations, and the Final Omnibus Rule, including the requirement that any agents,
subcontractors or vendors implement reasonable and appropriate administrative, physical, and
technical safeguards to protect such PHI and Pl. Business associates are directly liable under the
HIPAA Rules and subject to civil and, in some cases, criminal penalties for making uses and
disclosures of protected health information that are not authorized by its contract or required by law.
A business associate also is directly liable and subject to civil penalties for failing to safeguard
electronic protected health information in accordance with the HIPAA Security Rule. A "business
associate" also is a subcontractor that creates, receives, maintains, or transmits protected health
information on behalf of another business associate. Business Associate shall incorporate, when
applicable, the relevant provisions of this Addendum into each subcontract or subaward to such
agents, subcontractors and vendors, including the requirement that any security incidents or
breaches of unsecured PHI or Pl be reported to Business Associate.
DHCS HIPAA BAA 2115
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 5 of 15
HIPAA Business Associate Addendum
2. In accordance with 45 CFR section 164.504(e)(1)(ii), upon Business Associate's knowledge of a
material breach or violation by its subcontractor of the agreement between Business Associate and
the subcontractor, Business Associate shall:
a. Provide an opportunity for the subcontractor to cure the breach or end the violation and
terminate the agreement if the subcontractor does not cure the breach or end the violation
within the time specified by DHCS; or
b. Immediately terminate the agreement if the subcontractor has breached a material term of the
agreement and cure is not possible.
F. Availability of lnfo~mation to DHCS and Individuals. To provide access and information:
1. To provide access as DHCS may require, and in the time and manner designated by DHCS (upon
reasonable notice and during Business Associate's normal business hours) to PHI in a Designated
Record Set, to DHCS (or, as directed by DHCS), to an Individual, in accordance with 45 CFR
section 164.524. Designated Record Set means the group of records maintained for DHCS that
includes medical, dental and billing records about individuals; enrollment, payment, claims
adjudication, and case or medical management systems maintained for DHCS health plans; or
those records used to make decisions about individuals on behalf of DHCS. Business Associate
shall use the forms and processes developed by DHCS for this purpose and shall respond to
requests for access to records transmitted by DHCS within fifteen (15) calendar days of receipt of
the request by producing the records or verifying that there are none.
2. If Business Associate maintains an Electronic Health Record with PHI, and an individual requests a
copy of such information in an electronic format, Business Associate shall provide such information
in an electronic format to enable DHCS to fulfill its obligations under the HITECH Act, including but
not limited to, 42 U.S.C. section 17935(e).
3. If Business Associate receives data from DHCS that was provided to DHCS by the Social Security
Administration, upon request by DHCS, Business Associate shall provide DHCS with a list of all
employees, contractors and agents who have access to the Social Security data, including
employees, contractors and agents of its subcontractors and agents.
G. Amendment of PHI. To make any amendment(s) to PHI that DHCS directs or agrees to pursuant to
45 CFR section 164.526, in the time and.manner designated by DHCS.
H. Internal Practices. To make Business Associate's internal practices, books and records relating to the
use and disclosure of PHI received from DHCS, or created or received by Business Associate on behalf
of DHCS, available to DHCS or to the Secretary of the U.S. Department of Health and Human Services
in a time and manner designated by DHCS or by the Secretary, for purposes of determining DHCS'
compliance with the HIPAA regulations. If any information needed for this purpose is in the exclusive
possession of any other entity or person and the other entity or person fails or refuses to furnish the
information to Business Associate, Business Associate shall so certify to DHCS and shall set forth the
efforts it made to obtain the information.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 6of15
HIPAA Business Associate Addendum
I. Documentation of Disclosures. To .document and make available to DHCS or (at the direction of
DHCS) to an Individual such disclosures of PHI, and information related to such disclosures, necessary
to respond to a proper request by the subject Individual for an accounting of disclosures of PHI, in
accordance with the HITECH Act and its implementing regulations, including but not limited to 45 CFR
section 164.528 and 42 U.S.C. section 17935(c). If Business Associate maintains electronic health
records for DHCS as of January 1, 2009, Business Associate must provide an accounting of
disclosures, including those disclosures for treatment, payment or health care operations, effective with
disclosures on or after January 1, 2014. If Business Associate acquires electronic health records for
DHCS after January 1, 2009, Business Associate must provide an accounting of disclosures, including
those disclosures for treatment, payment or health care operations, effective with disclosures on or
after the date the electronic health record is acquired, or on or after January 1, 2011, whichever date is
later. The electronic accounting of disclosures shall be for disclosures during the three years prior to
the request for an accounting.
J. Breaches and Security Incidents. During the term of this Agreement, Business Associate agrees to
implement reasonable systems for the discovery and prompt reporting of any breach or security
incident, and to take the following steps:
1. Notice to DHCS. (1) To notify DHCS immediately upon the discovery of a suspected security
incident that involves data provided to DHCS by the Social Security Administration. This notification
will be by telephone call plus email or fax upon the discovery of the breach. (2) To notify DHCS
within 24 hours by email or fax of the discovery of unsecured PHI or Pl in electronic media or in
any other media if the PHI or Pl was, or is reasonably believed to have been, accessed or acquired
by an unauthorized person, any suspected security incident, intrusion or unauthorized access, use
or disclosure of PHI or Pl in violation of this Agreement and this Addendum, or potential loss of
confidential data affecting this Agreement. A breach shall be treated as discovered by Business
Associate as of the first day on which the breach is known, or by exercising reasonable diligence
would have been known, to any person (other than the person committing the breach) who is an
employee, officer or other agent of Business Associate.
Notice shall be provided to the DHCS Program Contract Manager, the DHCS Privacy Officer and
the DHCS Information Security Officer. If the incident occurs after business hours or on a weekend
or holiday and involves data provided to DHCS by the Social Security Administration, notice shall
be provided by calling the DHCS EITS Service Desk. Notice shall be made using the "DHCS
Privacy Incident Report" form, including all information known at the time. Business Associate
shall use the most current version of this form, which is posted on the DHCS Privacy Office website
(www.dhcs.ca.gov, then select "Privacy" in the left column and then "Business Use" near the middle
of the page) or use this link:
http://www.dhcs.ca.gov/formsandpubs/laws/priv/Pages/DHCSBusinessAssociatesOnly.aspx
Upon discovery of a breach or suspected security incident, intrusion or unauthorized access, use or
disclosure of PHI or Pl, Business Associate shall take:
a. Prompt corrective action to mitigate any risks or damages involved with the breach and to
protect the operating environment; and
b. Any action pertaining to such unauthorized disclosure required by applicable Federal and State
laws and regulations.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 7 of 15
HIPAA Business Associate Addendum
2. Investigation and Investigation Report. To immediately investigate such security incident,
breach, or unauthorized access, use or disclosure of PHI or Pl. If the initial report did not include all
of the requested information marked with an asterisk, then within 72 hours of the discovery,
Business Associate shall submit an updated "DHCS Privacy Incident Report" containing the
information marked with an asterisk and all other applicable information listed on the form, to the
extent known at that time, to the DHCS Program Contract Manager, the DHCS Privacy Officer, and
the DHCS Information Security Officer:
3. Complete Report. To provide a complete report of the investigation to the DHCS Program
Contract Manager, the DHCS Privacy Officer, and the DHCS Information Security Officer within ten
(10) working days of the discovery of the breach or unauthorized use or disclosure. If all of the
required information was not included in either the initial report, or the Investigation Report, then a
separate Complete Report must be submitted. The report shall be submitted on the "DHCS Privacy
Incident Report" form and shall include an assessment of all known factors relevant to a
determination of whether a breach occurred under applicable provisions of HIPAA, the HITECH Act,
the HIPAA regulations and/or state law. The report shall also include a full, detailed corrective
action plan, including information on measures that were taken to halt and/or contain the improper
use or disclosure. If DHCS requests information in addition to that listed on the "DHCS Privacy
Incident Report" form, Business Associate shall make reasonable efforts to provide DHCS with
such information. If necessary, a Supplemental Report may be used to submit revised or additional
information after the completed report is submitted, by submitting the revised or additional
information on an updated "DHCS Privacy Incident Report" form. DHCS will review and approve or
disapprove the determination of whether a breach occurred, is reportable to the appropriate entities,
if individual notifications are required, and the corrective action plan.
4. Notification of Individuals. If the cause of a breach of PHI or Pl is attributable to Business
Associate or its subcontractors, agents or vendors, Business Associate shall notify individuals of the
breach or unauthorized use or disclosure when notification is required under state or federal law
and shall pay any costs of such notifications, as well as any costs associated with the breach. The
notifications shall comply with the requirements set forth in 42 U.S.C. section 17932 and its
implementing regulations, including, but not limited to, the requirement that the notifications be
made without unreasonable delay and in no event later than 60 calendar days. The DHCS
Program Contract Manager, the DHCS Privacy Officer, and the DHCS Information Security Officer
shall approve the time, manner and content of any such notifications and their review and approval
must be obtained before the notifications are made.
5. Responsibility for Reporting of Breaches. If the cause of a breach of PHI or Pl is attributable to
Business Associate or its agents, subcontractors or vendors, Business Associate is responsible for
all required reporting of the breach as specified in 42 U.S.C. section 17932 and its implementing
regulations, including notification to media outlets and to the Secretary. If a breach of unsecured
PHI involves more than 500 residents of the State of California or its jurisdiction, Business
Associate shall notify the Secretary of the breach immediately upon discovery of the breach. If
Business Associate has reason to believe that duplicate reporting of the same breach or incident
may occur because its subcontractors, agents or vendors may report the breach or incident to
DHCS in addition to Business Associate, Business Associate shall notify DHCS, and DHCS and
Business Associate may take appropriate action to prevent duplicate reporting. The breach
reporting requirements of this paragraph are in addition to the reporting requirements set forth in
subsection 1, above.
6. DHCS Contact Information. To direct communications to the above referenced DHCS staff, the
Contractor shall initiate contact as indicated herein. DHCS reserves the right to make changes to
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 8of15
HIPAA Business Associate Addendum
the contact information below by giving written notice to the Contractor. Said changes shall not
require an amendment to this Addendum or the Agreement to which it is incorporated.
DHCS Program DHCS Privacy Officer DHCS Information Security Officer
Contract Manager
See the Scope of Work Privacy Officer Information Security Officer
exhibit for Program c/o: Office of HIPAA Compliance DHCS Information Security Office
Contract Manager Department of Health Care Services P.O. Box 997413, MS 6400
information P.O. Box 997413, MS 4722 Sacramento, CA 95899-7 413
Sacramento, CA 95899-7413
Email: iso@dhcs.ca.gov
Email: 12rivac!i£officer@dhcs.ca.gov Fax: (916) 440-5537
Telephone: (916) 445-4646 Telephone: EITS Service Desk
(916) 440-7000 or
Fax: (916) 440-7680 (800) 579-0874
K. Termination of Agreement. In accordance with Section 13404(b) of the HITECH Act and to the extent
required by the HIPAA regulations, if Business Associate knows of a material breach or violation by
DHCS of this Addendum, it shall take the following steps:
1. Provide an opportunity for DHCS to cure the breach or end the violation and terminate the
Agreement if DHCS does not cure the breach or end the violation within the time specified by
Business Associate; or
2. Immediately terminate the Agreement if DHCS has breached a material term of the Addendum and
cure is not possible.
L. Due Diligence. Business Associate shall exercise due diligence and shall take reasonable steps to
ensure that it remains in compliance with this Addendum and is in compliance with applicable
provisions of HIPAA, the HITECH Act and the HIPAA regulations, and that its agents, subcontractors
and vendors are in compliance with their obligations as required by this Addendum.
M. Sanctions and/or Penalties. Business Associate understands that a failure to comply with the
provisions of HIPAA, the HITECH Act and the HIPAA regulations that are applicable to Business
Associate may result in the imposition of sanctions and/or penalties on Business Associate under
HIPAA, the HITECH Act and the HIPAA regulations.
IV. Obligations of DHCS
DHCS agrees to:
A. Notice of Privacy Practices. Provide Business Associate with the Notice of Privacy Practices that
DHCS produces in accordance with 45 CFR section 164.520, as well as any changes to such notice.
Visit the DHCS Privacy Office to view the most current Notice of Privacy Practices at:
http://www.dhcs.ca.gov/formsandpubs/laws/priv/Paqes/default.aspx or the DHCS website at
www.dhcs.ca.gov (select "Privacy in the left column and "Notice of Privacy Practices" on the right side
of the page).
B. Permission by Individuals for Use and Disclosure of PHI. Provide the Business Associate with any
changes in, or revocation of, permission by an Individual to use or disclose PHI, if such changes affect
the Business Associate's permitted or required uses and disclosures.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 9of15
HIPAA Business Associate Addendum
C. Notification of Restrictions. Notify the Business Associate of any restriction to the use or disclosure
of PHI that DHCS has agreed to in accordance with 45 CFR section 164.522, to the extent that such
restriction may affect the Business Associate's use or disclosure of PHI.
D. Requests Conflicting with HIPAA Rules. Not request the Business Associate to use or disclose PHI
in any manner that would not be permissible under the HIPAA regulations if done by DHCS.
V. Audits, Inspection and Enforcement
A. From time to time, DHCS may inspect the facilities, systems, books and records of Business Associate
to monitor compliance with this Agreement and this Addendum. Business Associate shall promptly
remedy any violation of any provision of this Addendum and shall certify the same to the DHCS Privacy
Officer in writing. The fact that DHCS inspects, or fails to inspect, or has the right to inspect, Business
Associate's facilities, systems and procedures does not relieve Business Associate of its responsibility
to comply with this Addendum, nor does DHCS':
1. Failure to detect or
2. Detection, but failure to notify Business Associate or require Business Associate's remediation of
any unsatisfactory practices constitute acceptance of such practice or a waiver of DHCS'
enforcement rights under this Agreement and this Addendum.
B. If Business Associate is the subject of an audit, compliance review, or complaint investigation by the
Secretary or the Office of Civil Rights, U.S. Department of Health and Human Services, that is related
to the performance of its obligations pursuant to this HIPAA Business Associate Addendum, Business
Associate shall notify DHCS and provide DHCS with a copy of any PHI or Pl that Business Associate
provides to the Secretary or the Office of Civil Rights concurrently with providing such PHI or Pl to the
Secretary. Business Associate is responsible for any civil penalties assessed due to an audit or
investigation of Business Associate, in accordance with 42 U.S.C. section 17934(c).
VI. Termination
A. Term. The Term of this Addendum shall commence as of the effective date of this Addendum and
shall extend beyond the termination of the contract and shall terminate when all the PHI provided by
DHCS to Business Associate, or created or received by Business Associate on behalf of DHCS, is
destroyed or returned to DHCS, in accordance with 45 CFR 164.504(e)(2)(ii)(I).
B. Termination for Cause. In accordance with 45 CFR section 164.504(e)(1)(ii), upon DHCS' knowledge
of a material breach or violation of this Addendum by Business Associate, DHCS shall:
1. Provide an opportunity for Business Associate to cure the breach or end the violation and terminate
this Agreement if Business Associate does not cure the breach or end the violation within the time
specified by DHCS; or
2. Immediately terminate this Agreement if Business Associate has breached a material term of this
Addendum and cure is not possible.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 10 of 15
HIPAA Business Associate Addendum
C. Judicial or Administrative Proceedings. Business Associate will notify DHCS if it is named as a
defendant in a criminal proceeding for a violation of HIPAA. DHCS may terminate this Agreement if
Business Associate is found guilty of a criminal violation of HIPAA. DHCS may terminate this
Agreement if a finding or stipulation that the Business Associate has violated any standard or
requirement of HIPAA, or other security or privacy laws is made in any administrative or civil
proceeding in which the Business Associate is a party or has been joined.
D. Effect of Termination. Upon termination or expiration of this Agreement for any reason, Business
Associate shall return or destroy all PHI received from DHCS (or created or received by Business
Associate on behalf of DHCS) that Business Associate still maintains in any form, and shall retain no
copies of such PHI. If return or destruction is not feasible, Business Associate shall notify DHCS of the
conditions that make the return or destruction infeasible, and DHCS and Business Associate shall
determine the terms and conditions under which Business Associate may retain the PHI. Business
Associate shall continue to extend the protections of this Addendum to such PHI, and shall limit further
use of such PHI to those purposes that make the return or destruction of such PHI infeasible. This
provision shall apply to PHI that is in the possession of subcontractors or agents of Business Associate.
VII. Miscellaneous Provisions
A. Disclaimer. DHCS makes no warranty or representation that compliance by Business Associate with
this Addendum, HIPAA or the HIPAA regulations will be adequate or satisfactory for Business
Associate's own purposes or that any information in Business Associate's possession or control, or
transmitted or received by Business Associate, is or will be secure from unauthorized use or disclosure.
Business Associate is solely responsible for all decisions made by Business Associate regarding the
safeguarding of PHI.
B. Amendment. The parties acknowledge that federal and state laws relating to electronic data security
and privacy are rapidly evolving and that amendment of this Addendum may be required to provide for
procedures to ensure compliance with such developments. The parties specifically agree to take such
action as is necessary to implement the standards and requirements of HIPAA, the HITECH Act, the
HIPAA regulations and other applicable laws relating to the security or privacy of PHI. Upon DHCS'
request, Business Associate agrees to promptly enter into negotiations with DHCS concerning an
amendment to this Addendum embodying written assurances consistent with the standards and
requirements of HIPAA, the HITECH Act, the HIPAA regulations or other applicable laws. DHCS may
terminate this Agreement upon thirty (30) days written notice in the event:
1. Business Associate does not promptly enter into negotiations to amend this Addendum when
requested by DHCS pursuant to this Section; or
2. Business Associate does not enter into an amendment providing assurances regarding the
safeguarding of PHI that DHCS in its sole discretion, deems sufficient to satisfy the standards and
requirements of HIPAA and the HIPAA regulations.
C. Assistance in Litigation or Administrative Proceedings. Business Associate shall make itself and
any subcontractors, employees or agents assisting Business Associate in the performance of its
obligations under this Agreement, available to DHCS at no cost to DHCS to testify as witnesses, or
otherwise, in the event of litigation or administrative proceedings being commenced against DHCS, its
directors, officers or employees based upon claimed violation of HIPAA, the HIPAA regulations or other
laws relating to security and privacy, which involves inactions or actions by the Business Associate,
except where Business Associate or its subcontractor, employee or agent is a named adverse party.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 11of15
HIPAA Business Associate Addendum
D. No Third-Party Beneficiaries. Nothing express or implied in the terms and conditions of this
Addendum is intended to confer, nor shall anything herein confer, upon any person other than DHCS or
Business Associate and their respective successors or assignees, any rights, remedies, obligations or
liabilities whatsoever.
E. Interpretation. The terms and conditions in this Addendum shall be interpreted as broadly as
necessary to implement and comply with HIPAA, the HITECH Act, the HIPAA regulations and
applicable state laws. The parties agree that any ambiguity in the terms and conditions of this
Addendum shall be resolved in favor of a meaning that complies and is consistent with HIPAA, the
HITECH Act and the HIPAA regulations.
F. Regulatory References. A reference in the terms and conditions of this Addendum to a section in the
HIPAA regulations means the section as in effect or as amended.
G. Survival. The respective rights and obligations of Business Associate under Section Vl.D of this
Addendum shall survive the termination or expiration of this Agreement.
H. No Waiver of Obligations. No change, waiver or discharge of any liability or obligation hereunder on
any one or more occasions shall be deemed a waiver of performance of any continuing or other
obligation, or shall prohibit enforcement of any obligation, on any other occasion.
DHCS HIPAA BAA 2/15
Attachment A
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 12 of 15
HIPAA Business Associate Addendum
Business Associate Data Security Requirements
I. Personnel Controls
A. Employee Training. All workforce members who assist in the performance of functions or
activities on behalf of DHCS, or access or disclose DHCS PHI or Pl must complete information
privacy and security training, at least annually, at Business Associate's expense. Each workforce
member who receives information privacy and security training must sign a certification, indicating
the member's name and the date on which the training was completed. These certifications must
be retained for a period of six (6) years following contract termination.
B. Employee Discipline. Appropriate sanctions must be applied against workforce members who fail
to comply with privacy policies and procedures or any provisions of these requirements, including
termination of employment where appropriate.
C. Confidentiality Statement. All persons that will be working with DHCS PHI or Pl must sign a
confidentiality statement that includes, at a minimum, General· Use, Security and Privacy
Safeguards, Unacceptable Use, and Enforcement Policies. The statement must be signed by the
workforce member prior to access to DHCS PHI or Pl. The statement must be renewed annually.
The Contractor shall retain each person's written confidentiality statement for DHCS inspection for a
period of six (6) years following contract termination.
D. Background Check. Before a member of the workforce may access DHCS PHI or Pl, a thorough
background check of that worker must be conducted, with evaluation of the results to assure that
there is no indication that the worker may present a risk to the security or integrity of confidential
data or a risk for theft or misuse of confidential data. The Contractor shall retain each workforce
member's background check documentation for a period of three (3) years following contract
termination.
II. Technical Security Controls
A. Workstation/Laptop encryption. All workstations and laptops that process and/or store DHCS
PHI or Pl must be encrypted using a FIPS 140-2 certified algorithm which is 128bit or higher, such
as Advanced Encryption Standard (AES). The encryption solution must be full disk unless
approved by the DHCS Information Security Office.
B. Server Security. Servers containing unencrypted DHCS PHI or Pl must have sufficient
administrative, physical, and technical controls in place to protect that data, based upon a risk
assessment/system security review.
C. Minimum Necessary. Only the minimum necessary amount of DHCS PHI or Pl required to perform
necessary business functions may be copied, downloaded, or exported.
D. Removable media devices. All electronic files that contain DHCS PHI or Pl data must be
encrypted when stored on any removable media or portable device (i.e. USB thumb drives, floppies,
CD/DVD, smartphones, backup tapes etc.). Encryption must be a FIPS 140-2 certified algorithm
which is 128bit or higher, such as AES.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 13of15
HIPAA Business Associate Addendum
E. Antivirus so'ftware. All workstations, laptops and other systems that process and/or store DHCS
PHI or Pl must install and actively use comprehensive anti-virus software solution with automatic
updates scheduled at least daily.
F. Patch Management. All workstations, laptops and other systems that process and/or store DHCS
PHI or Pl must have critical security patches applied, with system reboot if necessary. There must
be a documented patch management process which determines installation timeframe based on
risk assessment and vendor recommendations. At a maximum, all applicable patches must be
installed within 30 days of vendor release.
G. User IDs and Password Controls. All users must be issued a unique user name for accessing
DHCS PHI or Pl. Username must be promptly disabled, deleted, or the password changed upon
the transfer or termination of an employee with knowledge of the password, at maximum within 24
hours. Passwords are not to be shared. Passwords must be at least eight characters and must be
a non-dictionary word. Passwords must not be stored in readable format on the computer.
Passwords must be changed every 90 days, preferably every 60 days. Passwords must be
changed if revealed or compromised. Passwords must be composed of characters from at least
three of the following four groups from the standard keyboard:
• Upper case letters (A-Z)
• Lower case letters (a-z)
• Arabic numerals (0-9)
• Non-alphanumeric characters (punctuation symbols)
H. Data Destruction. When no longer needed, all DHCS PHI or Pl must be cleared, purged, or
destroyed consistent with NIST Special Publication 800-88, Guidelines for Media Sanitization such
that the PHI or Pl cannot be retrieved.
I. System Timeout. The system providing access to DHCS PHI or Pl must provide an automatic
timeout, requiring re-authentication of the user session after no more than 20 minutes of inactivity.
J. Warning Banners. All systems providing access to DHCS PHI or Pl must display a warning
banner stating that data is confidential, systems are logged, and system use is for business
purposes only by authorized users. User must be directed to log off the system if they do not agree
with these requirements.
K. System Logging. The system must maintain an automated audit trail which can identify the user
or system process which initiates a request for DHCS PHI or Pl, or which alters DHCS PHI or Pl.
The audit trail must be date and time stamped, must log both successful and failed accesses, must
be read only, and must be restricted to authorized users. If DHCS PHI or Pl is stored in a
database, database logging functionality must be enabled. Audit trail data must be archived for at
least 3 years after occurrence.
L. Access Controls. The system providing access to DHCS PHI or Pl must use role based access
controls for all user authentications, enforcing the principle of least privilege.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 14of15
HIPAA Business Associate Addendum
M. Transmission encryption. All data transmissions of DHCS PHI or Pl outside the secure internal
network must be encrypted using a FIPS 140-2 certified algorithm which is 128bit or higher, such as
AES. Encryption can be end to end at the network level, or the data files containing PHI can be
encrypted. This requirement pertains to any type of PHI or Pl in motion such as website access, file
transfer, and E-Mail.
N. Intrusion Detection. All systems involved in accessing, holding, transporting, and protecting DHCS
PHI or Pl that are accessible via the Internet must be protected by a comprehensive intrusion
detection and prevention solution.
Ill. Audit Controls
A. System Security Review. All systems processing and/or storing DHCS PHI or Pl must have at
least an annual system risk assessment/security review which provides assurance that
administrative, physical, and technical controls are functioning effectively and providing adequate
levels of protection. Reviews should include vulnerability scanning tools.
B. Log Reviews. All systems processing and/or storing DHCS PHI or Pl must have a routine
procedure in place to review system logs for unauthorized access.
C. Change Control. All systems processing and/or storing DHCS PHI or Pl must have a documented
change control procedure that ensures separation of duties and protects the confidentiality, integrity
and availability of data.
IV. Business Continuity I Disaster Recovery Controls
A. Emergency Mode Operation Plan. Contractor must establish a documented plan to enable
continuation of critical business processes and protection of the security of electronic DHCS PHI or
Pl in the event of an emergency. Emergency means any circumstance or situation that causes
normal computer operations to become unavailable for use in performing the work required under
this Agreement for more than 24 hours.
B. Data Backup Plan. Contractor must have established documented procedures to backup DHCS
PHI to maintain retrievable exact copies of DHCS PHI or Pl. The plan must include a regular
schedule for making backups, storing backups offsite, an inventory of backup media, and an
estimate of the amount of time needed to restore DHCS PHI or Pl should it be lost. At a minimum,
the schedule must be a weekly full backup and monthly offsite storage of DHCS data.
V. Paper Document Controls
A. Supervision of Data. DHCS PHI or Pl in paper form shall not be left unattended at any time,
unless it is locked in a file cabinet, file room, desk or office. Unattended means that information is
not being observed by an employee authorized to access the information. DHCS PHI or Pl in paper
form shall not be left unattended at any time in vehicles or planes and shall not be checked in
baggage on commercial airplanes.
B. Escorting Visitors. Visitors to areas where DHCS PHI or Pl is contained shall be escorted and
DHCS PHI or Pl shall be kept out of sight while visitors are in the area.
DHCS HIPAA BAA 2/15
Exhibit A
COSS MOU Number: 15-MOU-00576
DHCS 14-90495
Page 15 of 15
HIPAA Business Associate Addendum
C. Confidential Destruction. DHCS PHI or Pl must be disposed of through confidential means, such
as cross cut shredding and pulverizing.
D. Removal of Data. DHCS PHI or Pl must not be removed from the premises of the Contractor
except with express written permission of DHCS.
E. Faxing. Faxes containing DHCS PHI or Pl shall not be left unattended and fax machines shall be
in secure areas. Faxes shall contain a confidentiality statement notifying persons receiving faxes in
error to destroy them. Fax numbers shall be verified with the intended recipient before sending the
fax.
F. Mailing. Mailings of DHCS PHI or Pl shall be sealed and secured from damage or inappropriate
viewing of PHI or Pl to the extent possible. Mailings which include 500 or more individually
identifiable records of DHCS PHI or Pl in a single package shall be sent using a tracked mailing
method which includes verification of delivery and receipt, unless the prior written permission of
DHCS to use another method is obtained.
DHCS HIPAA BAA 2/15
Exhibit B-1
Information Exchange Agreement between the Social Security Administration (SSA) and the
California Department of Health Care Services (State Agency). These are sensitive documents
that cannot be posted on public websites.
Exhibit B-2
Certification of Compliance for the Information Exchange Agreement between the Social
Security Administration (SSA) and the California Department of Social Services (State Agency).
These are sensitive documents that cannot be posted on public websites.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
California Department of Social Services (COSS)
Confidentiality and Security Requirements for
CALIFORNIA STATE AGENCIES
lnteragency Agreements/Memoranda of Understanding
I. GENERAL REQUIREMENTS
Exhibit C
Page 1 of 6
A. These requirements provide a framework for maintaining the confidentiality and
security of confidential data the State agency gathers or processes in the course
of carrying out the terms of this agreement with COSS. Definitions of commonly
used terms are provided. For purposes of this agreement only, confidential
and/or personal data are referred to as confidential data.
B. No exceptions from these policies shall be permitted without the explicit, prior,
written approval of authorized COSS staff. All confidentiality and security
requirements, as stated in this agreement, shall be enforced and continue
throughout the term of the agreement. Data protection and security plans may
be required prior to receipt of confidential data.
C. In addition, the State agency will be expected to demonstrate that it has taken
specific steps to ensure the data is kept secure and confidential.
II. PRIVACY, SECURITY, AND CONFIDENTIALITY
A. All confidential data made available in order to carry out this Agreement, will be
protected from unauthorized use and disclosure through the observance of the
same or more effective means as that required by the State Administrative Manual
Sections 5300-5399, Civil Code Section 1798 et seq., Welfare and Institutions
Code Section 10850, and other applicable federal and/or State laws governing
individual privacy rights and data security. Upon request, COSS reserves the right
to review, and then accept security and privacy procedures that are relevant to its
data.
B. The State agency is responsible for the security of the confidential data and
compliance with the terms of this agreement by its employees, contractors, or
sub-contractors.
111. ACCEPTABLE USE AND DISCLOSURE
A. The State agency shall not use or further disclose confidential data other than as
permitted or required by this agreement.
B. The State agency shall refer any persons not included under this agreement with
COSS, to COSS to request access to the confidential data.
C. The State agency agrees that the information obtained will be kept in the strictest
confidence and shall make information available to its own employees only on a
"need to know'' basis. Need to know is based on those authorized employees
who need information to perform their official duties in connection with the uses
of the information authorized by this agreement.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
IV. INFORMATION SECURITY INCIDENTS
Exhibit C
Page 2 of 6
A. Notification: The State agency shall notify the COSS or its designated agent of
any actual or attempted information security incidents, as defined below, within
24 hours of initial detection. Information security incidents shall be reported by
telephone to:
Nola Niegel
Acting Information Security Officer
Information Systems Division
California Department of Social Services
744 P Street, M.S. 9-9-70
Sacramento, CA 95814
(916) 654-0694
B. Cooperation: The State agency shall cooperate in any investigations of
information security incidents.
C. Isolation: The system or device affected by an information security incident, and
containing COSS confidential data, shall be removed from operation immediately
to the extent necessary to prevent further harm or unauthorized disclosures. It
shall remain removed from operation until correction and mitigation measures
have been applied. COSS must be contacted prior to placing the system or
device, containing COSS confidential data, back in operation. The affected
system or device, containing COSS confidential data, shall not be returned to
operation until COSS gives its approval.
V. ENCRYPTION AND TRANSMISSION
A. The State agency shall ensure the confidentiality of COSS data transmission.
B. The State agency shall ensure that all electronic file media used in data
exchanges are either:
1. Transferred by secure file transfer protocol; or
2. Encrypted or protected with equally strong measures if placed on any
personal computer (either desktop or laptop), or on any removable
storage media of any kind, pursuant to Budget Letter 05-32.
C. Transmission of COSS confidential data by fax shall not be used unless no other
method of transmission is feasible and with the following pre-cautions:
1. Faxes containing COSS confidential data shall not be left unattended.
2. Fax machines shall be in secure areas.
3. Faxes shall contain a confidentiality statement notifying persons receiving
faxes in error to destroy them.
4. Fax numbers shall be verified with the intended recipient before sending
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Exhibit C
Page 3 of 6
D. Transfer of COSS confidential data via paper copy shall be mailed using a
secure, bonded mail service, such as Federal Express, Golden State Overnight
or by registered U.S. Mail (i.e., accountable mail using restricted delivery). All
packages must be double packed with a sealed envelope and a sealed outer
envelope or locked box.
VI. NETWORK SECURITY
A. COSS confidential data shall be secured against logical or physical access on
any computing device, on any storage media, or in transit.
B. Maintaining a firewall separating any network attached computing device
containing the data from any network not controlled by the contractor.
C. Using password based authentication and other security safeguards and
precautions to restrict logical and physical access to the data to authorized users
only.
D. Maintaining a log of all accesses to the data.
E. Restricting removal of the data from the work location.
F. Applying all vendor supplied security patches and updates to all computing
devices containing or having access to the data.
G. Configuring all computing devices containing or having access to the data in a
secure manner including:
1. Requiring the authentication or re-authentication after an established
period of inactivity.
2. Not allowing remote access to COSS confidential data or the server that
stores it unless:
a. The remote computer is physically secure and located in manner
to ensure the privacy of the data displayed or stored on it.
b. Communication to the server must be on a physically secured
dedicated line, through a remote control solution using SSL
encryption, or through a strongly encrypted VPN with firewalls that
do not permit split tunneling, not on a public network.
c. The remote computer accessing COSS data must be owned and
controlled by the contractor and must not be configured in a less
secure manner than the contractor's internal computers.
VII. RETURN OR DESTRUCTION OF DATA
A. Return or Destruction: Confidential data used, compiled, processed, stored or
derived by the State agency in the performance of this agreement shall be
destroyed or returned by the agency. All such data shall either be returned to
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Exhibit C
Page 4 of 6
COSS in an agreed-upon format within 30 days of termination of this contract or
be destroyed, unless this agreement expressly authorizes the State agency to
retain specified confidential data after the termination of this agreement. If the
data is returned to COSS, the State agency shall provide COSS with the media
and an inventory of the data and files returned.
B. For purposes of this subsection, "derived" confidential data shall refer to a data
set, containing confidential data, that is derived from another data set by (a)
elimination of fields from the original data set, (b) addition of fields to the original
data set, (c) manipulation of the structure of the original data set or a derivative
data set, or (d) renaming an original data set.
C. Methods of Destruction: The State agency shall destroy all confidential data not
returned when the use authorized ends in accordance with approved methods of
confidential destruction (via shredding, burning, certified or witnessed
destruction, or degaussing of magnetic media). All computer sets containing
individual identifiers shall be destroyed. The agency shall use wipe software on
all the hard drive surfaces of computers used to process or store COSS
confidential data when the computer is withdrawn from use in processing or
storing such data. This includes back-up media. Destruction shall occur before
the effective date of termination of this contract and a letter of confirmation shall
be provided to COSS detailing when, how, and what COSS data was destroyed.
This certification letter is required whether destruction services are contracted or
the agency performs the destruction.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
Exhibit C
Page 5 of 6
VIII. CONFIDENTIALITY AND SECURITY COMPLIANCE STATEMENT
Based on the requirements of the Welfare and Institutions Code Section 10850, Civil
Code Section 1798 et seq., and State Administrative Manual Sections 5300-5399, the
State agency shall provide security sufficient to ensure protection of confidential
information from improper use and disclosures, including sufficient administrative,
physical, and technical safeguards to protect personal information from reasonable
anticipated threats to the security or confidentiality of the information.
NAME OF STATE AGENCY:
*Signature of Authorized State Official
Title: Date:
Phone: E-Mail Address:
Fax:
*Title: Information Security Officer Signature Date:
Phone: E-Mail Address:
Fax:
* Signatures are required by the Information Security Officer and Authorized State Official. This
may include the Agency Chief Information Officer, System Administrator, or other individual
responsible for ensuring compliance with the confidentiality and security requirements.
COSS MOU No. 15-MOU-00576
DHCS 14-90495
IX. DEFINITIONS
Exhibit C
Page 6 of 6
For the purposes of these requirements, the stated terms are defined as noted:
State Agency: For purposes of this agreement, the terms State agency, agency, or
contractor, refers to the California State agency with which COSS enters into this
agreement.
Confidential Data: Information, the disclosure of which is restricted or prohibited by any
provision of law. Some examples of "confidential information" include, but are not limited
to, public social services client information described in California Welfare and
Institutions Code Section 10850 and "personal information" about individuals as defined
in California Civil Code Section 1798.3 of the Information Practices Act (IPA) if the
disclosure of the "personal information" is not otherwise allowed by the IPA. Confidential
data includes personal identifiers. For purposes of this agreement only, confidential
and/or personal data are referred to as confidential data
Confidential Identifiers: Are specific personal identifiers such as name, social security
number, address and date of birth.
De-Identification: Removal of personal identifiers. Examples of personal identifiers
include name, social security numbers, driver's license numbers, and account numbers
with access codes. Personal information does not include publicly available information
that is lawfully made available to the general public. (See definitions for confidential data
and confidential/ personal identifiers.)
Information Assets: Information assets include anything used to process or store
information, including (but not limited to) records, files, networks, and databases;
information technology facilities, equipment (including personal computer systems), and
software (owned or leased).
Information Security Incidents: Information Security incidents include, but are not
limited to, the following; any event (intentional or unintentional) that causes the loss,
damage to, destruction, or unauthorized disclosure of COSS information assets.
Risk: The likelihood or probability that a loss of information assets or breach of security
will occur.
Signature of Authorized State Official: Authorized signature shall be determined by
the state agency. It is recommended that the agency ISO or individual responsible for
oversight of the security requirements in the agreement, review and sign the compliance
statement.
COSS MOU 15-MOU-00576
DHCS 14-90495
EXHIBIT D
Dispute Resolution regarding the
Health Insurance Portability and Accountability Act (HIPAA)
De-identification of Data
45 CFR 164.514(a) and b(1) and b(2)
Page 1 of 1
1. Describe the study or intended use of the data, (authority for data use, purpose,
and subject population described in the data elements) that has been de-
identified pursuant to HIPAA regulations
2. Describe the de-identification method or procedures engaged in to make the
determination the data is properly de-identified
3. Describe the objections to the de-identification method(s) used or an explanation
why there is a reasonable basis to believe that the data can be used to identify
an individual
4. Response that de-identification meets HIPAA requirements and/or there is no
reasonable basis to believe data can be used to identify an individual.
Attach any documents that are relevant to resolving the dispute.
\
Exhibit B.1
CDSS MOU No. 15-MOU-00576
DHCS 14-90495
IEA SSA and DHCS Agreement
,.
'
I
I
Exhibit B.1
INFORMATlON EXCHANGE AGREEMENT
BETWEEN .
THE SOCIAL SECURITY ADMINISTRATION (SSA)
AND
THE CALIFORNIA DEPARTMENT OF HEAL tH CARE SERVICE~ (STATE AGENCY)
A. PURP.QSE: The purpose. of this Information Exohango Agreement (''IBA") is to establish
terms, condition&, and safeguards under which SSA will disclose to tho State Agenoy certain
information, records, or data. (herein "date.") to assist the Stato Agency in adminiatering
certain federally funded state-administered bMefit programs (fnelucling state-funded afate
supplementary paymont programs Wldel'"TitJe XVI of the Social Security Act) identified in
this IBA. By entering into this IBA, the State Agency agrees to comply with: .
• the terms and conttitions set forth in the Computer Matching and Privacy Ptc>teotion Act
Agreement ('1 CMPPA Agreement") attached as Attachment l, governing tlie-State
Agency's uso of the data di11olosed from SSNs Pt!vacy Aot System ofReoor<lll; imd
• all other terms and oonditions sut forth in this IBA
B. PROGRAMS AND D.ATA EXCHANGE 8YSTEMSr (1) The State Agency will uso the
data received or accessed ftom SSA under this IBA fur the purpose of administering tho .
federally funded, state-administored programs identified in Table 1 below. In Table l, tho
State. Agency has identified: (a) each federally funded, state-atlministered program that It
administers; and (b) each SSA data ex.cliange system to which thtJ State Agency needs access
in order to administer the identified program. The list of SSA's data exchange systems is
attached tW Attachment 2:
TABLEl
FEDERALLY FUNP~ BleNEFIT PROGRAMS
Proaram SSA Data EXcha111e System{s)
[XJ Medicaid BENDEXISDXIEVS/SVES/SOLQ/SV£S. l·C1t1zenshlp
/Quarters gf Covsrage/Prfsoner Query
D Temporary Asststance to Needy FamUles
(TANF)
D Supplemental Nutrition Assistance Program
(SNAP· formally Food Stamps-)
D U!"employment Compensation (Federal)
D Unemployment Compensation (State)
CJ Stat& Child Support Asency
U Low·lncome Harne EnertY Assistance
Program (ll·HEAP)
D Workers Compensation
D Vocat1onal Rehabf lltatlon Services
1
I
!
I
,.
""
Exhibit 8.1
O Foster <Are (IV·EJ
O State Health Insurance Prosram (S·CHIP)
D Women, Infants and Chtldren (W.1.C.)
[XJ Medicare Savfnp Programs (MSP) LIS Ftle
[XJ Medicare 1144 (Outreach) Medicare 1144 outreach File
D OtherFed11raUy Funded, State-Administered Program1 (Lfs;t Befow)
Prouram SSA Data. Exehan11e SVstem tn
(2) The State Agency will us; eaoh identified data exchange system on/)! for the purpose of
administering the speoiflc program for which access to the data exohange·system is provided.
SSA data exchange systems are protected by tht.) Privacy Act and federal law prohibits the
use of SSA •s data for any purpose other than the purpose of admin:isterlng the specific
program for whioh such -data is disclosed. In particular, the State Agency will use: (a.) the tax
return data dlso1osed by SSA only to determine individual eligibility for, or the amount of,
assistance under a state plan pursuant to Section 1137 programs and child support
enforoement programs in a.ooordanoe with 26 U.S.C. § 6103{1)(8);'and (b) the cltizenshfp
status data disclosed by SSA under the Children•s Health lnsurenoe Pi:ogram
Reautho!Uation Act of 2009, Pub. L. 111-3, only for the purpose of determining ondtleml.lnt
to Medieaid and CHlP pro~ for new applicants. The State Agency also acknowledges
that SSA's citizenship data may be less than 50 pim:ent oummt. Appli.oents for SSNe report
their citb:enship data at the time they.apply for their SSNs; there is no obligation for en
individual to report to SSA ·a ~hange in ~s or her immigratJon status until he or she flies a
claim for benefits.
C. PROGRAM QUESTIONNAm.E: Prior t~signing this IBA, the State Agenoy will
complete and submit to SSA a program questionnaire for each of the federally funded, state.
administered programs checked :in Table 1 above. SSA will not discloso any data under this
IBA tmtil it has received and approved tlle completed program questionnaire for each of the
programs Identified in Table 1 above.
2
I
I
I
i
' I
I
I
I
I
I
11:
,,
D. TRANSFER OF DATA: SSA will transmit the data to the State Al,ency imder this IBA
using the data tnmmnission method identified in Table 2 below:
TABLE2
TRANSFER.OF DATA
0 Data will be transmitted directly between SSA and the State AgODtJY. ·
Exhibit B.1
[X] Data will be transmitted directly between SSA ·and the California Office ofTeobnology (State
Tra.nsmf.ssion!Iranefor Component (0 STC")) by the Fllo "Transfer Mana.g.erllent System, a secure
mechanism approved by SSA. The STC will serve as tbe oonduit between SSA and the State
Agency pursuant to the State STC Agreement.
0 Data will be transmitted direotly between SSA and tho Intersta.to Conncotlon Ntitwork
("ICONj. ICON is a wide area telecommunications network oonneoting state agencies tbat
administer the state unemployment in1:1U1anoe laws. When rcrceiving data through ICON, the
State Agency will comply with the ''Systems See>urlty Requi:retncnts for SSA Web Access to S$A
Information Through the ICON~" attached as Attachment 3.
E. SECURITY PROCEDURES:: The State Agency will comply with limitations on use,
treatment, and safeguarding of data under the Privacy Act of 1974 (5 U.S.C. 552a), as
a.mended by tbe Computer Matching and Privacy Proteotion Act of 1988t related O.ffioo of
Management and Budget guidelinCSi the Federal Information Security Managoment Aot of
2002 (44 U.S.C. § 3541, et seq.), and related National Institute of Standards and Technology
guidelinos, In addition, the State Agonoy will comply with SSA's ''Information System
Security Guidelines for Federal, State ftlld Local Agencies Reoeiving Bleotronic.Information
from the Social Security Administration." attached as Attachment 4. For any tax return
data, the State Agency will also comply with the "Tu: Information Security Guidelines for
Fedml, State and L<JQal Agencies," Publication 1075, published by the Secretary of b
Treasury and available at the following Internal Revenue Service (IRS) website:
http://www 1irs.goytpub/:irs-:g4flpl075.pdf. This IRS Publication 1075 is inc01p0rated by
rofenm.co into this IBA.
F. c·oNI'RA~TOR/AGENT RESPONSIBILITmS: The Stato Agency wiU restrict acoess to
the da.ta. obtained from SSA to only those authorized State employees, contractors, and·
agents who· nood such data to perform their offiolal duti.os in coMection with purposes-
identified In this IBA. At SSA's roquest, the State Agency will obtain from cmcb of its
contra~tors and agents a current list of the employees of its oolitraotors and agent& who have
aooess to SSA data disclosed under this IBA. Tlm State Agenoy will require its contraotors1
agents1 and all employees of suoh eontraotors or agents with authorized access to the .SSA
data disclosed under this IBA, t!) comply with the temlB and oondith>ns set forth in tbis IBA,
and not to duplioate, disseminate, or d:Jeolose suoh data without obtaining SSN-s prior written
approval. In additioD., the State Agency will oomply with the limitations on use, duplication,
and redisolosure of SSA data set forth in Section IX. of the CMPPA Agreement, espeoially
with respect to its contractors-and agents.
3
!
I
!
l
I
I
J
I
I
l
I
I
!
I
I
I
' l
•.·
. I
' Exhibit 8.1
G. SAFEGUARDING AND REPORTING RESPONSmILITIES FOR PERSONALLY
IDENTIFIABLE INFORMATION ("PII''):
1. Tho State Agency will ensure that its employees, contractors, and agents:
a. prope.t'ly safeguard PII furnished by SSA under this mA from loss, theft or
inadvertent disclosure;
b. understand that they are responsible for safeguarding Utls fnfurmation at all times,
regardless of whether or not the State employoe, contraotor, or agent is at his or her
regular duty station;
c. ensure that laptops and other eleotronlc devicealmedia containing PII are encrypted
and/or password protected;
d. send omails containing PII only if encrypted or if to and from addresses that are
secure; and
e. liinit cliselosure of the information and details relating to a PII loss only to those with
a n;ed to know.
2. If an employee of the State Agency or an employee of the State Agency's· OOJJtractor or
. agent becomes aware. of suspeoted or actual loss of PII, he or she must immediately
contact the State Agency official responsible for Systems Security designated below or
his or her delegate. That State Agency official or delegate must then notify the SSA
Regional Oftioe Contact and the SSA Systems Security Cantaot identified b&low. If, for
any reason, the responsible State Agency official or dolegate is unable to notify the SSA
RogiGnal O:f!ico or the SSA Systetns Security Contact within l hour, tho responsible State
Agency official or delegate must oall SSA'rfNetwork Customer Service Centor
(''NCSC") at 410-965-m? or toll freoat 1-888-772-6661 to report the-actual or
suspected loss. The responsible State Agency oftioial or delegate will use the worksheet,
attached as. Attachmen.t 5, to quiokly gathor and organize information .about the incident
The responsible State Af,eooy oftioial or delegate must provide to SSA timely updates u
any additional information about the loss -o.f Pil becomes availablo,
3. SSA will make the necessary oontaot,within SSA to file a formal 1'0port in accorda.nge
with SSA procedures. SSA will notify the Department of Homeland Security's United
States Computer Bmergonoy Readiness Team if lOss or potential loss of PII related to -a
data exchange \Older this mA ocourt.
4. If the State Agency experiences a loss or breaob of data, it will determine whether or not
to provide notice to individuals whose daia has been lo&t of breached and bear any cost.s
aasociated with the notice or any mitigation, ·
4
j'
·I • ·'
.. ~.
·I
R POINTS OF CONTACT:
FQRSSA
San Franclllco Regional Office:
Ellery Brown
Data Bx.obange Coordinator
Fmik B~l Federal Building
1221 Nevin Avenue
Richtnond CA 94801
Phone: (510) 970-8243
Fax: (510) 970-81-01
Email: Blliizy.Brown@siia..gov
Systwns Issues~
Paroela Riley
Office of Earnings, Enumeration &
Administrative Systems
DIVES/Data Exchange Branch
6401 Sectnity Boul~vard
Baltimore, MD 21235
Phone: (410) 965-7993
Fax: (410) 966-3147
Email: Pamela.Riley@ssa.gov
FQR STATE AGEJ.WX
Agreeme.nt Issues:
Manuet Urbina
Chief, Security Unit
Pol icy Ope1'a.tions Branch
Medi-Cal Eligibility Division
1501 Capitol Avenue, MS 4607
Sacramento, CA 95814
Phone: (916) 650..0160
Email: Manuel.Urbina@dhos.-ca.gov
Exhibit B.1
Data Exchange Issues:
Guy Fortson .
Office of Electronic Information Exchange
GDl 0 Bast High Rise
64{)1 Security Bouli>vard
Baltimore, MD 21235
Phone: (410) 597-1103
Fax: (410) 597-0841
Email: guy.forts~n@ssa.gov
SysteIDB Security Issues:
Michael O. Johnson
Acting Director
Office ofBleotronio ln.farmation Exchange
Office of St.rategio Services
64"01 Set'Ulity Boulevard
Baltimore, MD 21235
Phone~ (410) 965-0266
Fax: (410) 966-0527
Email: Michael.G.Jolmson@asa.gov
TechnJcal Issues:
Fel Co1lier
Chief, Application Support Branch
Information Technology Services·Divtsion
1615 Capitol Ave, MS 6100
Sacramento, CA 95814
Phone: (916) 440-7036
Email: Pei.Collier@dhcs.ca.gov
l. DURATION: The effective date of this IBA is January 1, 2010. This IRA wil1 remain in
effect for as long as: (1) a CMPPA Agreement governing this IBA is in effootbetween SSA
and the State or the State Agency; and (2} the State Agency submits a certification in
accordance with Section J. below at least 30 days before the expiration and renewal of such
CMPP A Agreement.
5
• l
l, r
I
•'
I
t'
Exhibit B.1
J, CERTIFICATION AND PROGRAM CHANGES: At least 3-0 days before tho expiration
and renewal of~e State CMPPA Agreement governing this IBA, the State Agency will
certify in wrlting to SSA that: (l).it is in oomplia.nce with the terms and conditions of this
IBA; (2) the data exchange processea under this IFA have been and will be oonduoted
without change; and (3) it will, upon SSA'.s request, provide audit reports or other document&
that demonstrate review and -oversight ~vities. If there a.re substantive changes iri any of
the progJ:amB or data exchange processes listed in this IBA, the parti()S_ will modify 1he IBA in
accordance with Sectlun K. below and the State ft.¥,enr:y will submlt for SSA's approval new
program questionnaires under Section C. above describing suoh changes prior to using SSA 'B
data to administer suoh new or ·changed program.
IC. MODIFICATION: Modifications to this IBA niust be in writing and agreed to by the
parties.
L. TERMINATION: The parties may terminare this IBA at my time upon mutual written
consent. In addition, either party may unilaterally terminate this IBA upon 90 days adv~oe
written notice to the other party. Such unilateral termination will be effeotive 90 days after
the date of the no.tioe, or at a later-date specified in the notice.
SSA may immediately and unilaterally suspend the data tlow under thls IBA, or terminate
this IBA, if SSA, in its sole discretion, determines that the State Agenoy (including its
employees, oontractors, and agents) has: (1) made an unauthorized use or disclosure of SSA-
suppli-ed data; or (2) violated or fai1ed to follow the tcJrms and conditionB of this IBA or the
CMPPA Agreement.
M. INTEGRATION: This IBA, inoludhlg all attachments, oonstitutes the entire agreement of
the patties with respect to its subjeot matter. There have been 'no representations, warranties,
or promises made outside of this IBA. This IBA shall take preoedence over aay other
document that may be in cQnfliot with it.
AITAcmmNIS
l -C.MPPA Agreoment
. 2.-SSA Data Exchange Systems
3 -Systems Security Requirements for SSA Web Aooess to SSA Information
Through ICON
4 ~ Infomiation System Seourity<Juidelinea for Federal, State and Local Agencies
Receiving Electronic-Information from the Social Secw.ity Administration
S -PII Loss Reporting Worksheet
·' .. '
'i
' I
Exhibit B.1
N. SSA AUTHORIZED SIGN A TURE1 The signatory below warrants and represents. that he
or she has the competent authority on belµUf of SSA to enter into the obligations set forth in
this IBA.
SOCIAL SECURITY ADMINISTRATION
7
O. REGIONAL AND STATE AGENCY SIGNATURES:
SOCIAL SECURITY ADMIN1STRATION
RBOIONIX
ctOrb:Spencer .•
San Francisco Re;:; Commissioner
Jo).J. c,)~1 nat6' '
TIIB CALJFORNIA DBPARTMBNTOF HEALTII CARE SRRV1CBS
Exhibit 8.1
The signatory below warrants and represents that sho has the competent authority
on behalf of the State to ent(}l' into the ons set forth in this IBA.
Da~
8
I
!
I
j l
I I
l
I
!
Exhibit B.1
2012 !EA CElmFICATION OF COMPLIANCl
(IEA-F)
CERTIFICATION OF COMPLIANCE
FOR
THE INFORMATION EXCHANGE AGREEMENT
BETWEEN
TBE SOCIAL SECURITY ADMINISTRATION (SSA)
AND
THE CALIFORNIA DEPARTMENT OF HEALTH CARE SERVtCES (STATE
AGENCY}
(State Agency Levsl)
In accordance with the terms of the Infomiation Exchange. Agreement (lEAIF} between SSA and
the State Agoucy, the State Agency, through its authorized representative, hereby certifies that,
as ofth.e date of this certification:
l. The State Agency is in compliance with the terms and conditions of the IEA/F;
2. The State Agency has conducted the data exchange processes under the IBA/F without
changei except as modified in accordance with the IBNF;
3. The State Agently will continue to conduct the duta exchange processes under the IBAIF
without change, except as may be modified in accordance with the mAJF;
4. Upon SSA's request, the State Agency will provide audit roports or other documents that
demonstrate compliance with the review and oversight activities required under the
IBAIF and tho governing Computer Matching and Privacy Protection Act Agreement;
and
5. In compliance with the requirements of the "Electronic Infonnation Exchange Security
Requirements. Guidelines, and Procedu~ for State and Locru Agencies Exchanging
Electronic Infonuation with the Social Security Administration," A~hment 4 to the
IEAIF, as periodically updated by SSA, the State Agency bas not made any changes in
the following area!; that could potentially affect the security of SSA data:
• General System Security Design and Operating Enviromnent
• System Access Control
• Automated Audit Trail
• Monitoring and Anomaly Detection
• Management Oversight
• Data and Communications Security
The State Agency will submit an updated Security Design Plan at least 30 days prior to
making any changes to the areas listed above.
1
Exhibit 8.1
2012 IEA CERTIFICATION OP COMP~IANCE
[IEA·F}
The signatory below warrants and represents that he or sbe ia a representative of the State
Agency duly authorized to make this oertifloation on behalf of the State Agency.
DEPARTMENT OF HEALm CARE SERVICES OF CALIFORNIA
TobyDou as
Director '//;bl;~
Date
2
,,
ATTACHMENT 1
COMPUTER MATCHING AND PRIVACY
PROTECTION ACT AGREEMENT
Exhibit 8.1
Exhibit 8.1
Model CMPPA Agtec.mont
r COMPUTER MATCHING AND PRIVACY PROTECTION ACT AOREEMBNT
.II
]
j
BETWEEN
TIIE SOCIAL SECURITY ADMINISTRATION
AND
THE HEALTH AND HUMAN SERVICES AGENCY
OF CALIFORNIA
I. Purpote aad Legal Authority
A. Purpose
This Computer Matching Md Privacy Protection Act (CMPPA)Agtecment
between the Socbd Security Administration (SSA) and the California He:altb and
Hwnan Services Agency (State Agencyj, 8eUl forth ibe .terms and coruijtions
goveming disclosures of records, information, or data ( collecti veJy referred to
hurein ••data") made by SSA to the Stats Agency that adminieters federally
funded benefit programs under various provisions of the Social Security Act
(Act). 1:>1.1ch as section 1137 (42 U.S.C. § 1320b-7), including the stmc-funded
state supplementary ~ent programs µnder title XVI of the Act. The terms and
conditlons of this Agreement ensure that SSA makes suclt discio&UreS of data, BJld
the State Age.ncy uses such disclosed data, in aa:ordance with tho req~ts of
the Privacy Act of 1974, as amonded by the Computer Matching 811d Privacy "
Protection Act of 1988 1 S U.S.C. § 552a.
Under section l 137 of the Act, th~ State Agency is required to use an income and
eligibility verification system to adminis~~ specified fedeJ:alJy fund.ed benefit
programs. including the state-funded state supplementary payment programs
under· title XVI of~ Act. To assist the State Agency lo detennitllng ~tlement
to and eligibility fur benefits under those prouramr, as well as oth.et federally
funded benefit progr:uns, SSA discloses certain data about applfcam,, for state
benefits from SSA Privacy Act Systems of Records {SOR)·and verifies the Social ;
Security numbers (SSN) of the applicants.
B. Legal Authority
SSA's authority to disclose data and the State Agency's authority to collect,
maintain,_ and use data protected under SSA SORs for specified purpos~.s is:
• Sect~ons 1137, 453, and 1106(b) of the Act (42 U.S.C. §§ 1320b~7, 653,
and 1306(b)) (income and eligibility verification data);
• 26 U.S.C. § 6103(1)(7) and (8) (tax ret1mHia1a);
• Section 202(x)(3)(B)(iv) of the Act (42 U.S.C. '§ 401(x)(3)(B)(iv))
(prisoner data.)i
• Section 161 t (c)(l)(I)(iii)ofthe Act (42 U.S.C. § 1382(e)(l)(J)(lli) (SSI)i
:·:
Exhibit B.1
• Section 205(r)(3) of tho Act (42 U.S.C. § 40S(r)(3)) and the Intelligence
Reform and Tertorlstn.Prevention Act of2004, Pub. L. los-458.
§ 7213(a)(2) (death data);
o Sections 402, 412, 421, and 435 of Pub. L. 104-193 (8 U.S.C. §§ 1612,
1622, 1631, and 1645) (quarters of coverage dattt);
• Children's Health losurance Program Reauthorization Act of 2009,
Pub. L. I l lw3 (oilizen!hip data); and
• Routine use exception to the Privacy Act, S U.S.C. § 552a(bX3) (data
necessary to administ\tr other programs compatible with SSA programs).
2
This Agreemottt further carries out sention l 106(a} of the Act (42 U.S.C. § 1306),
the regulations promulsated. pursuant to that section (20 C.F .R. Ptll'l 401), the
Prlvaey Act of 1974 (S u.s.c. § 5S2a), as amended by the CMPPA, related Office
of Management-and Budget (OMB) SUldeUnea. the Federal T.nformation Socurity
Management Act of2002 (FISMA) (44 U.S.C. § 3541, et seq.), and related
National Institute of Standards and Technology (NIST) guidelh1es~ which provide
the requirements that the State Agency must follow with regard to use, treatment,
and safeguarding of clata.
n. Scope
A. The State Agency will oomply with the teml8 and conditions of this Agreement
and the Privacy Act. as amenckld by the CMPP A.
B. The State Agency wi11 execute one or more Information Exchange Agreemimts
{IBA) with SSA.. documaiting additional terms and conditions applicable to those
speoific data eKChanges1 lncl\ldfns the particular-benefit programs admJnisiered by
the State A,,teooy, the data elements that will be disclosed, and tho data proteotion
requiremmts impl~ented to assist the State Agency in the admlnist'rad.on of
those. programs. ,~
c. The Stllte·Aaency will use the SSA data governed by this Aireemettt to chrtermine
entitlement and eligl'bility of individuals for on\3. or mor: of the following
programs:
1. Temporary Assistance to Needy Families (TANf} program under Pert A
of title N of th~ Act.
2. Medicaid provided under an approved State plan or an approved w<dver under
title XIX of the Act;
3. State Children's Health Insuronce Program (CHIP) under tltle XXI of the Act,
JS am.ended by the Children's Health Insurance Program Reauthorl7.ation Act
of2009;
4. Supplemental Nutritional Assistance Program (SNAP) under the Food Stamp
Aet of 1977 (7 U.S.C. ~ 2011, et seq.);"
,,
i
I
Exhibit B.1
5, Women, Infants and Children Prograni CwIC) under the Child Nutrition Act
of 1966 (42 U.S.C. § 1771, et seq.);
6. Medicare Savings Programs (MSP) under 42 U.S.C. § 13%a(10)(E);
3
7. Unemployment Compensa1ion programs provided undor a state law descn'bed
in ~on.3304 ofthe Internal Revenue Code of 1954;
8. Low Income Heating and Energy Assistance (LIHEAP' or home energy
grants) program under. 42 U.S.C. § 8621;
9. State-administered supplementary payments e>f the type described in
section l616(a.) of the Act;
I 0. Programs under a plan approved llllder titles [, X, XIV or XVI of the Act;
11. Foster Care and Adoption Assistance under title IV of the A~t;
12. Child Support Enforcement programs under sootion 4S3 <Jf the Act
(42 u.s.c. § 653)j
13. Other applicable federally funded programs administered by the State Ag~ncy
under titles I, IV, X, XIV, XVI, :X'VllI, XIX, XX arid XXI of the Act; and
14. Any other federally funded pro~ administered by tho State Agency that
are compatible with SSN·s prognuna.
D. The Btat.c Agency will ensure that SSA data dlsclo~d for the specific purpose of
administering a pardculat f~erally funded beneflt progtam is used only to
administer tbat program.
III. Justification and Expected Results
A. Justitication
This Agreement atid related data ~xcbanges with the State Agenoy are necessary
for SSA to assist the ·state ~cy in its adminJstration of federally funded benefit
programs by providing the data required to aoe:~tely dcterrniuo entitlt:ment end
uHgibility of individuals for benefits provided under these programs. SSA uses
computer teclmoJogy to transfer ~e data because it is more economical. 1...ffic:ient,
and futer than using manual processes.
B. Expect~d Results
The State Agency will use the data provid«i by SSA to improw Wblic service
and program efficiency and Integrity. The use of SSA data expedites·the
ap.plicatfon.process and ensures that benefits aro awarded only to applicants that
sati:ify the State Agertc)''s program criteria. A cost-benefit analysis for the
exchange made under this Asreement is not required in accordance with the
d<rtermination by tho SSA Data lntegritY Board (DIB) to waive such analy~111,
pursuant to 5 U.S.C. § SS2a(u)(4)(B). ·
IV. R«ord Deseription
A. Systems of Records
SSA SORs used for purposes of the subject data exch~es include:
• 60-QOSS -Master Files of SSN Holders a.rid SSN Applioations
(accessible through EVS. SVES, or Quarters of Coverage
Quety data systems);
Exhibit B.1
• 60-0059 --F.arnings Recording and Self-Employment Income System
(aoocssiblo through BBNDBX, SVBS, or Quarters of Coveraao
Query data systems);
• 60-0090 -Master Beneficiary Record (acQeSSible through BBNDEX or
SVES d"ta systems);
-._ 60-0103-Supplemental Seourltyincome Record (SSR) and Special
V~ Benefrta (SVB) (aCCOGSible throu&;h SDX or SVTIS
data systMls);
• 60-0269 -Prisoner Update Proce!Jsing System (PUPS) (accessible through
SVES or Prisoner Query data systems).
• 60-0321 ·-Medicare Part D 6nd Part D Subsidy File
The State Agency will only use the tax rc:.'tum data contained in SOR 60-0059-
(Barnings Recording and Self-Employment Income System) in accordance with
26 u.s.c .. § 6103.
B. Data Elements
Data elements disclosed in computer ma~hing governed by this Agreement are
Personally Identifiable Information (Pll) from specified SSA SORs, irroluding
names, SSNs, addresses, amounts. and other information related to SSA benefits.
and .earnings infonnatfon. Spectfio listings of data elements are available et:
b1m:Jf\Wfit.S,ii!!!41Q'(/ql&(
C. Number of Records Involved
The numbt:r of records for..ea.ch program covered under thi9 Agreemen1 is eq_ual to
the nwnber of title n, title XVI, or· title XVIII recipienul resident in the State as
reco~ded in. SSA's Annual Statistical ~.ut>Plement fo~ on the lntemet at:
· · bttQ:/fwww.pu.goy41o!!cvl£IQC!/ltiv.~
This number will .fluctuate during tbe term of this AgNement, corresponding to
the number of title lI. title XVI. and titlo XVllI recipients added to. or deleted
·ftom, SSA databases during the tenn of this Agreem~t.
I
I
I
' '
J
' I
i
I
I
! •
V.. Notice and Opportunity to Contest Procedures
A. Notice to Applicants
. Exhibit B.1
s
The State Agency will notiff all indlvidUl),!s who apply fbr &demlly funded,
$tale-administered ·bene:tltCJ under the Act that any data they provide are subject to
verification tbrougll. computer matehing with SSA. The State Agency and SSA
will provide such notice through approprilde language printed on application
forms or separate handout&.
B. Notice to Benefi~rl~pienta/Annultanta . . ·.·.. .
The State Agency will provide notioe to ~ciaries, recipients, and annuitants
under the programs covered by this Agreement infol'IDing them of ongoiftg
computer matching with SSA. SSA will provide sueh notice th.rough p\iblication
in the Fedora! Registor and periodic mailingii to all beneficturies, reclpienta. and
annuitants describing SSA's matching activities.
C. Opportunity to Contest
The ·State Agency will not terminate; suspend. reduce, deny, or take other adverse
actiol'l aaainst an applicant for or reclpient of fedentlly tunded, state-administered
benefits based on data dJsclosed by SSA from its SOR.s until the individual is
notitfad in writing of the potential adverse action and provided an opportwtlty to
contest the planned action. "'Adverso action" meami any aotion that results in a
termination, suspension, reduction, or final denial of eligibility, paymont, or
benidit. Such notices will:
1. Infonn thll individual of the match finding's and the opportunity to <:9ntest
these findings; ·
2. Oive the individual wtil the expiration of any time period established for the
relevant program b'y a statute or resuJation-ior the individual to rospond to
the notice. If no Buch Ci.rm pl:H'iod i.a established by a statute or regulation for
the program, ~-JO-day period wf U be provided. The tiine period begins on
the date on which notice ia mailed or otherwi&e -provided to the individual to
respond; and
3. Clearly t~ that, unless the fu.cl.l.vidual responds to the notice in the required
time perio4, the State Ageney will conclude that the SSA dB.ta are correct and
wUI effectuate the tbrea.tened actl.on or othefW,ise make the necessary
adjustment to the iadMdual's benefit or oJititlement.
Exhibit B.1
VJ, Records Accuracy Assessment and Verltlcatton Procedures
The State Agency may use SSA's beneftt data without independent vmfloatlon.
SSA has Independently assessed the accura~ of its benefits data to bo more than
99 percent. acewaie when th@y arc created.
Prisorun and death ·data. somo of which i& not independently verified by SSA, doea
not have the Bame degree of accuracy u SSA •s benefit data. Therefore, the State
Agency must.iii.dependently verify these data through -ApPlicabl~ State verlflcation
procedures a1Ld the notice and ~ty to contest pi'ocedures specified ln
Section V _of this Agreement before takhti ·any aqverse action against any individual.
6
SSA's citizenship data may be le3s th11n SO percent current. Applicants for SSNs
report their citizenship status at the time they apply for· their SSNs. There is no
obliption for an individual to report tQ SSA a chfinie in his or her in.unigratlon stdl1S
until he or she files a claim for benefits.
VII. Dtspoaition and Records Retontion ofMatehed Items
A. The State Agency will retain all data tecei'ved from SSA to admini.Ster programs
governed by this Agreement only .fot the required processing times for the
applicable federally 'funded benefit programs and will then destroy all such data.
B. The State Agency may rotain SSA data in bardcopy to meet evidentiary
requirements, provided that thoy retire sudl data in e.ccordanoc with applicable
state laws governing the State Ageney•s retention of records.
C. The swe Agency m11y use any accretions, del«i.ons, or cbunges to the SSA data:
govCJmed by th1s Agreement to update their master files of federally funded,
state-administered beoe:fit piogram applicants and NeipientB and retal:D such
mas~r files in accordance with applicable state laws governing the State
Agency's retention of records.
D. The State Agency may n.ot create separate files or records comprised solely of the
data provided by SSA to administer programs govetned by this Agreement.
E. SSA will delete electronic data fnput filos Neoived from the State Agency after lt
processes the applicable match. SSA will retire its data. in accordance with the
Federal Records Retention Schedule (44 U.S.C. § 3303a).
vm. Security Proc:edures-
'rhe State Agency will c~ply with the security end safeguarding requirements of the
Privacy Act, u amended by the CMPPA, related OMB guidellnes, FISMAt related
Exhibit B.1
7
NIST guideline~ and the current revision of IRS Publication 107S, Tax. Information
Security Guttkltnesfor Federal, State and lot::C1l Agencies and Enttltes, available at
.b,ttp:llwww.~. In additfollt the State Agency will have in plll.ce administrative,
technioal, and physical safeguards for the ma1Ched data and results ofBUCh matche.!i.
Additional administrative, technical, and pbyaiCal security requirements go\:eming all
-data SSA provides electronically to tile State.Agert1;y, including s~J.C guidance on
safeguarding and reporting resp0nslbilities for PTI, are set torth in the IEAs.
IX.Records Usage, Duplication, and RedUclosure Restrictions
A. The State Agency will use and~ SSA cbta and the records created usfn& that
data only .for the purpose of verifyina eligibility for the specific federally funded
benefit programs identtfled in tbe lEA
B. The State Agency will comply with the foJJowing llmltatians on use, duplication.
and rediselosure of SSA data:
1. The State Agoncy" will not use or l'Wisclose the data disclosed by SSA £or any
purpose other1han to determine ellgiblllty·.fur, or the ltr.lount of, benefits
un<k=r tho •tate-administe..i--ed incomCJ/heal:th maintenance. programs identified
in this Agrfement.
2. The State Agency will not use the data disclosed by SSA to extract
"intbrmation concerning individuals wbu ·are-neither applicants .IX>r, nor
rccipi'3nte of, benefits under the state-lldmlnlstered Jncomelhe-alth maintel18nce
programs identifled in this Aareement. ·
3. The State Agen.cy will use the Federal ·tax Information (Fl'l) disclosed by
SSA only to determine-individual eligibility for, or the amount of, assistance
under a state plan pursuant to section 1l3 7 programs and child support
enforcement programs in aocordance witl:l 26 U.S.C. § 6103(1)(7) ~d(S).
''i'he State Agency receiving FTI will maintain all rn from IRS in accordance
with 26 U.S.C. §.6103(.i>)(4) and thell~.S Publication 107S. Contraetors and
aaenta acting on behalf of the State Agency wilt only have access to tax return
data where specifically authorized by 2{) U.S.C. § 6103 and the m.s
Publication 1075.
4. The State Agency will use the citizenship statu& data disclosed by SSA
under the Children's Health Insurance Program Reauthorization Act of 2009,
Pub. L. ·t t 1-3., only for the purposo of determining 011titlement to Medicaid ·
and CHIP programs for new applicant:.!.
S. The State Agency will restrict access· to the~ disclosed by SSA to only
those authorized State employees, contractors, and agents who need such data
Exhibit 8.1
to perform their official duties in connection with the purposes identifi.W in
this Aijl'Cement.
.g
6. The State Agency will enter into a. written agreement with each of its
contractors and agents who need SSA data to perfonn their official duties
whereby ·such contractor or agent agrees to abide by all relevant Fodera! laws 1
restrictions on access, use, and di&closure, and security requirements· in thi$
Agreement. The State Agency wnt provide lts comractors and agents with
copi~ of tbia Agreement, related IBAs, and ~J related Gttaohmenta before
inhial disclo&ure of SSA data lo such contractors and agenb. Prior t.o Blgl'ling
this Agreement,. and ·thercaflet at SSA •s request, the State Agency will obtain
:from.·its contractors and agents a current list of the employees of S\Jch
contractors and agenta with access to SSA data and provide such lists to SSA.
7. Tho State Agency's employoes, contraCtors-, and agents who access, usa, er
disclose SSA data in ·a manner or purpose not authorized by this Agreement
may be subj~ to civil and criminal sanctions pursuant to applicable Federal
statutes.
C. The Stat\' Ag~ncy will not duplicate in a separate file or dissem.inatl>, without prior
written penniS11ion from SSA1 the data governed by this Agreement fur any
purpose other than to determino entitlem~t to, or ellsibtlity for, federally funded
btnefit.s. The State Agency proposin¥ the redisclosme must specify in writing to
SSA what data are being disclosed, to whom, and the reasons that justify the
redisclosure. SSA will not give permission for such rediscloaure unless the
r~iscl~crure-ls required by 1aw or essential to the conduct of the matching
program an.d authorl1.ed under a routine use.
X. Comptroller General A«ess
The Comptroller General (the Oovemmont Accountability Office) may have acccas to
all records of the State Agency that the Comptroller Oaoeral deems necessary to
monitor and: verify compliance with this Agreement in accordance with
S U.S.C. § S52a(o)(l){K)~
XI.Duration, Modlfieation, and Termination of the Agreement
A. Duration
1. This Agreement is effective from July l, 2012 (Effective Date) through
December 31, 2013 (Expil'lltlon Date).
2. In ~cordance with the CMPPA, SSA will: (a) pbblish a Computer
Ma~bing Notice in the Federal Register at leaot 30 days prior to tbe
! i
I
I • I
I
I
i
Exhibit B.1
9
Eftective Date; (b) send required notices to the Congressional committees of
jurisdiction under S U.S.C. § SS2a(o)(2)(A)(t) at_ least 40 dl\ys prior to the
Effective Date; and (c) send the requited report to the OMB at least 40 days
prior to the Bffective Dme.
3. Within 3 months prior the Exp.lration Date, the SSA DIB may, without
additional review, renew this Ajreem..mt for .a perlo4 not to exceed
12 months, pursuant to 5 U.S.C. § 552a(o)(2)(D), if:
• the applicable data exchange will continue wi1bout any change; and
• SSA and the State Apru:y certify to the DIB in writing that the
applicable data exchange has boon conducted iQ compliance with this
Agreement.
4. ff either SSA or the. State Agency does not wish to renew this Agreement, it
must notify the other party of its intent not to ren~w at least 3 months prior
to the Expiration Date.
B. Modification
Ally modification to this Agreement must be in writing, signed by both parties,
and approved b~ the SSA nm.
C. Temtlnation
Tha parties may tttrminate this Agreem~ a.t any time upon mutual written
consent of both parties. Either party may unilaterally term1nate this Agreement
upon 90 days advance written notice to th~ other party; such unilateral termination
will be effective 90 days after the date of 1ho notice, or at a later date specified in
the .notice.
S·SA may immediately and unilaterally suspeJtd the data flow or terminate this
Agreement if SSA determines, fn its sole ~scretion, that the State Agency has
violated or failed to comply with this Agreement.
XII. Reimbursement
In accordilnce wJth seetion 1106(b) of the Act, th~ Co~eioner of SSA has
determined not to oharge the State Agency .tho costs of furnishing the electronic data
from the SSA SORs under this Agreement.
Exhibit 8.1
10
xm. Diselalmer
SSA is not liable for any damages or loss resulting from enors in the data provided
to tho State Agency und&r any lBAs governed by this Agreement. Furthermore, SSA
is not liablt fur any damages or loss resulting ftom the destruction of any materials
or data provided by the State Agency.
XIV. Points of Contact
A. SSA Pohrt of Contact
Regional Offke
Martin White,. Director
San Francisco Regional Office, Center far Programs Support
1221 Nevin A"le
Ri(:bmond CA 94801
Phone: (510) 970-8243/Fax: (510)-970-8101
Martin. White@ssa.gov
B. State Agency Potat of Contact
Sonia Herrera
Health and Human Services Agency
1600 Ninth Street, Room 460
Sacramento, CA 95814
Phone: (916) 654-3459/Fax.: (916) 44-SOOl
sheaera@2..hb,.ca.gov
.•
Exhibit 8.1
XV. SSA and Data Integrity Board Approval of Model CMPPA Agreement
The signatories below warrant e.od represent that they have the competent authority
on behalf ofSSA to approve the model of this CMPPA Agreement
SOCIAL SSCURITY ADMINISTRATION
~ l . ·-~~ Deputy Executive Dlreotot
Oftlce of Privacy and Disclosure
OtBce of the Ooneral Counsel
l certify that the SSA Data Integrity Board approved the mod~I of this CMPPA
Agreement. .
Date
XVI. Authorized Signatures
The signatori~ below warrant and represent that they have the competent authority
on behalf of their respective agencies to enter into tho obligations set forth in this
Agreement..
11
SOCIAL SECURITY ADMINISTRATION
HEALTH AND BUMAN SERVICES AGENCY
~).~
Diana S. Dooley ~
Sooretary
~ .:1 '7, &p I l.
Date I
Exhibit B.1
12
I
I
j
Exhibit B.1
ATTACHMENT 2
AUTHORIZED DATA EXCHANGE SYSTEM-(S)
Exhibit B.1
Attachment 2
Authorized Data Exchange System(s)
BEER (Beneficiary Earnings Exchange· Record): Employer data for the last calendar year.
BENDEX (Beneficiary and Earnings Data Exchange): Primary source for Title II eligibility,
benefit and demographic data.
LIS (Low-Income Subsidy): Data from the Low-Income Subsidy Application for Medicare Part
D beneficiaries --used for Medicare Savings Programs (MSP).
Medicare 1144 (Outreach): Lists of individuals on SSA roles, who may be eligible for medical
8S5istanoe for: payment of the cost of Medicare cost--aharing under the Medicaid prograni
pursuant to Sections 1902(a)(l O)(E) and 1933 of the Act; transitional usistanoe under Section
18600-31 (f) of the Act; or premiums and cost-sharing subsidies for low-income individuals
under Section 18600-14 of the Act.
PUPS (Prisoner Update Processing System): Confinement data received from over 2000 state
and local institutions (such as jails, prisons, or other penal institutions or ooITectional facilities)--
PUPS matches tho received data with the MBR and SSR benefit data and generates alerts for
review/action.
QUARTERS OF COVERAGE (QC): Quarters of Coverage data as assigned and described
under Title II of the Act --The term "quarters of cqverage" is also referred to 8!I "credits" or
"Social Seeurity credits" in various SSA public infonnation documents, as well as to refer to
"qualifying quarters" to determine entitlement to receive Food Stamps.
SDX (SSI State Data Exchange): Primary source ofTitle XVI eligibility, benefit and
domographic data. as wull as data for Title. VIII Special Veterans Benefits (SVB).
SOLQ/SOLQ-1 (State On~llne Query/State On·Une Query-Internet): A real-time online
system that provides SSN verification and MBR and SSR benefit data similar to data provided
through SVBS.
Exhibit B.1
Attachment l
SVES (State Verification and Exchange System): A batch system that provides.SSN
verification. MBR benefit information,. and SSR information through a uniform. data
·response based on authorized user~initiated queries. The SVES types are divided into
five different responses as follows:
SVESI:
SVES I/Citizenship*
SVES.11:
SVESID:
SVESIV:
This batch provides strictly SSN verification.
This batch provides strietly SSN verification and
citizenship data.
This bateh provides strictly SSN verification and
MBR benefit information
This batch provides strictly SSN verification and
SSR/SVB.
This batch provides SSN verification, MBR benefit
information, and SSR/SVB information. which
represents all available SVES data.
* Ciiizenshlp status data disclosed by SSA under the Children's Health Insurance
Program Reauthorization Act-of 2009, Pub. L. 111-3 ls only for the purpose of
determining ent/tlement to Medicaid and CHIP program for new applicants.
2
Exhibit B.1
ATTACHMENT 3 OMITIED
...
ATTACHMENT 4
ELECTRONIC INFORMATION EXCHANGE SECURITY
REQUIREMENTS AND PROCEDURES
Exhibit B.1
I
ELECTRONIC INFORMATION-EXCHANGE
,SECU.RITY REQUIREMENTS AND' PRO.CEDURES
FOR·
STATE AND LOCAL AGENCIES EXCHANGING
ELECTRONIC INFORMATION WITH THE_ SOCIAL
SECURITY ADMINISTRATIQ~
SENSITIVE-DOC,UMENT
VERSION' 6.0~2 1'P.rn · 2014
1
Exhibit B.1
Table-of c_ont~nts:
1. JntmduCtlon
2. .Electrpok IofQnoaUgn Ex;;bange Pefinijjon
· 3~ ·soles and Respon5ib!Uties
4;, General Svstems s,cur_ilv ~tandii;1Cds
s~ 5y$tgm:; Sec:u[ibi Regulrement5 .
s·.1 Overview
5.2 General System Secudh( Design and Operalinq-Epyimnment
5.3 · System Acces5:Contnal
5;4 Autgmated ·Audjt Trail _
5.5 per59nallv-IdentJtliJble IDformatiqp
5~6 Mgnitofipg apd ·Anomaly Dgtftrtipn
_5.7 MaDiqelnent Oyftn;iight apd.Oyiility MSuranc@
S.8 Dita and Cqmmuniciitipns.Sgcyritv.
5.9 IDcident Repprtjnq
5, 19 $ecurjtv. Awar@ne:;s ;jfr1d Emplgvee sarictlgn·:;
5.11 t=Antric;tars gt Elq:ctrnnic lptgrmaUOn EXcbapqe partners
6. Gengralg~Securjtv Certlfiqtjgn-and Compliance Beylew pn:jpnims
6. t Jbe Secucley c:ertmcatlon prggram. · · · · · · ·
6.2 Dpc;uoientiDg sm=udht COntrOIS jn the Secur'lty Design Piao
~.2·.1 When the SQP ind Risk Assessment ate Required
6.3· The Certificatign proC;e$$
6.4 fbe Cpmpliancc Reylew Ptaatam and proces5
6._5.1 EIEp tompliance B@yit!W Participation
6_ • .5.2 VerlijQitioo pf Audjt Samples
6.6. Scheduling tbe-Qnsjtg Rgvjew
7. Addjtjpnal Definitions
s. s_equtatorv aeteritrmce&
9. .FregMerittv Asked Quedjgn:i
10. Diagraims
Flgw Chart of the OJS·Certificatign procas
flgw Chart gfttie OIS Cgmpllane1reeview ·prgGl)ss
<;omgliance R@yjew pgeislo·n Mat[;x· · · ·-
2
Exhibit B.1
RECEIVING ELECTRONIC INFORMAnON FROM THE
SOCIAL $ECURITY '~DMINI!.'TRA'riON .
1. Introduction 4'l
Exhibit B.1
The law requires the Social Security Administration (SSA) to maintain oversight and assure the
protection of Information It provides to Its Electronic Information Exchange Partners {EIEP). EIEPs
are entitles that have information exchange agreements with SSA.
The overall aim of this document is twofold. First, to ensure that SSA can properly certify EIEPs as
compliant by the SSA security requirements, standards, and procedures expressed in this document
before we grant access to SSA Information In a production environment. Second, to ensure that
EIEPs continue to adequately safeguard electronic information provided to them by SSA.
This document (which SSA considers SENSIT1VE 1 and should only be shared with those who need it
to ensure SSA-provided information Is safeguarded), describes the security requirements, standards,
and procedures EIEPs must meet and Implement to obtain information from SSA electronically. This
document helps EIEPs understand criteria that SSA uses when evaluatlng and certifying the system
design and security features used for electronic access to SSA-provided Information.
The addition, elimination, and modification of security control factors determine which level of
security and due diligence SSA requires for the EIEP to mitigate risks. The emergence of new
threats, attack methods, and the availability of new technology warrants frequent reviews and
revisions to our System Security Requirements (SSR). Consequently, EIEPs should expect SSA's
System Security Requirements to evolve in concert with the industry.
EIEPs must comply with SSA's most current SSRs to gain access to SSA-provided data. SSA wlll
work with its partners to resolve deficiencies that occur subsequent to, and after, approval for access
if updates to our security requirements cause an agency to be uncompllant. EIEPs may proactlvely
ensure their ongoing compliance with the SSRs by periodically requesting the most current SSR
package from their SSA contact. Making periodic adjustments Is often necessary.
2. Efot,tronic'lrircmnatirm E>ech·ange Qefinitian 0
For discussion purposes herein, Electronic Information Exchange (EIE) Is any electronic process In
which SSA discloses information under Its control to any third party for any purpose, without the
specific consent of the subject individual or agent acting on his or her behalf. EIE involves
individual data transactions and data flies processed within the systems of parties to electronic
information sharing agreements with SSA. These processes Include direct terminal access or OTA
to SSA systems, batch processing, and variations thereof (e.g., onllne query) regardless of the
systematic method used to accompllsh the activity or to Interconnect SSA with the EIEP.
1 Sensitive data -"any Information, the loss, misuse, or unauthorized access to or modification of which could adversely affect the
national Interest or the conduct of Federal programs, or the privacy to which Individuals are entftled under 5 u.s.c. Section 552a
(The Privacy Act), but that has not been speclflcally authorized under criteria established by an Executive Order or an Act of
Congress to be kept classfflecl In the Interest of national defense or foreign policy but Is to be protected In accordance with the
\.equlrements of the Computer Security Act of 1987 (P.L.100-235)."
3
Exhibit 8.1
3;, .Rol~s and Responslbillties
The SSA Office of Information Security (OIS} has agency-wide responsibility for Interpreting,
developing, and implementing security pollcy; providing security and integrity review
requirements for all major SSA systems; managing SSA's fraud monitoring and reporting
activities; developing and disseminating security training and awareness materials; and
providing consultation and support for a variety of agency Initiatives. SSA's security reviews
ensure that external systems receiving information from SSA are secure and operate in a
manner consistent with SSA's Information Technology (IT) security policies and In compliance
with the terms of electronic Information sharing agreements executed by SSA with outside
entities. Within the context of SSA's security policies and the terms of electronic Information
sharing agreements with SSA's EIEPs, OIS exclusively conducts and brings to closure lnltlal
security certifications and periodic security compliance reviews of EIEPs that process, maintain,
transmit, or store SSA-provided Information In accordance with pertinent Federal requirements
which Include the following (see also Begulagecy,J.leferencet):
a. The Federal Information security Management Act (FISMA) requires the protection of
"Federal Information In contractor systems, Including those systems operated by state and
local governments." ·
b. The Social Security Administration requires EIEPs to adhere to the policies, standards,
procedures, and directives published in this Systems Security Requirements (SSR)
document.
Personally Identifiable Information (PII), covered under several Federal laws and statutes, Is
Information about an Individual including, but not limited to, personal Identifying information
Including the Social Security Number (SSN).
The data (last 4 digits of the SSN) that SSA provides to its EIEPs for purposes of the Help
America Vote Act (HAVA) does not identify a specific.individual; therefore, Is not "PII" as
defined by the Act.
However, SSA Is diligent In discharging l_ts responslbllity for establishing aPJJrapriate
administrative, technical, and physical safeguards to ensure the security, confidentiality, and
availability of Its records and to protect against any anticipated threats or hazards to their
security or integrity.
NOTE: Disclosure of Federal Tax Information (FTI} Is limited to certain Federal
agencies and state programs supported by federal statutes under Sections 1137,
453, and 1106 of the Social Security Act. For Information regarding safeguards for
protecting FTI, consult IRS Publication 1075, Tax Information Security Guldellnes
for Federal, State, and Local Agencies.
The SSA Regional Data Exchange Coordinators (DECs) serve as a bridge between SSA and
state EIEPs. In the security arena, DECs assist OIS in coordinating data exchange security
review activities with state and local EIEPs; e.g., they provide points of contact with state
agencies, assist In setting up security reviews, etc. DECs are also the first points of contact
for states if an employee of a state agency or an employee of a state agency's contractor or
4
Exhibit B.1
agent becomes aware of a suspected or actual loss of SSA-provided Personally Identifiable
Information (PII).
4. Gene_ral ~yste1ns S.ec·urity:·$~andar~s 0.
EIEPs that request and receive Information electronlcally from SSA must comply with the
following general systems security standards concerning access to and control of SSA-
provided Information.
NOTE: EZEPs may not create separate files or records comprised solely of the
Information provided by SSA.
a. EIEPs must ensure that means, methods, and technology used to process, maintain,
transmit, or store SSA-provided information neither prevents nor impedes the EIEP's
ability to
• safeguard the Information in conformance with SSA requirements,
• efficiently investigate fraud, data breaches, or security events that Involve
SSA-provided information, or
• detect instances of misuse or abuse of SSA-provided Information
For example, utilization of cloud computing may have the potential to
jeopardize an EIEP's compllance with the terms of their agreement or SSA's
associated system security requirements and procedures.
b. EIEPs must use the electronic connection established between the EIEP and SSA
only In support of the current agreement(s) between the EIEP and SSA.
c. EIEPs must use the software and/or devices provided to the EIEP only in support of
the current agreement(s) between the EIEP and SSA.
d. SSA prohibits modifying any software or devices provided to the EIEPs by SSA.
e. EIEPs must ensure that SSA-provided Information Is not processed, maintained,
transmitted, or stored in or by means of data communications channels, electronic
devices, computers, or computer networks located In geographic or virtual areas not
subject to U.S. law.
f. EIEPs must restrict access to the information to authorized users who need it to
perform their official duties.
NOTE: Contractors and agents (hereafter referred to as contractors) of the
EIEP who process, maintain, transmit, or store SSA-provided Information are
held to the same security requirements as employees of the EZEP. Refer to the
section t;qptmao;,. of Elmfoat,; lplqtmattqn EXcb@ntji: eartn·ers/n the $V:it@Dzs
Securif¥ s;eautrements for additional Information.
g. EIEPs must store information received from SSA In a manner that, at all times, is
physically and electronically secure from access by unauthorized persons.
S·
Exhibit 8.1
h. The EIEP must process SSA-provided Information under the Immediate supervision
and control of authorized personnel.
I. EIEPs must employ both physical and technological safeguards to prevent
unauthorized retrieval of SSA-provided information via computer, remote terminal,
or other means.
j. EIEPs must have formal PII incident response procedures. When faced with a
security incident caused by malware, unauthorized access, software Issues, or acts
of nature, the EIEP must be able to respond in a manner that protects SSA-provided
information affected by the incident.
k. EIEPs must have an active and robust employee security awareness program, which
is mandatory for all employees who access SSA-provided information.
I. EIEPs must advise employees with access to SSA-provided information of the
confldentlal nature of the information, the safeguards required to protect the
information, and the civil and criminal sanctions for non-compliance contained in
the applicable Federal and state laws.
m. At Its discretion, SSA or its designee must have the option to conduct onslte
security reviews or make other provisions to ensure that EIEPs maintain adequate
security controls to safeguard the information we provide.
S. Syst!;?m_s Secu.rit)' Reqoirements 0
S~ 1 Overview 0
SSA must certify that the EIEP has implemented controls that meet the requirements and
work as Intended, before we will authorize Initiating transactions to and from SSA
through batch data exchange processes or online processes such as State Online Query
(SOLQ) or Internet SOLQ (SOLQ-I).
The Technical Systems Security Requirements (TSSRs) address management,
operatlonal, and technical aspects of security safeguards to ensure only the authorized
disclosure and use of SSA-provided Information by SSA's EIEPs.
SSA recommends that the EIEP develop and publish a comprehensive Systems Security
Policy document that specifically addresses:
• the classification of information processed and stored within the network,
• administrative controls to protect the Information stored and processed within the
network,
• access to the various systems and subsystems within the network,
• Security Awareness Training,
• Employee Sanctions Policy,
6
Exhibit B.1
• Incident Response Polley, and
• the disposal of protected information and sensitive documents derived from the
system or subsystems on the network.
SSA's systems security requirements represent the current state-of-the-practice security
controls, safeguards, and countermeasures required for Federal information systems by
Federal regulations, statutes, standards, and guidelines. Addltlonally, SSA's systems
security requirements also Include organizationally defined Interpretations, policies, and.
procedures mandated by the authority of the Commissioner of Social Security In areas
when or where other cited authorities may be silent or non-specific.
S.2 Ge"neral System Security Design and ·opcratfng Environment 0
EIEPs must provide descriptions and explanations of their overall system design,
configuration, security features, and operational environment and Include explanations of
how they conform to SSA's requirements. Explanations must include the following:
o Descriptions of the operating envlronment{s) In which the EIEP will utilize, maintain,
and transmit SSA-provided Information
o Descriptions of the business process( es) In which the EIEP will use SSA-provided
information
o Descriptions of the physical safeguards employed to ensure that unauthorized
personnel cannot access SSA-provided Information and details of how the EIEP keeps
audit information pertaining to the use and access to S,SA-provlded information and
associated applications readily available
o Descriptions of electronic safeguards, methods, and procedures for protecting the
EIEP's network Infrastructure and for protecting SSA-provided Information while in
transit, in use within a process or application, and at rest (stored or not In use)
o Descriptions of how the EIEP prevents unauthorized retrieval of SSA-provided
information by computer, remote terminal, or other means, including descriptions of
security software other than access control software (e.g., security patch and anti-
malware software Installation and maintenance, etc.)
o Descriptions of how the configurations of devices {e.g., servers, workstations, and
portable devices) Involving SSA-provided information comply with recognized Industry
standards and SSA's system security requirements
o Description of how the EIEP implements adequate security controls (e.g., passwords
enforcing sufficient construction strength to defeat or minimize risk-based Identified
vulnerabilltles)
7
Exhibit B.1
5.3 svstem· Acce~s control
EIEPs must utilize and maintain technological (logical) access controls that limit access to
SSA-provided information and associated transactions and functions to only those users,
processes acting on behalf of authorized users, or devices (Including other Information
systems) authorized for such access based on their official duties or purpose(s). EIEPs
must employ a recognized user access security software package (e.g. RAC-F, ACF-2,
TOP SECRET) or a security software design which Is equivalent to such products. The
access control software must utlllze personal Identification numbers (PIN) and passwords
or Biometric Identifiers in combination with the user's system identification code (userID).
The access control software must employ and enforce (1) PIN/password, and/or (2)
PIN/biometric identifier, and/or (3) SmartCard/blometric identifier, etc., for
authenticating users).
Depending on the computing platform (e.g., client/server (PC), mainframe) and the
access software implementation, the terms "PIN" and "user system Identification code
(userID)" may be, for practical purposes, synonymous. For example, the PIN/password
combination may be required for access to an individual's PC after which, the
. userlD/password combination may be required for access to a mainframe application. A
biometric identifier may supplant one element In the pair of those combinations. SSA
strongly recommends Two-Factor Authentication.
The EIEP's implementation of the control software must comply with recognized industry
standards. Password policies should enforce sufficient construction strength (length and
complexity) to defeat or minimize risk-based identified vulnerabilities and ensure .
!Imitations for password repetition. Technical controls should enforce periodic password
changes based on a risk-based standard (e.g., maximum password age of 90 days,
minimum password age of 3 - 7 days) and enforce automatic disabling of user accounts
that have been inactive for a specified period of time (e.g., 90 days).
The EIEP's password pollcles must also require more stringent password construction
(e.g., passwords greater than eight characters In length requiring upper and lower case
letters, numbers, and special characters; password phrases) for the user accounts of
persons, processes, or devices whose functions require access privileges in excess of
those of ordinary users.
EIEPs must have management control and oversight of the function of authorizing
individual user access to SSA-provided Information and to oversee the process of Issuing
and managing access control PINs, passwords, biometric Identifiers, etc. for access to the
EIEP's system.
The EIEP's systems access rules must cover least privilege and individual accountability.
The EIEP's rules should Include procedures for access to sensitive Information and
transactions and functions related to It. Procedures should Include control of transactions
by permissions module, the assignment and limitation of system privileges, disabling
accounts of separated employees (e.g., within 24 hours), indlvldual accountability, work
at home, dlal-up access, and connecting to the Internet.
8
Exhibit B.1
5,4 Automated Audit T(ail
SSA requires EIEPs to implement and maintain a fully automated audit trail system
(ATS). The system must be capable of creating, storing, protecting, and efficiently
retrieving and collecting records identifying the individual user who Initiates a request for
information from SSA or accesses SSA-provided information. At a minimum, Individual
audit trail records must contain the data needed (Including date and time stamps) to
associate each query transaction or access to SSA-provided Information with its initiator,
their action, if any, and the relevant business purpose/process (e.g., SSN verification for
Medicaid). Each entry In the audit file must be stored as a separate record, not overlaid
by subsequent records. The Audit Trail System must create transaction flies to capture
all input from interactive internet applications which access or query SSA-provided
Information.
If a State Transmission Component (STC) handles and audits the EIEP's transactions with
SSA, the EIEP Is responsible for ensuring that the STC's audit capabilities meet SSA's
requirements for an automated audit trail system. The EIEP must also establish a process
to obtain specific audit information from the STC regarding the EIEP's SSA transactions.
Access to the audit file must be restricted to authorized users with a "need to know."
Audit file data must be unalterable (read-only) and maintained for a minimum of three
(preferably seven) years. Information In the audit flle must be retrievable by an
automated method. EIEPs must have the capability to make audit flle Information
available to SSA upon request. EIEPs must back-up audit trail records on a regular basis
to ensure their avallabllity. EIEPs must apply the same level of protection to backup
audit files that apply to the origlnal files.
If the EIEP retains SSA-provided Information in a database (e.g., Access database,
SharePolnt, etc.), or if certain data elements within the EIEP's system Indicate to users
that SSA verified the information, the EIEP's system must also capture an audit trail
record of users who viewed SSA-provided information stored within the EIEP's system.
The retrieval requirements for SSA-provided information at rest and the retrieval
requirements for regular transactions are Identical.
s.s Personally IdentinC1ble l_~rorm-ation (PII.)
P:l:I is any Information about an Individual maintained by an agency, including (1)
any information that can be used to distinguish or trace an lndlvidual's identity,
such as name, social security number, date and place of birth, mother's maiden
name, or biometric records; and (2) any other information that Is linked or linkable
to an individual, such as medical, educational, financial, and employment
information. An item such as date and place of birth, mother's maiden name, or
father's surname Is PII, regardless of whether combined with other data.
SSA defines a Pll loss as a circumstance when SSA has reason to believe that
Information on hard copy or In electronic format, which contains PII provided by SSA,
left the EIEP's custody or the EIEP disclosed it to an unauthorized Individual or entity.
PII loss Is a reportable incident (refer to laddenr Bepqrtlnq).
9
Exhibit 8.1
If a PII loss involving SSA-provided information occurs or Is suspected, the EIEP
must be able to quantify the extent of the loss and compile a complete llst of the
Individuals potentlally affected by the Incident (refer to lricident Beaadina).
5.6 Monitoring_ and Anomaly Detectior:t 0
SSA recommends that EIEPs use an Intrusion Protection System (JPS) or an
Intrusion Detection System (IDS). The EIEP must establish and/or maintain
continuous monitoring of Its network infrastructure and assets to ensure the following:
o The EIEP's security controls continue to be effective over time
o Only authorized lndlvlduals, devices, and processes have access to SSA-
provided information
o The EIEP detects efforts by external and Internal entities, devices, or processes to
perform unauthorized actions (i.e., data breaches, malicious attacks, access to
network assets, software/hardware Installations, etc.) as soon as they occur
a The necessary parties are Immediately alerted to unauthorized actions
performed by external and Internal entities, devices, or processes
o Upon detection of unauthorized actions, measures are immediately Initiated to
prevent or mitigate associated risk
a In the event of a data breach or security incident, the EIEP can efficiently determine
and Initiate necessary remedial actions
o The trends, patterns, or anomalous occurrences and behavior In user or network
activity that may be Indicative of potential security Issues are readily discernible
The EIEP's system must Include the capablllty to prevent employees from unauthorized
browsing of SSA records. SSA strongly recommends the use of a transaction-driven
permission module design, whereby employees are unable to Initiate transactions not
associated with the normal business process. If the EIEP uses such a design, they then
need anomaly detection to detect and monitor employee's unauthorized attempts to gain
access to SSA-provided lnformiiJtion and attempts to obtain Information from SSA for
clients not In the EIEP's client system. The EIEP should employ measures to ensure the
permission module's integrity. Users should not be able to create a bogus case and
subsequently delete it in such a way that It goes undetected.
If the EIEP's design does not currently use a permission module and is not transaction-
driven, until at least one of these security features exists, the EIEP must develop and
implement compensating security controls to deter employees from browsing SSA
records. These controls must Include monitoring and anomaly detection features, either
systematic, manual, or a combination thereof. Such features must include the
capablllty to detect anomalies in the volume and/or type of transactions or queries
requested or initiated by Individuals and include systematic or manual procedures for
verifying that requests and queries of SSA-provided information comply with valld
official business purposes. The system must also produce reports that allow
management and/or supervisors to monitor user activity, such as the following:
10
Exhibit B.1
• u~er 10 Exc::eption Rer)ortS:
This type of report captures Information about users who enter Incorrect user IDs
when attempting to gain access to the system or to the transaction that Initiates
requests for information from SSA, including failed attempts to enter a password.
• In_quiry,Match Exception Reports;
This type of report captures information about users who may be Initiating
transactions for SSNs that have no client case association within the EIEP's system
(the EIEP's management should review 100 percent of these cases).
o System t=rror Exception Reports:
This type of report captures information about users who may not understand
or may be violating proper procedures for access to SSA-provided Information.
• • Inqui,.Y Activ.ity·Statistical Reports:
This type of report captures information about transaction usage patterns
among authorized users and Is a tool which enables the EIEP's management to
monitor typical usage patterns In contrast to extraordinary usage patterns.
The EIEP must have a process for distributing these monitoring and exception reports to
appropriate local managers/supervisors or to local security officers. The process must
ensure that only those whose responsibilities Include monitoring anomalous activity of
·users, to include those who have exceptional system rights and privileges, use the
reports.
5~7 Management Oversight and Quality 'As.s,ura_n~e 0
The EIEP must establish and/or maintain ongoing management oversight and quality
assurance capabilities to ensure that only authorized employees have access to SSA-
provided information. They must ensure ongoing compliance with the terms of the EIEP's
electronic information sharing agreement with SSA and the SSRs established for access to
SSA-provided Information. The entity responsible for management oversight must consist
of one or more of the EIEP's management officials whose job functions include
responsibility to ensure that the J;:IEP only grants access to the appropriate employees and
position types which require SSA-provided Information to do their jobs.
The EIEP must ensure that employees granted access to SSA-provided information
receive adequate training on the sensitivity of the Information, associated safeguards,
operating procedures, and the penalties for misuse.
SSA recommends that EIEPs establish the following job functions and require that
employees tasked with these job functions do not also share the same job functions as
personnel who request or use information from SSA.
• Perform periodic self-reviews to monitor the. EIEP's ongoing usage of SSA-
provided Information.
• Perform random sampling of work activity that involves SSA-provided
information to determine If the access and usage comply with SSA's
requirements.
11
2
Exhibit B.1
5.8 ·oata an.d Coi:nmunications Security __fl_
EIEPs must encrypt PII and SSA-provided information when transmitting across dedicated
communications circuits between its systems, Intrastate communications between its local
office locations, and on the EIEP's mobile computers, devices and removable media. The
EIEP's encryption methods should align with the Standards established by the National
Institute of Standards and Technology (NIST). SSA recommends the Advanced
Encryption Standard (AES) or triple DES (Data Encryption Standard 3), If AES Is
unavailable, encryption method for securing SSA-provided Information during transport.
Flies encrypted for external users (when using tools such as Microsoft WORD
encryption,) require a key length of nine characters. We also recommend that the key
(also referred to as a password) contain both special characters and a number. SSA
requires that the EIEP deliver the key so that the key does not accompany the media.
The EIEP must secure the key when not In use or unattended.
SSA discourages the use of the public Internet for transmission of SSA-provided
information. If however, the EIEP uses the public Internet or other electronic
communications, such as emails and faxes to transmit SSA-provided Information, they
must use a secure encryption protocol such as Secure Socket Layer (SSL) or Transport
Layer Security (TLS). SSA also recommends 256-bit encryption protocols or more
secure methods such as Virtual Private Network technology. The EIEP should only send
data to a secure address or device to which the EIEP can control and llmlt access to only
specifically authorized Individuals and/or processes. SSA recommends that EIEPs
use Media Access Control (MAC) Filtering and Firewalls to protect access points
from unauthorized devices attempting to connect to the network.
EIEPs should not retain SSA-provided Information any longer than business
purpose(s) dictate. The Information Exchange Agreement with SSA stipulates a time
for data retention. The EIEP should delete, purge, destroy, or return SSA-provided
information when the business purpose for retention no longer exists.
The EIEP may not save or create separate files comprised solely of Information provided
by SSA. The EIEP may apply specific SSA-provided information to the EIEP's matched
record from a preexisting data source. Federal law prohibits duplication and redlsclosure
of SSA-provided Information without written approval. The prohibition applies to both
Internal and external sources who do not have a "need-to-know2 ." SSA recommends
that EIEPs use either Trusted Platform Module (TPM) or Hardware Security
Module (HSM) technology solutlons to encrypt data at rest on hard drives and
other data storage media.
EIEPs must prevent unauthorized disclosure of SSA-provided Information after they
complete processing and after the EIEP no longer requires the information. The EIEP's
operational processes must ensure that no residual SSA-provided information remains on
the hard drives of user's workstations after the user exits the applicatlon(s) that use
SSA-provided Information. If the EIEP must send a computer, hard drive, or other
computing or storage device offsite for repair, the EIEP must have a non-disclosure
clause in their contract with the vendor. If the EIEP used the item In connection with a
business process that Involved SSA-provided Information and the vendor will retrieve or
may view SSA-provided Information during servicing, SSA reserves the right to inspect
Need-to-know -access to the lnfonnatlon must be necessary for the conduct of one's official duties.
12
Exhibit B.1
the EIEP's vendor contract. The EIEP must remove SSA-provided information from
electronic devices before sending it to an external vendor for service. SSA expects the
EIEP to render It unrecoverable or destroy the electronic device if they do not need to
recover the data. The same applies to excessed, donated, or sold equipment placed into
the custody of another organization.
To sanitize media, the EIEP should use one of the following methods:
• Overwriting
Overwrite utilities can only be used on working devices. Overwriting Is appropriate only for
devices designed for multiple reads and writes. The EIEP should overwrite disk drives,
magnetic tapes, floppy disks, USB flash drives, and other rewrlteable media. The overwrite
utlllty must completely overwrite the media. SSA recommends the use of qurglag media
sanitization to make the data Irretrievable and to protect data against laboratory attacks or
forensics. Please refer to DeUaltfqnsfor more Information regarding Media
SanitjzpUqa). Reformatting the media does not overwrite the data. . . .
• Degaussing
Degaussing Is a sanitization method for magnetic media (e.g., disk drives, tapes,
floppies, etc.). Degaussing Is not effective for purging non-magnetic media (e.g.,
optical discs). Degaussing requires a certified tool designed for particular types of
media. Certification of the tool is required to ensure that the magnetic flux applied to
the media Is strong enough to render the Information irretrievable. The degaussing
process must render data on the media irretrievable by a laboratory attack or
laboratory forensic procedures (refer to.Deffaltiims for more information regarding
Medfa:Saat«zaUoa). · · · · · · · ·
• Physical destruction
Physical destruction is the method when degaussing or over-writing cannot be
accomplished (for example, CDs, floppies, DVDs, damaged tapes, hard drives,
damaged USB flash drives, etc.). Examples of physical destruction Include shredding,
pulverizing, and burning.
State agencies may retain SSA-provided Information in harclcopy only if required to
fulfill evldentlary requirements, provided the agencies retire such data In accordance
with applicable state laws governing retention of records. The EIEP must control print
media containing SSA-provided information to restrict its access to authorized
employees who need such access to perform their official duties. EIEPs must destroy
print media containing SSA-provided Information In a secure manner when It Is no longer
required for business purposes. The EIEP should destroy paper documents that contain
SSA-provided information by burning, pulping, shredding, macerating, or other similar
means that ensure the information is unrecoverable.
NOTE: Hand tearing or lining through documents to obscure Information
does not meet SSA's requirements for appropriate destruction of PII.
The EIEP must employ measures to ensure that communications and data furnished to
SSA contain no viruses or other malware.
$pe~/al No,ti~: If SSA-provided Information will be stored In a commercial
13
Exhibit 8.1
cloud, please provide the name and address of the cloud provider. Also,
please describe the security features contractually required of the cloud
provider to protect SSA-provided Information •
. .
5,9: Inci.d~nt Reporting 0
SSA requires EIEPs to develop and implement pollcles and procedures to respond to
data breaches or PII loses. You must explain how your pollcles and procedures
conform to SSA's requirements. The procedures must Include the following
Information: ·
If the EIEP experiences or suspects a breach or loss of PII or a security incident,
whictl indudes SSA-provided information, they must notify the State offldal
responsible for Systems Security designated In the agreement. That State offidal or
delegate must then notify the SSA Regional Office Contact and the SSA Systems
Security Contact Identified in the agreement. If, for any reason, the responsible State
offidal or delegate is unable to notify the SSA Regional Office or the SSA Systems
Security Contact within one hour, the responsible State Agency official or delegate
must report the Incident by contacting SSA~ National Network Service Center
(NNSC) toll free at 877-697-4889 (select nsecurity and PII Reportingnfrom the
options list). The EIEP wlll provide updates as they become available to the SSA
contact, as appropriate. Refer to the worksheet provided in the agreement to
facilitate gathering and organizing Information about an inddent.
The EIEP must agree to absorb all costs associated with notification and remedial actions
connected to security breaches, if SSA determines that the risk presented by the
breach or security Incident requires the notification of the subject individuals. SSA
recommends that EIEPs serlously consider establlshlng Incident response
teams ta address PII breaches •
. 5.10 Security ~w&neness and Employee San.ctions 0 ---
The EIEP must designate a department or party to take the responsibility to provide
ongoing security awareness training for employees who access SSA-provided
information. Training must include:
o The sensitivity of SSA-provided information and address the Privacy Act and other
Federal and state laws governing Its use and misuse
o Rules of behavior concerning use and security in systems processing SSA-provided
i nformatlon
o Restrictions on viewing and/or copying SSA-provided information
o The employee's responslblllty for proper use and protection of SSA-provided
Information including Its proper disposal
o Security incident reporting procedures
o Basic understanding of procedures to protect the network from malware attacks
14
Exhibit 8.1
o Spoofing, Phishing, and Pharmlng scam prevention
o The possible sanctions and penalties for misuse of SSA-provided Information
SSA requires the EIEP to provide security awareness training to all employees and
contractors who access SSA-provided Information. The training should be annual,
mandatory, and certified by the personnel who receive the training. SSA also requires
the EIEP to certify that each employee or contractor who views SSA-provided data also
certify that they understand the potential criminal and administrative sanctions or
penalties for unlawful disclosure.
S.11·contractors of Electroni.c Inforniati~n ~xch.ange· Part~e.rs: 0 ---
As previously stated In The Cj@necal Sy#l:m$ $W;utltjr st;;jadirdi, contractors of the
EIEP must adhere to the same security requirements as employees of the EIEP. The
EIEP Is responsible for the oversight of Its contractors and the contractor's compliance
with the security requirements. The EIEP will enter Into a written agreement with each
of its contractors and agents who need SSA data to perform their official duties,
whereby such contractors or agents agree to abide by all relevant Federal laws,
restrictions on access, use, disclosure, and the security requirements In this
Agreement.
The EIEP's employees, contractors, and agents who access, use, or disclose
SSA data In a manner or purpose not authorized by this Agreement may be subject to
both clvll and criminal sanctions pursuant to applicable Federal statutes. The EIEP wlll
provide Its contractors and agents with copies of this Agreement, related
IEAs, and all related attachments before Initial disclosure of SSA data to such
contractors and agents. Prior to signing this Agreement, and thereafter at SSA's
request, the EIEP wlll obtain from Its contractors and agents a current list of
the employees of such contractors and agents with access to SSA data and provide
such lists to SSA.
The EIEP must be able to provide proof of the contractual agreement If the contractor
processes, handles, or transmits Information provided to the EIEP by SSA or has
authority to perform on the EIEP's behalf, the EIEP should clearly state the specific roles
and functions of the contractor. The EIEP will provide SSA written certification that the
contractor Is meeting the terms of the agreement, including SSA security requirements.
The certification wlll be subject to our final approval before rediscloslng our information.
The EIEP must also require that contractors who will process, handle, or transmit
information provided to the EIEP by SSA sign an agreement with the EIEP that obligates
the contractor to follow the terms of the EIEP's data exchange agreement with SSA. The
EIEP or the contractor must provide a copy of the data exchange agreement to each of
the contractor's employees before disclosing data and make certain that the contractor's
employees receive the same security awareness training as the EIEP's employees. The
EIEP should maintain awareness-training records for the contractor's employees and
require the same annual certification procedures.
The EIEP wlll be required to conduct the review of contractors and is responsible
for ensuring compliance of Its contractors with security and privacy requirements and
I imitations. As such, the EIEP will subject the contractor to ongoing security compliance
15
Exhibit B.1
reviews that must meet SSA standards. The EIEP will conduct compliance
reviews at least triennially commencing no later than three (3) years after the approved
initial security certification to SSA; and must provide SSA with written documentation of
recurring compliance reviews, with the contractor, subject to our approval.
If the EIEP's contractor will be Involved with the processing, handling, or transmission
of information provided to the EIEP by SSA offslte from the EIEP, the EIEP must have
the contractual option to perform onsite reviews of that offsite faclllty to ensure that the
following meet SSA's requirements:
a safeguards for sensitive information
o computer system safeguards
a security controls and measures to prevent, detect, and resolve unauthorized
access to, use of, and redlsclosure of SSA-provided information
o continuous monitoring of the EIEP contractors' network Infrastructures and assets
6. General -se~_urlty certification ~~no Compli.an_c¢ Re\fiew ~rograms 0
SSA's security certification and compliance review programs are distinct processes. The
certification program is a one-time process when an EIEP initially requests electronic access to
SSA-provided Information. The certification process entails two rigorous stages Intended to
ensure that technical, management, and operational security measures work as designed. SSA
must ensure that the EIEPs fully conform to SSA's security requirements and satisfy both
stages of the certification process before SSA will permit online access to its data in a
production environment.
The compliance review program, however, ensures that the suite of security measures
implemented by an EIEP to safeguard SSA-provided Information remains In full compliance with
SSA's security standards and requirements. The compliance review program applies to both
online and batch access to SSA-provided Information. Under the compliance review program,
EIEPs are subject to ongoing and periodic security reviews by SSA.
6.1 The Security CertiflcatiO:n Pro~gr<uh __ Q_
The security certification process applies to EIEPs that seek online electronic access to SSA
Information and consists of two general phases:
• Phase One: The Security Design Plan (SDP) phase Is a formal written plan authored
by the EIEP to comprehensively document its technical and non-technlcal security
controls to safeguard SSA-provided Information (refer to aae;umeaUnD-SetUrl&:y
c 0 ntmls tnthe:~•<'"itY Qa(M Piao).+ · · ·
NOTE: SSA. may have' fega~y EIE_P_s (~IEPs n_ot certifie·ci: under the current.
p~~S5) V{hO hav~ r.·otp_l".f!pal"ed an· SOP; OIS~:Strongly recarnmend!iLthat
these E_IEes_p·repar'e an:SDJ>,
The ElEP~s preparation and-maintenance of a current SOP wlll aid them in
determining po.~ential complionc_e i,sSues .prior to revie'Ws; ~s_urhlg
continued compliance with SSA's. secur:ity requl~:mentS, and p·r~yiding for . 16 . -
Exhibit B.1
monn~fficie.nt security revi.ews.
• Phase 2: The SSA Onsite Certification phase is a formal onslte review conducted by
SSA to examine the full suite of technical and non-technical security controls
Implemented by the EIEP to safeguard data obtained from SSA electronlcally (refer to
'Tbe Certjficatjqn pmqss;).
6.2 Documenting Security Controls ir, the-Security Design Plan .CSDP) 0
~.;2~1 When the sop and .Risk Assessm.ent-are Required 0 -------
EIEPs must submit an SOP and a security risk assessment (RA) for evaluation when one or
more of the following circumstances apply. The RA must be In electronic format. It must
Include discussion of the measures planned or Implemented to mitigate risks identified by
the RA and (as applicable) risks associated with the circumstances below:
• to obtain approval for requested access to SSA-provided information for an inltlal
agreement
• to obtain approval to reestablish previously terminated access to SSA-provided data
• to obtain approval to implement a new operating or serurlty platform that will involve
SSA-provided Information
o to obtain approval for significant changes to the EIEP's organizational structure,
technical processes, operational environment, data recovery capabllltles, or security
Implementations planned or made since approval of their most recent SOP or of their
most recent successfully completed security review
• to confirm compliance when one or more security breaches or incidents involving
SSA-provided Information occurred since approval of the EIEP's most recent SOP
or of their most recent successfully completed security review
• to document descriptions and explanations of measures Implemented as the result
of a data breach or security incident
• to document descriptions and explanations of measures Implemented to resolve
non-compliancy issue(s)
• to obtain a new approval after SSA revoked approval of the most recent SOP
SSA may require a new SOP if changes ocrurred (other than those llsted above) that
may affect the terms of the EIEP's Information sharing agreement with SSA.
SSA will not approve the SDP or allow the Initiation of transactions and/or access
to SSA-provided Information before the ElEP compiles with the SSRs.
An SDP must satisfactorily document the EIEP's compliance with all of SSA's SSRs in order to
provide the minimum level of security acceptable to SSA for its EIEP's access to SSA-provided
Information.
EIEP's must correct deficiencies identified through the evaluation of the SOP and submit a
revised SOP that Incorporates descriptions and explanations of the measures Implemented to
17
Exhibit B.1
eliminate the deficiencies. SSA cannot grant access to SSA-provided information untll the EIEP
corrects the deficiencies, documents the SOP, and SSA approves the revisions. The EIEP wlll
communicate the implementation of corrective actions to SSA on a regular basis. SSA wlll
wlthhold final approval untll the EIEP can rectify all deficiencies.
SSA may revoke the approval of the EIEP's SOP and its access to SSA-provided Information if we
learn the EIEP is non-compliant with one or more SSRs. The EIEP must submit a revised SOP,
which Incorporates descriptions and explanations of the measures the EIEP wlll Implement to
resolve the non-compliance lssue(s). The EIEP must communicate the progress of corrective
actlon(s) to SSA on a regular basis. SSA will consider the EIEP in non-compliant status until
resolution of the issue(s), the EIEP's SOP documents the corrections, and we approve the SOP.
If, within a reasonable time as determined by SSA, the EIEP Is unable to rectify a deficiency
determined by SSA to present a substantial risk to SSA-provided information or to SSA, SSA will
wlthhold approval of the SOP and discontinue the flow of SSA-provided information.
NOTE: EtEPs that function on•y. as an STC, transferring SSA~provided informatio.n
to other.. EIEPs· must, per the· terms of. their agreements with SSA; a~here tenSSA's
s_ystem.Securlty Requirements·{sSR) and.exercise thelr:responslbitit:ies regarding
prot~~lt;ln of.5$A~~r,ovi_"e~ infQrmatJ.on. -· · · · ·. ·-· · · · · -· ·
6_.3 The Certifi~ati~n Process 0
Once the EIEP has successfully satisfied Phase 1, SSA will conduct an onsite certification
review. The objective of the onslte review is to ensure the EIEP's non-technical and
technical controls safeguard SSA-provided information from misuse and improper disclosure
and that those safeguards function and work as intended.
At Its.discretion, SSA may request that the EIEP participate In an onslte review and
compliance certification of their security Infrastructure.
The onsite review may address any or all of SSA's security requirements arid Include, when
appropriate:
• a demonstration of the EIEP's implementation of each requirement
• random sampling of audit records and transactions submitted to SSA
• a wallcthrough of the ElEP's data center to observe and document physical security
safeguards
• a demonstration of the EIEP's Implementation of electron le exchange of data with SSA
• discussions with managers/supervisors
• examiflation of management control procedures and reports (e.g., anomaly detection
reports, etc.)
• demonstration of technical tools pertaining to user access control and If appropriate,
browsing prevention, specifically:
o If the design Is based on a permission module or slmllar design, or it Is transaction
driven, the EIEP wlll demonstrate how the system triggers requests for information
from SSA.
18
Exhibit 8.1
o If the design is based on a permission module, the EIEP will demonstrate how the
process for requests for SSA-provided Information prevent SSNs not present In the
EIEP's system from sending requests to SSA. We will attempt to obtain Information
from SSA using at least one, randomly created, fict_itious number not known to the
EIEPs system.
During a certification or compliance review, SSA or a certifier acting on Its behalf, may
request a demonstration of the EIEP's audit trail system (ATS) and its record retrieval
capability. The certifier may request a demonstration of the ATS' capability to track the
activity of employees who have the potential to access SSA-provided Information within the
EIEP's system. The certifier may request more Information from those EIEPs who· use an
STC to handle and audit transactions. We wlll conduct a demonstration to see how .the EIEP
obtains audit Information from the STC regarding the EIEP's SSA transactions.
If an STC handles and audits an EIEP's transactions, SSA requires the EIEP to demonstrate
both their own In-house audit capabilities and the process used to obtain audit information
from the STC.
If the EIEP employs a contractor who processes, handles, or transmits the EIEP's SSA-
provided Information offsite, SSA, at its discretion, may include the contractor's facility in
the onslte certification review. The inspection may occur with or without a representative
of the EIEP.
Upon successful completion of the onsite certification exercise, SSA will authorize
electronic access to production data by the EIEP. SSA wlll provide written notification of
its certification to the EIEP and all appropriate Internal SSA components.
The following is a high-level flow chart of the OIS Certification Process: fl
Kickoff Meeting
to dlsaiss certification process with
EIEP
Evaluate SDP for appraval
Certify the !IEP
19
Exhibit B.1
6.s The Comptian·~e Re:vle\_Y Prog:r~m :and Process 0
Similar to the certification process, the compliance review program entails a rigorous
process intended to ensure that EIEPs who receive electronic Information from SSA are In full
compliance with the Agency's security requirements and standards. As a practice, SSA
attempts to conduct compliance reviews following a two to five year periodic review
schedule. However, as circumstances warrant, a review may take place at any time. Three
prominent examples that would trigger an ad hoc review are:
• a significant change In the outside EIEP's computing platform
• a violation of any of SSA's systems security requirements
• an unauthorized disclosure of SSA Information by the EIEP
The following Is a high-level flow chart of the OIS Compliance Review Process: 0
Detennine method of review
------~-•t_he_r_ba_ck_g_ro_u_n_d_in_f_o .... ~ ... ~-• .... tl_on ___ _J
Set review.date
Manttar flndln~s
SSA may conduct onslte compliance reviews and include both the EIEP's main facility and a field
office.
SSA may, also at Its discretion, request that the EIEP participate in an onslte compliance
review of their security Infrastructure to conflrrri the implementation of SSA's security
requirements.
20
Exhibit B.1
The onslte review may address any or all of SSA's security requirements and include, where
appropriate:
• a demonstration of the EIEP's implementation of each requirement
• random sampllng of audit records and transactions submitted to SSA
• a walkthrough of the EIEP's data center to observe and document physlcal security
safeguards
• a demonstration of the EIEP's implementation of onllne exchange of data with SSA
• discussions with managers/supervisors
• examination of management control procedures and reports (e.g. anomaly detection
reports, etc.)
o demonstration of technical tools pertaining to user access control and, If appropriate,
browsing prevention:
o If the design uses a permission module or similar design, or Is transaction driven, the
EIEP will demonstrate how the system triggers requests for information from SSA.
o If the design uses a permission module, the EIEP will demonstrate the process used to
request SSA-provided Information and prevent the EIEP's system from processing SSNs
not present In the EIEP's system. We can accomplish this by attempting to obtain
Information from SSA using at least one, randomly created, fictitious number not known
to the EIEP's system.
SSA may, at its discretion, perform an onslte or remote review for reasons including, but
not limited to the followlng:
•. the EIEP has experienced a security breach or Incident Involving SSA-provided Information
•1 the EIEP has unresolved non-compliancy issue(s)
o to review an offslte contractor's facility that processes SSA-provided Information
• the EIEP Is a legacy organization that has not yet been through SSAs security certification
and compliance review programs
• the EIEP requested that SSA perform an N & V (Independent Verification and Valldatlon
review)
During the compliance review, SSA, or a certifier acting on its behalf, may request a
demonstration of the system's audit trail and retrieval capability. The certifier may request a
demonstration of the system's capablllty for tracking the activity of employees who view SSA-
provided Information within the EIEP's system. The certifier may request EIEPs that have STCs
that handle and audit transactions with SSA to demonstrate the process used to obtain audit
information from the STC.
If an STC handles and audits the EIEP's transactions with SSA, we may require the EIEP to
demonstrate both their in-house audit capabilities and the processes used to obtain audit
information from the STC regarding the EIEP's transactions with SSA.
21
Exhibit 8.1
If the EIEP employs a contractor who wlll process, handle, or transmit the BEP's SSA-provided
information offsite, SSA, at its discretion, may Include in the onsite compliance review an onslte
inspection of the contractors facility. The inspection may occur with or without a representative
of the EIEP. The format of the review in routine circumstances (i.e., the compliance review Is
not being conducted to address a special circumstance, such as a dlsclosure vlolatlon) will
generally consist of reviewing and updating the EIEP's compliance with the systems security
requirements described above in this document. At the conclusion of the review, SSA will Issue
a formal report to appropriate EIEP personnel. The Final Report wlll address findings and
recommendations from SSA's compliance review, which includes a plan for monitoring each Issue
untll closure.
NOTE: SSA handles documentation provided for compliance reviews as sensitive
Information. The Information Is only accessible to authorized Individuals who have a
need for the Information as It relates to the EZEP's compliance with Its electronic
Information sharing agreement with SSA and the associated system security
requirements and procedures. SSA will not retain the EZEP's documentation any longer
than required. SSA wlll delete, purge, or destroy the documentation when the
retention requirement expires.
The followlng is a high-level example of the analysis that aids SSA in making a preliminary
determination as to which review format is appropriate. We may also use additional factors to
determine vvhether SSA will perform an onsite or remote compliance review.
• High/Medium Risk Criteria
a undocumented closing of prior review findlng(s)
a implementation of technlcal/operatlonal controls that affect security of SSA-provided
information (e.g. implementation of new data access method)
a PII breach
• Low Risk Criteria
o no prior review findlng(s) or prior flndlng(s) documented as closed
o no Implementation of technlcal/operatlonal controls that Impact security of SSA-provided
information (e.g. lmplementatlon of new data access method)
o no PII breach
6.!5. l· El e·P Compliance .Rev,if!w F!art.lclpation 0
SSA may request to meet with the following persons during the compliance review:
• a sample of managers and/or supervisors responsible for enforcing and monitoring
ongoing compliance to security requirements and procedures to assess their level of
training to monitor their employee's use of SSA-provided Information, and for
reviewing reports and taking necessary action
o the individuals responsible for performing security awareness and employee sanction
functions to learn how you fulfill this requirement
• a sample of the EIEP's employees to assess their level of training and
understanding of the requirements and potential sanctions applicable to the use
and misuse of SSA-provided Information
22
Exhibit B.1
• the individual(s) responslble for management oversight and quality assurance
functions to confirm how your agency accomplishes this requirement
• additional Individuals as deemed appropriate by SSA
6.5~2 Verification of Audit S.amples· 0
Prior to or during the compliance review, SSA wlll present to the EIEP a sampling
of transactions previously submitted to SSA for verification. SSA requires the
EIEP to verify whether each transaction was, per the terms of their agreement
with SSA, legitimately submitted by a user authorized to do so.
SSA requires the EIEP to provide a written attestation of the transaction review
results. The document must provide:
• confirmation that each sample transaction located In the EIEP's audit file
submitted by its employee(s) was for legltlmate and authorized business
purposes
• an explanation for each sample transaction located In the BEP's audit file(s)
determined to have been unauthorized
• an explanation for each sample transaction not found in the EIEP's ATS
When SSA provides the sample transactions to the EIEP, detailed instructions wlll be
Included. Only an official responsible for the EIEP Is to provide the attestation.
6;6 Scheduling the.Ons.lt~ R~vlew 0
SSA will not schedule the onsite review until we approve the EIEP's SOP. SSA will send
approval notification via email. There Is no prescribed period for arranging the subsequent
onsite review (certification review for an EIEP requesting initial access to SSA-provided
Information for an Initial agreement or compliance review for other EIEPs). Unless there
are compelling circumstances precluding it, the onslte review will follow as soon as
reasonably possible.
However, the scheduling of the onslte review may depend on additional factors lndudlng:
• the reason for submission of a plan
• the severity of security Issues, if any
• circumstances of the previous review, if any
• SSA workload considerations
Although the scheduling of the review is contingent upon approval of the SOP, SSA may
perform an onslte review prior to approval if we determine that it is necessary to
complete our evaluation of a plan.
23
Exhibit B.1
('l'HIS PAGE HAS;B£EN LEFT BLANK INTENTIONALLY)
24
Exhibit B.1
1. Addition·a1 Defini_tiorfs O
Sack Button:
Refers to a button on a web browser's toolbar, the backspace button on a
computer keyboard, a programmed keyboard button or mouse button, etc.,
that returns a user to a previously visited web page or applicatlon screen.
Breach::
Refers to actual loss, loss of control, compromise, unauthorized disclosure,
unauthorized acquisition, unauthorized access, or any similar term referring to
situations where unauthorized persons have access or potential access to PII or
Covered Information, whether physical, electronic, or in spoken word or
recording.
Browsing:
Requests for or queries of SSA-provided information for purposes not related to
the performance of official job duties.
Choke Point: . .
The firewall between a local network and the Internet Is a choke point In
network security, because any attacker would have to come through that
channel, which is typlcally protected and monitored.
Cloud Computing:
The term refers to Internet-based computing derived from the cloud
drawing representing the Internet in computer network diagrams. Cloud
computing providers dellver on-line and on-demand Internet services.
Cloud Services normally use a browser or Web Server to deliver and store
Information.
, Cloud Computing (NIST SP 800-145' Excerpt):
, Cloud ~mputing:is a model for enabling ubiquitous, convenient, on-demand' network at:cess 1~4.1 a
: sharE:d pocii of configutilble computing l'l!Sllur.:es (~.g., networt~. sE:rvers, st'1rage. applications,
; and serifices) that .:an be rapid IV provtSlaned and released with mlilimal management effort or
~ servlee proV'ider lnteracti'bm This cloud model ls;~)JlpQ~:of five essential characterlst!cs, three
: service models, arid four deployment models.
;
I Essential Characteristics:
• On-demaiid 5elf-sei'vlee - A consumer can unilaterally provision oomputing capabifltJes. such as
server.time.and networl( storage, as lliieded aut11maticallv without requinng human Interaction
: ·with each service provider.
; Broad network access -Capabilities are available:over the network.arid accessed th rt' ugh
·standard rnech.anJsms t~~t promote use by heter0ger1eous thin or thick client platforms (e.g.,.
25
Exhibit B.1
mobile phones, tablets. lapto~; and WoJrkstdtflJnS).
Resource pooling -The provider's computing resource~ are poofed to serve multiple consumers
using a multi-tenant model, with different physical and virtual resources dynamltally assigned arid
reas5igned accqrc:Jfns to consumer derr1and. There is a ~nse of location Independence in that the
customer generalt~ has noicontrol 1or knowledge o\ler th'° e~ctil->cation of the provided resources
but may be able to_spedfy location at a higher level of ab~traciion {e.g., oountr,·, state, or
datacenter). Example~ of resources i11clude st.orage, processing, memory, and network bandwidth.
~ " . . . . . ''
Rapid elastlclty-Capabilities can be elastitall·f j.iro~~ned and released, rn some cases
automatically, w SOJla rapidt1 outward and' inward commen~urate with demand.• To the·
consumer, the cap.atiilities avallablP. for provisioning crften appear to be ·unlimited and can be
appropriated In any quantity at any time.
Measured service -Cloud systems a•Jtomatlcally contrtJI and optimize resource use by leveraging
. a-metering capabiiityl at some level of abstraction appropriate to the type of service (e.g.,
stori1ge, proces.~ng, bandwidth, and active user accounts);:Resourct! usage can be monitored,
cdntrolled, and re'P?rted, providing transparency for both the j>iovlder and consumer of the
utilized service.
Service· Models:
Software as.a Service (SaaS) -The capability provided to the corisu~er is to. use the provider's
applleatlon5 running on a cloud intrastructure2. The applldltlons are accessible frorn vaifous client
devices t~rough eiti,er a th,in client interface, such as a web bro~ser-(e:g;, web-based emaj!), ot a
program interface .. The ~:>nSumer does not'managi! or control the underlying doud irifrastruct!Jre
lnchJdlng network, .~rvers, operating systems. storage, or even indiVid1Jal applk:atlon capabilities,
with the posslbie excepti11n of limited u,ser-specifi~ applitatlon configuration settin3s.
Platform as a Service (PaaS) -The capabil-ity provided t~ the consumer is t6'.'deploy l'nt-> the cloud
inhstructure consumer-created or acqulr@d applications created using prograrnming.languases,
ITbrarie-s, services, and tools supported by th~ provider .3·The consumer does. not ma'lage or
control the underlyins cloud~infrastructu1e includiilg network. servers, operatin11 systems, or
stora_se, but h_a£ g:Jntffil over the di!ployed applieations and posilbly c;onflsuration settiilgs for the
:ipplication-hosting environment.
lrifrastructure as Ii Service (laaS)-The capabllityJP..rg~@_e_tf1~-tlh! consumer Is to p~ovlslun
processlr1g. storage, networks, and other fundamental computing resources where the c~nsumer
Is able to deploy and run arbitrary software, which can Include operating systems and
. appllcatlon5. The-c6nsumer does not manase or control the underlying cloud ,1nfrastructura but
. has control over o'pi!ratintd'Ystems, Storage; and deployed apptrcations; and possibly limited
cuntrol of sela1 netwi>rt.:ing c.omponents1(e.g., host firewalls).
26
Exhibit 8.1
Deployment Models:
Private doud -The ~loud lnfrastruct•Jre is provisioned tor exclusi~ use by a single orsanization
comprising multiple consumers (e.g., busi~ss unit .. ). It may be'own~d~,maiiaged~ and\;perat'ed by
' the organization, a third-party~ or some combination of them~ and it may e~iSt on ~r off prerritses..
Community dOud ·The clO!Jd ·infrastructure is proVisioned for exclusive, U5'! by a spedfic
tonimunity of consumers· from organiZati6ns that havia shared.concerns (e.g'., miSsion, secuntv:
requirements, policy, arid cornpll~nce oonsideratlons)dt may be owr1ed, man:1ged1,and operated .
by one or mo.~ of the orsanizatlons:in the o.immunity, ·a third party, or sCJmeX~gffi\it_~gQ.rrof
them, arid it mav exist on or off premises.,
Public cloud -The doud infrastructure Is proVtsioned for open use by the· general publfi: •. It may be·
owned! managed, and operated by a business, acadernlc, or gowrnment orgaf!liation, or 5oine
combination' of them; It exists on the prerrllses of the cloud provider. • --
; Hybrid cloud -The doud infrastructura iS a compositir.>n of two or more distinct cloud
fntrastructures {i>rlvate, communitv, or public) that tetnain unfque entities, but are bound
~ ' ' . ~-
' together by standardized or propi'ie~ry technology that enables data and appllca1:ion portability
'(e.g.~ clou_d bursting fur load b&lancing between clouds)~
1 Typir.aJly this is done on a pay-per.US., 9r chai'gl!1Jer-ilse ti3'sis •...
' ·>' •• • ...
2 A tloud:infrastructure is the .:olle<.tfori cif hardwar-. and softwara that ienables t'Mflve.essentlal
characteristlb. of cloud computi'ns;·Thedoud thfrastructure.can be·'~wed·as ~Clntainlr.g berth~ ph)'Sital
layer and ari abstraetlo!" lll'fer •. The physiCal layer consist!'. of the hardware r-.s.,urces that are neeessary:1:o
support th~ doud se~.:es bl!ti~g p~ovlded,; and tvi:iica11Y·lnc1udes server •. sto~e alld network com~nents .. _
The abstrad:io.n layer consists ofthe softWare deployed acros's the physical layer, which manifests the
~~nfllii doud characterlsti~. CorKeptl.lally the a~tractiOn layer sits eb~e the phVsl~l layer~-, . '
"! 1n '
3 Thl_s capability does not nec:essarily;predude the use of compatible programming lan1ua!leli, libraries,
serVices, and toi:>IS'from'other sourr~:
Cloud Drive:
A cloud drive is a Web-based service that provides storage space on a remote
server.
c1oud Audit':
Cloud Audit Is a specification developed at CSco Systems, Inc. that provides
cloud computing service providers a standard way to present and share
detailed, automated statistics about performance and security.
27
Exhibit B.1
Comminglin~:
Commingling is the creation of a common database or repository that stores and
maintains both SSA-provided and preexisting EIEP PII.
Degau.~~ng:
Degaussing Is the method of using a "special device" (i.e., a device that
generates a magnetic field) in order to disrupt magnetically recorded
Information. Degaussing can be effective for purging damaged media and media
with exceptionally large storage capacities. Degaussing Is not effective for
purging non-magnetic media (e.g., optical discs).
Dial-up:
Sometimes used synonymously with dial-in, refers to dlgltal data transmission
over the wires of a local telephone network.
Function;
One or more persons or organizational components assigned to serve a
particular purpose, or perform a particular role. The purpose, activity, or role
assigned to one or more persons or organlzatlonal components.
Hub~
As it relates to electronic data exchange with SSA, a hub is an organization,
which serves as an electronic information conduit or distribution collection
point. The term Hub Is interchangeable with the terms "StateTransmission
Component," "State Transfer Component," or "STC."
IC.ON:
Interstate Connection Network (various entitles use 'Connectivity' rather than
'Connection')
1\18r. V:
Independent Verification and Validation
Legacy System:
A term usually referring to a corporate or organizational computer system or
network that utlllzes outmoded programming !anguages, software, and/or
hardware that typically no longer receives support from the orlglnal vendors or
developers .
. Manual Transactton:
A user-Initiated operation (also referred to as a "user-initiated transactionu).
This Is the opposite of a system-generated automated process.
Example: A user enters a client's information lncludlng the client's SSN and
presses the 'ENTER' key to acknowledge that Input of data is complete. A
new screen appears with multiple options, which include "VERIFY SS~ and
28
'CONTINUE". The user has the option to verify the client's SSN or perform
alternative actions.
Media Sanitizatlor,:
• Disposal: Refers to the discarding (e.g., recycling) of media that
contains no sensitive or confidential data.
Exhibit B.1
• Clearing: This type of media sanitization is adequate for protecting
Information from a robust keyboard attack. Clearing must prevent retrieval
of Information by data, disk, or file recovery utilities. Clearlng must be
resistant to keystroke recovery attempts executed from standard Input
devices and from data scavenging tools. For example, overwriting Is an
acceptable method for clearing media. Deleting Items, however, is not
sufficient for clearing.
This process may include overwriting all addressable locations of the data, as
well as Its logical storage location (e.g., Its file allocation table). The aim of
the overwriting process Is to replace or obfuscate existing information with
random data. Most rewrlteable media may be cleared by a single overwrite.
This method of sanitization Is not possible on un-writeable or damaged media.
111. Purging: This type of media sanitization is a process that protects
information from a laboratory attack. The terms clearing and purging are
sometimes synonymous. However, for some media, clearing Is not
sufficient for purging (i.e., protecting data from a laboratory attack).
Although most re-writeable media requires a single overwrite, purging
may require multlple rewrites using different characters for each write
cycle.
This Is because a laboratory attack Involves threats with the capablllty to
employ non-standard assets (e.g., specialized hardware) to attempt data
recovery on media outside of that media's normal operating environment.
Degaussing Is also an example of an acceptable method for purging magnetic
media. The EIEP should destroy media if purging Is not a viable method for
sanitization.
ii Destruction: Physical destruction of media is the most effective form of
sanitization. Methods of destruction include burning, pulverizing, and
shredding. Any residual medium should be able to withstand a laboratory
attack .
. Permission module:
A utility or subprogram within an appllcatlon, which automatically enforces
the relationship of a request for or query of SSA-provided Information to an
authorized process or transaction before initiating a transaction. For
example, requests for verification of an SSN for issuance of a driver's license
happens automatlcally from within a state driver's license application. The
System wlll not allow a user to request information from SSA unless the
EIEP's client system contains a record of the subject individual's SSN.
screen· s~raping:
29
Exhibit 8.1
Screen scraping is normally associated with the programmatic collection of visual
data from a source. Orlglnally, screen scraping referred to the practice of
reading text data from a computer display terminal's screen. This involves
reading the terminal's memory through Its auxlllary port, or by connecting the
terminal output port of one computer system to an Input port on another. The
term screen scraping is synonymous with the term bidirectional exchange of
data.
A screen scraper might connect to a legacy system via Telnet, emulate the
keystrokes needed to navigate the legacy user interface, process the resulting
display output, extract the desired data, and pass It on to a modem system.
More modem screen scraping techniques include ~pturlng the bitmap data
from a screen and running It through an optlcal character reader engine, or
In the case of graphical user Interface applications, querying the graphical
controls by programmatlcally obtaining references to their underlylng
programming objects.
Security Breach:
An act from outside an organization that bypasses or violates security policies,
practices, or procedures.
security I.ncident:
A security incident happens when a fact or event signifies the posslblllty that a
breach of security may be taking place, or may have taken place. All threats are
security Incidents, but not all security Incidents are threats.
Security Violation:
An act from within an organization that bypasses or disobeys security
policies, practices, or procedures.
~ensitiv~ dat~:
Any Information, the loss, misuse, or unauthorized access to or modification of
which could adversely affect the national Interest of the conduct of federal
programs, or the privacy to which individuals are entitled under section 552a of
title 5, United States Code (the Privacy Act), but which has not been specifically
authorized under criteria established by an Executive Order or an Act of Congress
to be kept secret In the interest of national defense or foreign policy.
c ~Ml;>S (Swit~hf¥c:t Multimega.bit:D~t~ $eryi~~ (-SMD!;)~
SMDS Is a telecommunications service that provides connectionless, high-
performance, packet-switched data transport. Although not a protocol, it
supports standard protocols and
communications Interfaces using current technology.
SSA~P .. rovided:data/ inf~rrriatiqn:
Synonymous with 'SSA-supplied data/Information! Defines Information under
the control of SSA that Is provided to an external entity under the terms of an
information exchange agreement with SSA. The following are examples of
30
Exhibit 8.1
SSA-provided data/Information:
• SSA's response to a request from an EIEP for Information from SSA (e.g., date
of death)
• SSA's response to a query from an EIEP for verification of an SSN
S_SA d_ata/,informa~ion~
This term, sometimes used Interchangeably with •ssA-provlded data/Information•,
denotes
information under the control of SSA that is provided to an external entity under
the terms of an Information exchange agreement with SSA. However, "SSA
data/infonnatlon" also Includes Information provided to the EIEP by a source
other than SSA, but which the EIEP attests to that SSA verified It, or the EIEP
couples the Information with data from SSA as to to certify the accuracy of the
information. The following are examples of SSA Information:
• SSA's response to a request from an EIEP for Information from SSA (e.g., date
of death)
• SSA's response to a query from an EIEP for verification of an SSN
o. Display by the EIEP of SSA's response to a query for verification of an
SSN and the associated SSN provided by SSA
• Display by the EIEP of SSA's response to a query for verification of an
SSN and the associated SSN provided to the EIEP by a source other
than SSA
• Electronic records that contain only SSA's response to a query for verification of
an SSN
and the associated SSN whether provided to the EIEP by SSA or a source
other than SSA
SSN:
Social Security Number
STC:
A State Transmission/Transfer Component is an organization that performs as an
electronic information conduit or collection point for one or more other entitles
(also referred to as a hub).
Syst~.m·g~nerate_d tr~nSillC~i_on:
A transaction automatically triggered by an automated system process.
Example: A user enters a client's information Including the client's SSN on an
Input screen and presses the "ENTER0 key to acknowledge that Input of data Is
complete. An automated process then matches the SSN against the
organization's database and_ when the systems finds no match, automatically
sends an electronic request for verification of the SSN to SSA.
31
systems prot·ess:
The Term "Systems Process" refers to a software program module that runs
In the background within an automated batch, onllne, or other process.
Third Party:
Exhibit B.1
This term pertains to an entity (person or organization) provided access to SSA-
provided Information by an EIEP or other SSA business partner for which one or
more of the followlng apply:
• Is not stipulated access to SSA-provided Information by an Information-sharing
agreement between an EIEP and SSA
• has no Information-sharing agreement with SSA
• SSA does not dlrectly authorize access to SSA-provided information
Tran-saction-drrven:
This term pertains to an automatically Initiated on line query of or request for
SSA Information by an automated transaction process (e.g., driver license
issuance, etc.). The query or request wlll only occur the automated process
meets prescribed conditions.
UncontrQlle~ transactl.on:
This term pertains to a transaction that falls outside a permission module. An
uncontrolled transaction Is not subject to a systematically enforced relationship
between an authorized process or application and an existing cllent record.
(THE REST OF THIS PAGE. HAS BEEN LEFT BLANK INTENnONALLY)
32
s. Regulatory References
0 ---
Federal Information Processing Standards
(FIPS) Publications Federal Information
Security Management Act of 2002 (FISMA)
Homeland Security Presidential Directive
(HSPD-12)
National Institute of Standards and Technology (NIST) Special Publications
Office of Management and Budget (OMB) Circular A-123, Management's
Responsibility for Internal
Control
Office of Management and Budget (OMB) Circular A-130, Appendix III,
Management of Federal
Information Resources
Exhibit B.1
Office of Management and Budget (OMB) Memo M-06-16, Protection of Sensitive
Agency
Information, June 23, 2006
Office of Management and Budget {OMB) Memo M-07-16, Memorandum for the
Heads of Executive
Departments and Agencies May 22, 2007
Office of Management and Budget (OMB) Memo M-07-17, Safeguarding Against
and Responding to the Breach of Personally Identifiable Information, May 22,
2007
Privacy Act of 1974
:{THE REST OF THIS PAGE •HAS BEl;N. LEFT :QLANK INTENTIONALLY)
33
'~· F.requently Asked Questions 0 .
(Click links: for answers or addutinnal information)
1. Q: What is a -~~.r..U. of data?
A: Refer also to S?curity Breach., Seclfrily !nddent, and Security
~t.l~m.
Exhibit B.1
2. Q: What is employee hrc·~_!.ng?
A: Requests for or queries of SSA-provided information for purposes not
related to the performance of offlclal job duties
3. Q: Okay, so the SOP was submitted. Can the Onsite Review be
scheduled now?
A: Refer to ~(il!.llnr~Qllfil.te..R.~.~t.
4. Q: What is a "~~rmL~filori f!1..odule~?
A: A utllity or subprogram within an application, which
automatically enforces the relatlonshlp of a request for or query
of SSA-provided Information to an authorized process or
transaction before initiating a transaction. For example, if
requests for verification of an SSN for issuance of a driver's
license happens automatically from within a state driver's
license application. The System will not allow a user to request
information from SSA unless the EIEP's cllent system contains a
record of the subject individual's SSN.
5. Q: What is meant by Sc;e,~n S{:.r;ulln9.?
A: Screen scraping Is normally associated with the programmatic
collection of visual data from a source. Originally, screen scraping
referred to the practice of reading text data from a computer display
terminal's screen. This Involves reading the terminal's memory
through Its auxiliary port, or by connecting the terminal output port
of one computer system to an input port on another. The term
screen scraping Is synonymous with the term bidirectional exchange
of data.
A screen scraper might connect to a legacy system via Telnet,
emulate the keystrokes needed to navigate the legacy user
Interface, process the resulting display output, extract the desired
data, and pass it on to a modern system.
More modern screen scraping techniques Include capturing the
bitmap data from a screen and running it through an optical
character reader engine, or in the case of graphical user
interface applications, querying the graphical controls by
programmatically obtaining references to their underlying
programming objects.
6. Q: When does an EIEP have to submit an SOP?
A: Refer to When the ~U;_)P ~ruL8A..2!:.~ Regyjred.
7. Q: Does an EIEP have to submit an SOP when the agreement Is
34
Exhibit B.1
renewed?
A: The EIEP does not have to submit an SOP because the agreement
between the EIEP and SSA was renewed. There are, however,
circumstances that require an EIEP to submit an SOP. Refer to
\.Y.h~.Jt.~_$.Q~?.J;:!P~~.Rem:!rgd.
a. Q: Is it acceptable to save SSA data with a verified indicator on a
(EIEP) workstation if the EIEP uses an encrypted hard drive? If not,
what options does the agency have?
A: There is no problem with an EIEP saving SSA-provided Information
on the encrypted hard drives of computers used to process SSA
data If the EIEP retains the information only as provided for In the
EIEP's data-sharing agreement with SSA. Refer to Data and
.C.Q_mml!ni~~l"-&Vrjty.
9. Q: Does SSA allow EIEPs to use caching of SSA-provided Information on
the EIEP's workstations?
A: Caching during processing Is not a problem. However, SSA-provided
Information must clear from the cache when the user exits the
appllcatlon. Refer to Datt! and Communiec1tlons Securicy.
10. Q: What does the term "interconnections to other systemsn mean?
A: As used in SSA's system security requirements document, the term
"Interconnections" Is the same as the term "connections. n
11. Q: Is It acceptable to submit the SOP as a .PDF file?
A: No, It Is not. The document must remain editable.
12. Q: Should the EIEP write the SOP from the standpoint of my agency's
SVES access itself, or from the standpoint of access to all data
provided to us by SSA?
A: The SOP is to encompass your agency's electronic access to SSA-
provided Information as per the electronic data sharing agreement
between your agency and SSA. Refer to Develoojng the SOP.
13. Q: If we have a "transaction-driven" system, do we still need a
permission module? If employees cannot Initiate a query to
SSA, why would we need the permission module?
A: "Transaction driven" basically means that queries automatically
submit requests (and It might depend on the transaction).
Depending on the system's design, queries might not be automatic or
it may still permit manual transactions. A system may require
manual transactions to correct an error. SSA does not prohibit
manual transactions If an ATS properly tracks such transactions. If a
"transaction-driven" system permits any type of alternate access; it still
requires a permission module, even If It restricts users from performing
manual transactions. If the system does not require the user to be
In a particular application or the query to be for an existing record in
the EIEP's system before the system will allow a query to go through
to SSA, It would stlll need a permission module.
14. Q: What is an Onsite Compllance Review?
35
Exhibit B.1
A: The Onslte Compliance Review is the process wherein SSA performs
periodic site visits to its Electronic Information Exchange Partners
(EIEP) to certify whether the EIEP's technical, managerial, and
operational security measures for protecting data obtained
electronically from SSA continue to conform to the terms of the EIEP's
data sharing agreements with SSA and SSA's associated system
security requirements and procedures. Refer to the .C..Q.nl?liance
~.rt .... fmgraro..£n{:I Prc~e$.;.
15. Q: What are the criteria for performing an Onslte Compliance Review?
A: The following are criteria for performing the Onslte
Compliance Review:
• EIEP initiating new access or new access method for obtaining
information from SSA
o EIEP's cyclical review (previous review was performed remotely)
~. EIEP has made significant change(s) In Its operating or security
platform Involving SSA-provided Information
• EIEP experienced a breach of SSA-provided personally identifying
information (PII)
• EIEP has been determined to be high-risk
Refer also to the .Re.vl~.w De.F-rmin~.tiQil.....Matax.
16. Q: What Is a Remote Compliance Review?
A: The Remote Compliance Review Is when SSA conducts the meetings
remotely (e.g., via conference calls). SSA schedules conference calls
with Its EIEPs to determine whether the BEPs technical, managerial,
and operational security measures for protecting data obtained
electronically from SSA continue to conform to the terms of the EIEP's
data sharing agreements with SSA and SSA"s associated system
security requirements and procedures. Refer to the ~l.!.fill.t..~
R~view Program and Prn~.~.
17--. Q: What are the criteria for performing a Remote Compliance Review?
A: The EIEP must satisfy the following criteria to qualify for a Remote
Compliance Review:
• EIEP's cyclical review (SSA's previous review yielded no findings
or the EIEP satisfactorily resolved cited findings)
• EIEP has made no significant change(s) in its operating or
security platform Involving SSA-provided information
• EIEP has not experienced a breach of SSA-provided
personally Identifiable information (PII) since its
previous compliance review.
• SSA rates the EIEP as a low-risk agency or state
36
Exhibit B.1
Refer also to the fu!.Y.i.e~ Determinatlon Matrix
37
•·
'
'
'
Exhibit 8.1
ATTACHMENT 5
WORKSHEET FOR REPORTING LOSS OR POTENTIAL LOSS
OF PERSONALLY IDENTIFIABLE INFORMATION
ATTACHMENTS
Worksheet for Reporting Loss or Potential Loss of Personally Identifiable
lnforrnation
1. Information about the individual making the report to the NCSC:
Name:
Position:
De Commissioner Level Or anization:
Phone Numbers:
Work: Cell: Home/Other:
E-mail Address:
M ement Official
2. Information about the data that was lost/stolen:
Describe what was lost or stolen (e.g., case file, MBR data):
Which element(s) of PII did the data contain?
Name Bank Accowit Info
SSN ·Medical/Health Information
Date of Birth Benefit Payment Info
Place ofBirth Mother's Maiden Name
Address Other (describe):
Estimated volume of records involved:
3. How was the data physically stored, packaged and/or contained?
Paper or Electronic? (circle one):
Exhibit B.1
OfJf27/06
Workstation Server CD/DVD Blackberry Phone #
1--~~~~-1--t-~~~~+-+-~~~~--+---1
Hard Drive Flo Disk USB Drive
Other (describe):
Exhibit B.1
ATTACHMENT 5 09/27/06
Additional Questions ifElectronic:
Yes No Not Sure
a. Was the device encrypted?
b. Was the device password protected?
c. If a laotop or tablet. was a VPN SmartCard lost?
Cardholder's Name:
Cardh.older's SSA logon PIN:
Hardware Make/Model:
Hardware Serial Number:
Additional Questions if Paper:
Yes No Not Sure
a. Was the information in a locked briefcase?
b. Was the information in a looked cabinet or drawer?
c. Was the information in a locked vehicle trunk?
d. Was the information redacted?
e. Other circumstances:
4. If the employee/contractor who was In possession of the data or to whom the
data was assigned ls not the person making the report to the NCSC (as listed in
#1), information about this employee/contractor:
Name: I
Position: I
Deouty Commissioner Level Organization: I
Phone Numbers:
Work: I l Cell: I I Home/Other: 1
Epmail Address: I
5. Circumstances of the loss:
-a. When was it lost/stolen?
h. Brief description of how t4e loss/theft occurred:
c. When was it reported to SSA management official (date and time)?
6. Have any other SSA ·components been contacted? H .so, who? (Include deputy
commissioner level, agency level, regionaVassociate level component names)
I
l
I
I
l
I
I
Exhibit B.1
ATTACHMENTS 09/27106
7. Which reports have been ftled? (include FPS,. local police, and SSA reports)
Report Filed Yes No Renort Number
Federal Protective Service :
Local Police
Yes No
SSA-3114 (Incident Alert)
SSA-342 (Report of Survey)
Other ( descn'be)
8. Other pertinent information (include actions under way, as well as any contacts
with other agencieat law enforcement or the press):
l
I
!
I :
i
I
.,
I
RECERTIFICATION OF THE COMPUTER MATCHING AGREEMENT
BETWEEN
THE SOCIAL SECURITY ADMINISTRA'l'lON (SSA)
AND
THE HEALTH AND HUMAN SERVICES AGENCY OF CALIFORNIA
(ST ATE AGENCY)
SSA Match #6003
Exhibit 8.1
Under the applicable provisions of the Privacy Act of 1974, amended by the Computer Matching
und Privacy Protection Act (CMPPA) of 1988, 5 U.S.C. ~ 552a(o)(2}, a computer matching ·
agreement will remain in effect for a period not lo exceed 18 months. Within 3 months prior lo
the expiration of such computer matching agreement, however, the Data Integrity Board (DlB)
may, without additional revlew, renew the computer matching agreement for a current, ongoing
mHtching program for a perjod not to.exc"d 12 ac]di!ional mopilis ff:
l. such program will be conducted without any changes; and
2. each party to the agreement certifies to the DIB in writing that the program h11s been
conducted in compliance with the agreement.
The following match meets the conditions ror renewal by thLc; recertification:
I. TITLEOFMATCH:
Computer Matching and Privacy Protection Act Agrt:emcnl Between the Social Security
Administralior. and the Health and Human Services Agency of California (Maleh #6003)
JI. Pf\!ffIES TO THE MATCH:
Recipient Agency: The Health and Human Services of California (State Agency)
S-ource Agency: Social Security Administration (SSA)
III. PURPOSE OF THE AO REEM ENT;
This CM PP A Agreement beLween SSA and tho State Agency, !iOt.C\ forth the terms and
conditions governing disclosures of records, information, or data (collectively referred lo
herein "data") made by SSA to the: State Agency that administe.r.s federally funded benefit
programs under various provisions orthe· Social Security Act (Act), such as section 1137
(42 U.S.C. § l320b-7). Including the state-funded state supplementary payment prognuns
untler title XVI of the Act Under section 1137 of the Act.. the State Agency is required
to u!ie an income and eligibility verification system to administer specified federally
fL1ndcd benefit programi;, including the slate-funded i;tate supplementary payment
programs under litlc XVI or lhe Act. To a!il\ist the State Agency in dctennioing
I
I
I
' l
l j
I
l
1
l
Exhibit B.1
2
entitlement to Wld cligib"ility for benefits under those programs, as well as other federally
funded benefit programS., SSA discloses certuin data about applicants for1itate benefits
from SSA Privacy Act Sy~tems of Records an<l verifies lhe Social Securily numbers of
the applicants.
JV. ORJGINAL EFFECTIVE AND EXPIRATION DATES OF THE MATCH:
Effective Date:
Expiration Date:
July I, 2012
December 31, 2013
V. RENEWALANDNEWEXPlRAT!ON DATES:
Renewal Dute: January l, 2014
New Expiration Date: Decemb1;r 31, 2014
VJ. CHANGES:
By this recertification, SSA and the Slltle Agency m11ke the following non-subslllntive
changes to the computer malching agreement:
In Article XIV, ·"Points of Contact,·· information under ~ubsection A .. "'SSA Point of
Conto.ct, Regional Office," should be deleted in iLs entirety and replaced with the
following:
Dolores Dunnachic, DirecLor
San Francisco Regional OfficcJ Center for Prog"rnms Supporl
1221 Nevin Ave
Richmond CA 9480 l
Phone: (510) 970-8444/Fax: (5 IO} 970-8101
Dolon:s.Dunim~h je@sim.gov
I
I
I
i
i
J
j
I
I
I
l
I
I
I
I
' j
l
1
I
j
I
{
' I
Exhibit B.1
Social Security Administration
Source Agency Certification:
As the uuthorizt:d representutivc of the i;ource agency named above, l certify thul; (I) the
subject m1.nching program was conducted in complia11ce with the existing computer
matching agreement between the parties; and (2) the 8ubject matching program will
continue without any change for an additional 12 months, subject Lo the approval of the
Dttta Integrity Board of the Social Security Administration.
Grace M .. Kim
Regional Commissioner
San Francisco
Dute 1' l i.... \ · L.i""">
Data I DL£grity 13oarg Certification:
A.r; Chair of tht: Data Integrity Board of the source agency named above, I certify that:
(1) the subject matching program was conducted in cornplinncc with the existing
computer matching agreenu:nt between the parties: and (2) the subject matching program
will continue without any chang~ for un udditionnl 12 months.
_ ~ii,t\&;;~ .. ~-
.lC.Jnllen J. M~ •· -~
QRNl .
~~ty:SO.nl
Date_ _!°l/1£112-~
I
I
I . I
I I
I
..
Exhibit B.1
4
Health und Human Serylces Agency of Californiu
Recipient Agpm.:y Ceni'ticatiog:
As the uuthorized representative of the recipient agency named above, I ccrt~fy that:
(1) the subjecl mRtching program was conducted in compliance with the existing
compu1er matching agreement between the parties; and (2) the suhject matching progrmn
will continue without any change for Hn additionul 12 month.~. subject to the upprov11l of
the Dnta Jrnegrily Board of the SociHI Security Administration.
Diana S. Dooley, Secrewry
Date~ So1 Mil3
I ..
I
1 I
Exhibit 8.2
CDSS MOU No. 15-MOU-00576
DHCS 14-90495
IEA SSA and COSS Agreement
Agreement #lS-FED-00207
CDSS/S·ocial Security Administration
Exhibit B.2
2015 JEA CERTIFICATION OF COMPLIANCE
(JEA-F)
CERTIFICATION OF COMPLIANCE
FOR
THE INFORMATION EXCHANGE AGREEMENT
BETWEEN
THE SOCIAL SECURITY ADMINISTRATION (SSA)
AND
THE CALIFORNIA DEPARTMENT OF SOCIAL SERVICES (STATE AGENCY)
(State A.t?e1icy Level)
In accordance with the terms of the lnformatit1n Exchange Agreement (IEA/F) between SSA and
the State Agency, the State Agency, through its authorized representative, hereby certifies that,
as of the date of this certification:
l. The State Agency is in compliance with the terms and conditions of the IEAJF;
2. The State Agency has conducted the data exchange processes under the IEA/F without
change, except as modified in accordance with the IBNF;
3. The State Agency will continue to conduct the data exchange processes under the IEA/F
without change, except as may be modified in accordance with the IENF;
4. Upon SSA's request, the State Agency will provide audit reports or other documents that
demonstrate compliance with the review and oversight activities required under the
IEA/F and tl1e governing Computer Matching and Privacy Protection Act Agreement;
and
5. In compliance with the requirements of the "Electronic Information Exchange Security
Requirements and Procedures for State and Local Agencies Exchanging Electronic
Infonnation with the Social Security Administration," (last updated April 2014)
Attachment 4 Lo the IEA!F, as periodically updated by SSA, the State Agency has not
made any changes in the following areas that could potentially affect the security of SSA
data:
• General System Security Design and Operating Environment
• System Access Control
• Automated Audit Trail
• Monitoring and Anomaly Detection
a Management Oversight
• Data and Communications Security
• Contractors of Electronic Information Exchange Partners
The State Agency will suhmit an updated Security Design Plan at least 30 days prior to
making any changes to the areas listed above and provide updated contractor employee
lists before allowing new employees' access to SSA provided data.
I
Exhibit B.2
2015 IEA CERTIFICATION OF COMPLIANCE
(IEA-F)
6. The State Agency agrees that use of computer technology to transfer the data is more
economical, efficient, and faster than using a manual process. As such, the StateAgcncy
will continue to utilize data exchange to obtain data it needs to administer the programs
for which it is authorized under the IEA/F. Further, before directing an individual to an
SSA field office to obtain data, the State Agency will verify that the information it
submitted to SSA via data exchange is correct, and verify with the individual that the
information he/she supplied is accurate. The use of electronic data exchange expedites
program administ.ration and limits SSA field office traffic.
2
Exhibit B.2
2015 IEA CERTIFICATION OF COMPLIANCE
(IEA-F)
The signatory below warrants and represents that he or she is a representative of the State
Agency duly authorized to make this certification on behalf of the State Agency.
THE CALlFORNlA DEPARTMENT OF SOCIAL SERVICES
' ; -· jf';) _.('.' !)I . t . (ll __ 1;1 I ( '1'.'' --__ _,iA. '· .. -~----/
Debor;d1 Pearce
Contracts and Purchasing Bureau
/o-.. , (") I I () ..... I '-("
Date
3
Exhibit l:l.2
IEA-F Agreement 09-6008 A-1
CDSS/Social Security Administration
t; .. :§;m:..s:;~-2!. S::·-~!llli6':E#S§1:0lll·~-.:::;;,.....!ii:iiW~.l!!'il--.. -~.>4.®il!l!i. M~. P.t7fil!J?Ef., .. ~.-#~.£ .SS!l"""!2::1!21_ •!ll!l!llllil!l!!!!l!l!S!li=!3!!Z!!!;!l&;;:J .. ~·~-=i:;os;;;sm2':!!i!!!'mm:::!l!E!l!l!=::!:l!llRlllZ=mlili>~-Ri¥m~:.:!/l!_ l>/llll~ .• ~al. s:l.~----. . :"""*~:s:.:-~"'Z
INFORMATION EXCHANGE AGREEMENT
BETWEEN
THE SOCIAL SECURITY ADMINISTRATION (SSA)
AND.
THE CALIFORNIA DEPARTMENT OF SOCIAL SERVICES
A, PURPOSE; The purpose of this Information Exchange Agreement ("!EA") is to establish
tenns, conditions, and safeguards under vvhich SSA will disclose to the Galifomia
Depart!1'1ent of Social Services (-Stat-e-A-geH-e-y-B-Ft~State Agency certain infonnation,
records, or data (herein "data") to assist the State Agency in administering certain federally
funded state-administered benefit programs (including state-funded state supplementary
payment programs under Title XVJ of t11e Social Security Act) identified in this TEA. By
entering into this IEA, the State Agency agrees to comply with: -
• the terms and conditions set forth in tl1e Computer Mate.fri-a-g-a-FH:i-P--fi.¥a-ey ProtectiBR-Aet
A-greei'Be-nt (''CMPPt\ Agree~) aH-a€h-ed arJ Attaehment 1, Recertification of the
Computer Matching Agreement Between The Social Security Administration (SSA)
And The California Health and Human Services Agency (State Agencv) attached as
• Attachment I-A governing the State Agency's use of the data disclosed from SSA's
• Privacy Act System of Records; and
• all other terms and conditions set forth in this IEA.
B. PROGRAMS AND DATA EXCHANGE SYSTEMS: (1) ll1e State Agency will use the
data received or accessed from SSA under this IEA for the purpose of administering the
federally funded, state-administered programs identified in Table 1 below. ln Table l, the
State Agency has identified: (a) each federally funded, state-administered program that it
administers; and (b) each SSA data exchange system to which the State Agency needs access
in order to administer the identified program. The list of SSA's data exchange systems is
attached as Attachment 2: '
TABLE1
FEDERALLY FUNDED BENEFIT PROGRAMS .· -'-"
.. -. . : -, . . . . . -~~· . .. ·
Program SSA Data Exchange System(s)
[8J Medicaid BENDEXISDX/SVES /-Citizenship_
[8J Temporary Assistance to Needy Families
(TANF) California Work Opportunity and BENDEX/SDX/SVES/PUPS
Responsibility to Kids (CalWORKS)
~ Supplemental Nutrition Assistance Program BENDEX/SDX/SVES/PUPS/Quarters of Coverage (SNAP-formally Food Stamps)
D Unemployment Compensation (Federal)
D Unemployment Compensation (State) .
D State Child Support Agency
,_ --
Agreement 09-6008 A-1
COSS/Social Security Administration
D Workers Compensation
Vocational Rehabilitation Services
IEA-F
Exhibit B.2
I D J
~ Foster Care (IV-E} I SDX/BENDEX/SVES
0 State Health Insurance Program (S-CHIP) I
D Women, Infants and Children (W .l.C.)
D Medicare Savings Programs (MSP)
' 0 Medicare 1144 (Outreach)
;
I ·~ Other Federally Funded, State-Administered Programs (List Below)
Program SSA Data Exchange System(s)
State Supplemental Payment (SSP) SOX
Refugee Cash Assistance
SDX/BENDEX/SVES
Entrant Cash Assistance SDX/BENDEX/SVES
(2) The State Agency will use each identified data exchange system onlv for the purpose of
administering the specific program for which access to the data exchange system is provided.
SSA data exch<mge systems are protected by the Privacy Act and federal law prohibits the
use of SSA's data for any purpose other than the purpose of administering the specific
program for which such data is disclosed. ln particular, the State Agency will use: (a) the tax
return data disclosed hy SSA only to detennine individual eligibility for, or the amount of,
assistance under a state plan pursuant to Section 1137 programs and child support '.
enforcement programs in accordance with 26 U .S.C. § 6103( 1 )(8); and (b) the citizenship
status data disclosed by SSA under the Children's Health Insurance Program
Reauthorization Act of 2009, Pub. L. 111-3, only for the purpose of determining entitlement
to Medicaid and CHIP program for new applicants. The State Agency also acknowledges
that SSA's citizenship data may be less than 50 percent current. Applicants for SSNs repo1i
their citizenship data at the time they apply for their SSNs; there is no obligation for an
individual to report to SSA a change in his or her immigration status until he or she files a
claim for benefits.
C. PROGRAM QUESTIONNAIRE: Prior to signing this IEA, the State Agency will
complete and submit to SSA a program questionnaire for each of the federally fonded, state-
administered programs checked in Table 1 above. SSA will not disclose any data under this
IEA until it has received and approved the completed program questionnaire for each of the.
programs identified in Table l above. .
2
I
I
I
!
i
I
I
I
Exhibit B.2
Agreement 09-6008 A-I IEA-F
COSS/Social Security Administration
D. TRANSFER OF DATA: SSA will transmit the data to the State Agency under tl1is IEA
using the data transmission method identified in Table 2 below:
TABLE2
TRANSFER OF DAT A
0 Data will be transmitted directly between SSA and the State Agency.
[gJ Data will be transmitted directly between SSA and CA Department of Technology (State
Transmission/Transfer Component ("STC")) by File Trai1sfer Management System (FTMS'I. a
1 secure mechanism approved by SSA. The STC will serve as the conduit between SSA and the
i State Agency pursuant to the State STC Agreement.
I 0 Data will be transmitted directly between SSA and the Interstate Connection Network
(''ICON"). ICON is a wide area telecommunications network connecting state agencies that I administer the state unemployment insurance laws. When receiving data through ICON. the ·
State Agency will comply with the "Systems Security Requirements for SSA Web Access to SSA
Information Through the ICON".
E. SECURITY PROCEDURES: The State Agency will comply with limitations on use,
treatment, and safeguarding of data under the P1ivacy Act of 1974 (5 U.S.C. 552a), as
amended by the Computer Matching and Privacy Protection Act of 1988, related Office of
Management and Budget guidelines, the Federal lnfonnation Security Management Act of
2002 (44 U.S.C. § 3541, et seq.), and related National Institute of Standards and Technology
,h'Uidelines. In addition, the State Agency will comply with SSA's "Information System
Security Guidelines for Federal, State and Local Agencies Recetv-Htg-€1-eetrenic lnfom1ation
from the Social Security Administration," attacl:ie<l-as--Attaelnneat 3 "Electronic
Information Exchange Securitv Requirements. Guidelines and Procedures :For Federal.
State and Local Agencies Exchanging Electronic Information 'With The Social S'ccuritv
Administration." as attached Attachment 4. For any tax return data, the State Agency will
also comply with the "Tax lnfomrntion Security Guidelines for Federal, State and Local
Agencies," Publication 1075, published by the Secretary of the Treasury and available at the
following lnternal Revenue Service (1RS) website: h!!p://www.irs.gov/puh/irs-pdt/pJ_07~,_gQf
This IRS Publication 1075 is incorporated by reference into this IEA.
F. CONTRACTOR/AGENT RESPONSIBILITIES: The State Agency will restrict access to
the data obtained from SSA to only those authorized State employees, contractors, and
agents who need such data to perform their official duties in connection with prnvoses
identified in this IEA. At SSA's request, the State Agency will obtain from each of its
contractors and agents a current list of the employees of its contractors and agents who have
access to SSA data disclosed llnder this IEA. The State Agency will require its contractors,
agents, and all employees of such contractors or agents with authorized access to the SSA
data disclosed under this IEA, to comply with the terms and conditions set forth in this IEA.
and not to duplicate, disseminate, or disclose such data without obtaining SSA's prior written
approval. In addition, the State Agency will comply with the limitations on use, duplication,
and redisclosure of SSA data set forth in Section IX. of the CMPPA Agreement, especially
with respect to its contractors ~nd agents. .•
Agreement 09-6008 A-l
CDSS/Social Security Administration
Exhibit B.2
IEA-F
G. SAFEGUARDING AND REPORTING RESPONSIBILITIES FOR PERSONALLY
IDENTIFIABLE INFORMATION ("PII''):
I. The State Agency will ensure that its employ~es, contractors, and agents:
a. properly safeguard PH furnished by SSA under this IEA from Joss, theft or
inaclverlent disclosure:.
b. understand that they are responsible for safeguarding this inf()1111ation at all times.
regardless of whether or not the State employee. contractor, or agent is a1 his or her
regular duty station~
c. ensure that laptops and other electronic devices/media containing Pl I tfre encrypterl
and/or password protected;
cl. send emails containing PII only if encrypted or if to and from addresses thai are
secure; and
e. limit disclosme of the infom1alion and details relating to a PJI loss only to those with
a need to know.
2. If an employee of the State Agency or an employee of the State Agency's contractor or
agent becomes aware of suspected or actual loss of PII, he or she must immediately
contact the State Agency official responsible for Systems Security designated below or
his or her delegate. Tirnt State Agency official or delegate mus't then notify the SSA
Regional Office Contact and the SSA Systems Security Contact identified below. It~ for
any reason, the responsible State Agency official or delegate is unable to notify the SSA
Regional Office or the SSA Systems Security Contact within 1 hour, the responsible State
Agency official or delegate must cal1 SSA's Network C.ustomcr Service Center
("NCSC'') at 410-965-7777 or toll free at 1-888-772-666 l to report the actual or
suspected loss. The responsible State Agency official or delegate will use the worksheet.
Worksheet for Reporting Loss or Potential Loss of PH attached as Attachment 4.
Attachment 5, to quickly gather and organize infom1ation about the incident. The
responsible State Agency official or delegate must provide to SSA timely updates a~~ any
additional infomrntion about the loss of PII becomes available.
3. SSA will make the necessary contact within SSA to file a fom1al report in ac.cordance
with SSA procedures. SSA will notify the Depai1ment of Homeland Security's United
States Computer Emergency Readiness Team if loss or potential loss of PIT related to a
data exchange under this IEA occurs.
4. lf the State Agency experiences a loss or breach of data, it will determine whether or not
to provide notice to individuals whose data has been lost of breached and bear any costs
associated with the notice or any mitigation.
f
· ...
4
Agreement 09-6008 A-1
CDSS/Social Secmity Administration
H. POINTS OF CONTACT:
FOR SSA
San Francisco Regional Office:
Ellery Brown
Data [x change Coordinator
Frank Hagel Federal Building
1221 Nevin A venue
Richmond, CA 9480 I
(510) 970-8243
(510) 970-8101
Ellery-'-Brown(a~i~22'.
Systems Issues:
Pamela Riley
Office of Earnings, Enumeration &
Administrative Systems
DIVES/Datn Exchange Branch
6401 Security Boulevard
4108 Robert M. Ball Building
Baltimore, MD 21235
Phone: (410) 965-7993
Fax: ( 410) 966-3147
Email: Pame\a.Riley(a!.ssa.Qov
Data Exchange Issues:
Exhibit B.2
IEA-F
G-t-ty-i:;:.e.ffirtm-Keisha Mahon ev
Program A~naiyst
Q.!licc of ElectrBB-i-€-ft-1i(Jrmati(*rL"7K~,;e
Office of the Genera! Counsel
Office of Privacy and Disclosure
617 Altmcver
GD I 0 East High Rise
6401 Security Boulevard
Baltimore, MD 21235
Phone: ( 4 l 0) :W-+--+.+G-3-966-9048
Fax: (410) 597 08·1l 594-0115
Email: guv.f01ison(t£issa.~ov
Keisha.MahonevraJ.ssa.gov
Systems Security Issues:
Michael G. Johnson
Acting Director
Gffi.€€-of Electronic lnfo1111ation EJ1:ehange
Office of Strategic SeFYices
Office of Information Security
Compliance
3820 Annex
640 I Security Boulevard
Baltimore, MD 21235
Phone: (410) 965-0266
Fax: (410) %6 0527 597-1449
Emajl: Michael.G.Jolmson(ii.1ssa.gov
5
Agreement 09-6008 A-1
COSS/Social Security Administration
FOR STATE AGENCY
Agreement Issues:
Suzanne Steinwe1i
Staff Services Manager 1
Exhibit B.2
IEA-F
· · Technical Issues:
Jeff/-\ cl ge
GiTi€:~-Senkw Information Svsten112
Anaivst (Sup.) CDSS, Welforc' to Work Division
Fraud Bureau. Policy Unit
744 P Street, MS +9~ MS 9-U-26.
Sacramento. CA 95814
C-DSb, Welfare to ·work Gi-v-i-s-ios Support
Bureau
Phone: (91 ()) ~7-0G 651-3976
Fax: (916) 263 5'707 651-5009
Email: Suzmme.Stcimvcrt@dss.ca.gov
Information Security Issues:
C ynth i a--Ffil.r-
ffi-fef m-at-ien-&ea!-f-ity-9-ffi.t'ef
Galifomia Depai1men~ of Social Services
714 P Street, M.8. g 3-l-9+
&aeramento, CA-9~
Phone: (9 l 6j-65 J 9923
Email: Cynthia.-Fair@!dss.ca.ge-v
Ravfield L. Scott
Information Securitv Officer
Enterprise Architecture and lnforniation
Securitv Bureau
CDSS, Information Svstcms Division
744 P Street. MS 9-9-70
Sacramento, CA 9'5814
Phone: (916) 651-5558
Email: Rayfield.Scott(ii!,dss.ca.gov
CDS~. Information Systems Division
744 P Street. iv1S .J.9-~-9-8-58
Sacramento, CA 95814
Phone: (9i6) :123 376.;-651-5545
Fax: (916) 4-9-§-9-S49---651-5547
Email: J eff.Adge(q]dss.ca.gov
I. DURA.TION: The etfoctive dare of this lEA is J.atwn£-y-+,-2-G+G January 20, 2012. This IEA
will remain in effect for as long as: ( l) a ClVIPPA Agreement governing this TEA is in effect
between SSA and the State or the State Agency: and (2) the State Agency submits a
certification in accordance with Section J. below at ieast 30 days before the expiration and
renewal of such CMP PA Agreement.
6
Agreement 09-6008A-1
COSS/Social Security Administration
Exhibit B.2
fEA-F
J. CERTiFICATlON AND PROGRAM CHANGES: At least 30 days before the expiration
and renewal of the State CMPPA Agreement governing this IEA, the State Agency will
certify in wTiting to SSA that: ( 1) it is in compliance with the terms and conditions of this
IEA; (2) the data exchange processes under this.)EA have been and will be conducted
-without change; and (3) it will, upon SSA's req'uest, provide audit reports or other documents
that demonstrate revieVv· and oversight activities. l f there are substantive changes in any of
the programs or data exchange processes listed in this JEA, the pmties will modify the IE/\ 111
accordance with Section K. below and the State Agency v...ilJ submi1for SS!\ 's dpprnval new
program questionnaires under Section C. above describing such changes prior to using SSA's
data to administer such ne\:v or changed program.
K. MODIFJCA TION: Modifications to this fEA must be in writing and agreed to by the
parties.
L. TERMINATfON: The pa11ies may te1minate this IEA at any time upon mutual written
consent. In addition, either paiiy may unilaterally terminate this TEA upon 90 days advance
w1itten notice to the other paiiy. Such unilateral termination will be effective 90 days after
t)1e date of the notice, or at a later date specified in the notice.
SSA may immediately and unilaterally suspend the data flow under this IEA or tenninate
this IEA, if SSA, in its sole discretion, determines that the State Agency (including its
employees, contractors, and agents) has: ( 1) made an unauthorized use or disclosure of SSA-
supplied data; or (2) violated or foiled to follow the terms and conditions of this IEA or the
CMPPA Agreement.
M. INTEGRATION: This IEA, including all attachments, constitutes the entire agreement of
the parties with respect to its subject matter. There have been' no representations, warrapties,
or promises made outside of this IEA. This IEA shall take precedence over any other
document that may be in conflict with it.
A-1 ATTACHMENTS
1 --CMPPA Agreement Recertification of the Computer Matching Agreement Between
The Social Securitv Administration (SSA) and The California Health and Human
Services Agency (State Agency) 3 pages
':> SSA Data Exchange Systems
3 -Systems Security Requirements for SSA Web Access to SSA information
Through lCON
4 -Information System Security Guidelines for Federal, State and Local Agencie'.>
Receiving Electronic Information from the Social Sec-...:irity Administration
Electronic Information Exchange Security Requirements, Guidelines and
Procedures for Federal. State and Local Agencies Exchan2ing Electronic
Information with The Social Security Administration 14 pages
5 -PII Loss Reporting Worksheet
7
Exhibit B.2
Agreement 09-6008 A-1 lEA-F
CDSS/Social Security Administration
N. SSA AUTHORIZED SIGNATURE: The signatory below warrants and represents that he
or she has the competent authority on behalf 6f SSA to enter into the obligations set forth in
this IEA.
SOCIAL s:ECURITY ADM!NlSTRATION
Michael · . GaHagher /
Assistant Deputy Co · Jsstoner
for Budget~ Finance and Managen:ient
Date
i;J1:s/1a
! ....
8
Exhibit B.2
Agreement 09-6008 A-I IEA-F
CDSS/Social Security Administration
.
N. SSA AUTHORIZED SIGNATURE: The signatory below warrants and represents that he
or she has the competent authority on behalf 6f SSA to enter into the obligations set forth in
this IEA.
SOCIAL SECURITY ADMINISTRATION
Da.t:e
8
ATTACHMENT 1
COMPUTER MATCHING AND PRIVACY
PROTECTION ACT AGREEMENT
Exhibit B.2
Agreeioont (f)...f:i:f.'f3
CIBS/SSA
Exhibit B.2
IFA-F
CA CHHS CMPPA Agr1,~ment 2010 A1'I'ACHMElfr 1
COMPUTER .MATCH.ING AND PRIVACY PROTECTION_ ACT
AGRE~MENT BETWEEN
THE SOCIAL SECURITY ADMJNISTRATlON AND
TI-ffi CALIFORNIA HEALTH AND HUMAN SER VICES AGENCY
Exhibit B.2
2
TABLE OF CONTENTS
I. Purpose and Legal Authol'ity ................................................................................... 3
II. SCOJ)C ............ , ........ i. •••••••••• , ................. , •• , •• ,,,_, •••• ~ ••••• , • ., •• ,,,,, •• , •••••••••••••••••••••• ,, ................... 4
lll. ,Justification and Expected Results .......................................................................... 5
JV. Record Description ................................................................................................... 5
v. Notice anJ or,IHH1Unity to Contest Procedures ..................................................... 6
Vl. Records Accuracy Assessment and Verification Procedurell ................................ 7
VII. Disposition and Records Retention of Matched Itctns .......................................... 8
VlJI. Security Procedu1·cs .................................................................................................. 8
IX. Records Usngc, Duplication, and llcdisclosure Restrictlons ................................. 9
.X. Co1nptroller General Acccss .................................................................................. 10
XI. Duration, Modification, and Termination of the Agreement ............................. 10
XII. Reimburscn1e11t ....................................................................................................... 1 J.
XICT. Dii;claimer ................................................................................................................ 11
XIV. Points of Con ta.ct ..................................................................................................... 12
XV. SSA Authorized Signature and Data Integrity Board Appro\•111... .................... ..IJ
XVI.. Regional and CH.HS Signaturt~s ............................................................................ 14
I. Purpose and Legal Auth.ority
A. Purpose
This Computer Matching and Priv11cy Protcc1ion Act ("CMPP A") Agreement
between the Social Security Adrninisrration ("SSA") and the Cal.iforni.~ l·.kalth
and Human S~rvices 1\gcncy ("State Agency") ·:~ets fo1ih the terms and ctmdi1ions
governing disclosures of records, infonnation, or data (herein "data") made by
SSA to various departments, boards, and othor organii'.atlons under the
jurisdiction of the State Agency ("CFff-IS Departments") that administer federaily
funded benefit programs under various provisions of the Social Security Act
("Act"), such as Section 1137 (42 lJ.S.C. §§ l320b·7), including the stale-funded
state supplementary puyrnentprograms under Title XVI of the Act. The terms
and conditions of this CMPPA Agreement ensure that SSA makes such
disclosures of datn, lllld the State Agency uses such disclosed da!<1, in accordance
with the requirements of the Privacy Act of 1974, as amended by the Computer
Matching and Privacy Protection Act of 198&, 5 U.S.C. § S52a.
Under Section 1 l 3 7 of the Act, the State Agen.cy is required to use an income nncl
eligibility verification system t1~ administer specified federnlly fonded benefit
programs, including the state·funded state supplementary payment programs
under Titl.e XVI ()f U1e Act Tu assisl !lit: State Agemcy in determining en!illemclll
to and eligibility for benefits under those programs, a~ well as otl1er federally
funded benefit programs, SSA discloses certain data about applicuJ1ts of state
benefits .from SSA Privacy Act Syst<.'1.US of Records ("SORs") and verifies the
Social Security numbers ("SSN") of the applicants.
B. Legal Authority
SSA's authority to disclose da1a and the State Agency's authority to collect,
maintain, and use data. protected under SSA SO Rs for specified purposes is:
• Sections J 137, 453, and I 106(b) of the Acl (42 U.S.C. §§ I 320b·7, 653,
and J 306(h)) (income and eligibility verification data);
• 26 U.S.C. § 6103(1)(7) and (8) (tax return data);
~ Section 202(x)(3){B)(lv) of the Act.(42 U.S.C. § 40l(x)(3)(J:3)(1v))
(prisoner datu);
• Section 205(r)(J) of the Act ( 42, U.S.C. § 1H>:5(r)(3 )) and lbi:: lntelligence
Reform and Terrorism Prevention Act of2004, Pub. L. .!08-458,
§ 72 I 3(a)(2) (deaih dam);
• Sections 402, 412, 421, and 435 of Pub. L. 104-193 (8 U.S.C. §§ 1612,
l 622, 1631, and 1645) (quarters of cove.rage data);
• Children's Health lnsurunce Program Re-nuthorization Act of2009,
Pub. L. I I l-3 (c.itizenship data); and
Routine use exception to the Privacy Act, 5 U.S.C. § 5S2a(b)(3) (dnta
necessary 10 administer other prognu:ns t:ompaiible with SSA progrmn~)-
Exhibit B.2
Exhibit B.2
4
This CMPPA Agreement further carries out Section I l06(a) of the Ac1 (42 U.S.C.
§ 1306), the reg~tlalions promulgated pursuant to tha! section (20 C.F.l<.. Part 40 I),
the Privacy Act of 1974 (5 U.S.C. 552a), ns amended by the Compllter Matching
and Privacy Protection Act of 1988, related Office of Management and. Budget
("OMB'") guidelines, the Federal Information Security Manaeement Act of 7.002
("flSMA") ( 44 U.S.C. § 3541, et seq.), and related National !J1stitu1c of Standards
and Technology ("NIST") guidelines, which provide the requirements that the
State Agency must follow with regard to use, treatment, and safeguarding of data.
II. Scope
A. The State Agency will ensure that CHHS Dcpaii:ments using SSA data to
administer federally funded benefit pro.grams will comply with the tenm and
conditions of this CMPPA Agreement and the Privacy Act, as amended by the
Computer Matching and Privacy Protection Act. For the purpose of this ClvlPPA
Agreement, "CHI-JS Departments" do not include uny tribal entities recognized by
the l.J.S. Bureau ofindian Affairs.
B. Each CHHS Department that participates in data exchanges with SSA covered by
this CMPPA Agreement will execute one or more Infonnation Exchange
Agreements (''lEAs") wiih SSA, documenting additional terms and conditions
applieublc 10 those specific dntu exchanges, including the particular benefit
progrums administered by that CHHS Department, the data elements that wi II be
disclosed, and the data protection requirements implemented lo assist the CHHS
Dep<utment in the administration of those prognnns.
C. The State Agency, throLJgh its CHHS Deparuncnts, will use the SSA data
governed by this CMPPA Agreement to detemliue entitlement and eligibility of
it1dividuals for tho following programs:
l. Temporary Assistance to Needy Families ("Ti\NF'") program 1111.der Part A
of Title IV of the Act;
2. Medicaid provided under a State pl.an approved undcT Title XIX of the Act;
3. St.ate Children's Health 111~urnnce Program ("CHIP") under Title X.Xl of
the. Act:, as amended by rhe Children's Health lnsurance Program
Reauthorization Act of2009;
11. Food Stamp Program ("SNAP") under the Food Stamp Act of 1977
(7 U.S.C. § 201 J, ct seq.);
5. Women, .Tnfontli and Children Program ("WJC") under the Chlld Nutrition Acr
of 1966 (42 U.S.C. § 1771, et seq.);
6. Medicflre Savings Program ("MSP") under 42 lJ.S.C. § 1320b-14;
'l. Unemployment Compensation programs provided under a state: law deseribed
in Se{.-tion 3304 of thl'! Internal Revenue Code of I 954;
8. Low Income Heating and Enc.rgy Assistanc.e ("Lll-IEAP" or home energy
grams) program unde.r 42 U.S.C. § 8621;
9. State-administered supplementary payments of the type described in
Section 1616(a) of the Act;
l 0. Programs under a plan tq1proved under Titles l, X, X1V or XVI of the Act;
l I. Foster Care and Adoption A::isistance undc~r Title IV of the Act;
12. Child Support Enforcement programs under Scctio11 453 of the Act
(42 U.S.C. § 653);
13. Other upplicablc federally funded programs administered by CH.HS
Departments under Titles l, IV, X, XIV, XVJ, XVIU, XIX, XX and XX! of
the Act; and
14. Any other federally funded programs administered by CHHS Depurtrnents
and are compatible with. SSA's programs.
D. The State Agcmcy will ensure that SSA data disclosed for. the spcci lfo purpose of
administc1ing a particular fodera!Jy funde<l benefit program is used only to
administer tlrnt program.
UL Justification and gxpcded Results
A. Justification
This CMPPA Agreement und related data exchanges with CHHS Departments are
necessary for SSA w assi~hhc State Agency i.11 its administrutioH of federally
funded benefit progrums by providing the data required to accurntely determine
entitlement and eligibility of individuals for benefits provided tmdcr these
programs. SSA uses compurc1· technology to transfer the data because it is more
economical, efilcient, and foster than using mW1ual processes.
B. Expected Results
CHHS Departments will use the data provided by SSA to improve pllblic service
and prngnun efficiency and integrtly. The use of SSA data ¢xpedite~ t:hc
application process and ensmes thm. benefits are awarded only to applicants th~t
sa1isfy tbe Sta1e Agency's program crite1ia. A cost-benefit analysis for the
exchange made under this CMPPA Agreement is not required in accordanL:e with
the determination by the SSA Data Integrity Board ("DIB") to waive such
analysis pirrsuant to 5 U.S.C. § 552a(u)(4)(B).
IV. Record Description
A. Systems ofRccmds
SSA SO Rs used for pllrposcs of the suqjec'.t data cxchonges include:
• 60-005 8 --Master Files of SSN Holders and SSN Applications
(accessible through EVS, SVES, or Quarters of Coverage
Query data systems);
Exhibit B.2
• 60-0059 --Earnings Recording and Self-Employment Income System
(accessible through BEND EX, SVES or Quarters of Coverage
Query data systems);
• 60-0090 --Master Beneficiary Record (accessible through BENDEX or
SVES datu systems);
• 60-01 OJ --Supplemental Security Income Record (SSH) nnd Sp1:einl
Veterans Bc:.nefas (SVB) (ucccssible throngh SDX Dr SVES
data systems);
• 60-0269 --Prisoner Update Processing System (PUPS) (accessible through
SVES or Prisoner Query data systems).
• 60-0321 --Medicare Dutabase File
The State Agency will ensure that the tax return data contained. in SOR 60-0059
(Ea:mings Recording and Self-Employment Income System) will only be used in
accordance with 26 U.S. C. § 61 OJ.
B. Data Elements
Data elements disclosed in computer matching governed by !his CMPPA
Agreement arc Personally Identifiable Information ("PU") from specified SSA
SORs, including names, SSNs, addresses, amounts, and other information related
to SSA benefits, and earnings information. Specific listings of data elements are
available at:
C. Number of Records [nvolvcd
Exhibit B.2
6
The number ofrewrds for each program covered under lhis CM.PP!\ Agreement
is equal to the number of Title fl, Title XVI, or Title XVI!l recipients resident in
the Stnte as recorded in SSA's AnnunJ Statistical Supplement found on Internet at:
·n1is number will fluctuate during the term of this CM PP A Agreement,
corre.~ponding to 1hc number of Title II, Title XVI, rind Title XVflJ recipients
added to or deleted from SSA d1:1tabnscs during the tcm1 of thi~• CMPPA
Agr1;crnenl.
V. Notice nnd Opportunity to Contest Pr<>1.~edures
A. Notice to Applicmlts
CHHS Departments will notify all individuals who l1pply for federally funded,
stale·administered bt~ne'fits under the Act thut any data they provide is sul:iecl to
verification through computer matching with SS/\. CHHS Departmerns and SS/I.
will provide such notice through approptiatc Jm1guage printed on application
forms or separate handouts.
B. Notice to BeneficiariesfRecipients/ Annuitants
Exhibit B.2
CI-1HS Departments will prnvide 11olice to beneficiaries, recipients, and annuitants
under the programs covered by this CMPP A Agreement informing them of
ongoing compuk"I m~tching with SSA. SSA will provide such nol"ice through
publication in the Federal Register ru1d periodic mailings to all beneficiaries,
recipients, and annuiwnts describing SSA's matching activities.
C. Opportunity to Contest
CHHS Departments will nol terminate, suspend, reduce, d<.:ny, or lake other
adverse nction against an applicarit for or rccipienr of federnJJy fw1dc:.c\ state-
adrninistercd ·benefits btised on data disclosed by SSA from its SORs \lntil the
individual is notified in v.Ti ting of the potential adverse ae1ion and provided an
opportunity to contest the planned action. "Adverse action" means <ll1Y action that
results in a teliIJination, suspension, reduction, or final denial of eligibility,
payment, or benefit. Such notices will:
I. I.nfonn the individual of the match findJngs and the opportunity to contes(
these findings;
2. Give the individual until the expiration of any time period established for the
rel.evnnt progcam by a. statute or regulation for the [ndiv1dL1E1l to 1·espond le
the notice. If no such t1me p<.:riod is established by a s(i:tl.uti:. or regulation ior
the program. a 30-day period will be prnvidi;:d. The tinie pc1iod begins 011
the date on which notice is mailed or otherwise provided to the individual w
respond; and
3. Clearly state that, unless the individual responds to the notice in the required
Lim<: period, the CHHS Department will conclude that the SSA data i~
com:ct and will effectuate th;,; threatened action or otherwise make the
necessary adjustment to ihe individual's benefit or entitlcrmint.
VL Records Accuracy Assessment .an.cl Verification Procedures
CHHS Departments may use· SSA's benefit data without independcnl verification.
SSA has independently assessed the accuracy of its benefits data to be more than 99'X,
accurate when they are created.
Prisoner and death data, some of which is not independently verified by SSA, does
not have the same degree of accuracy as SSA's benefit data. "fberefore, CHHS
Departments must indcpcndcntiy verify this daLU through applicable Agenc.v
verification procedures und the notice and opportunity to contest procedW'cs specified
in Section V. ofthis CMPPA .Agreement before tu king any adverse action againsl nny
individuol.
SSA's citizenship data may be less than 50 percent current. Applicants for SSNs
report th~ir citizenship status at the 1.ime they apply for their SSNs. T1iere is no
obliga(ion for a11 individual io report lo SSA a change in his or her immigration siatu~
until he or she files a claim for benefits.
VII. Disposition and Records Retention of Matched hems
A. CHHS Departments receiving data from SSA to administer programs governed by
this Cl\.iPPA Agreement will retain all such data only for the required prncessing
limes for lhe applicable federally funded benefit programs and will tht.11 <.blroy
1111 such daiu.
B. CHHS Departments may retain SSA data in hardcopy to meet evidentiury
requirenients, provided that they re1ire such data in accordance with applicable
state laws governing CHHS Departments' retention of records.
Exhibit B.2
C. CHHS Departments may use arJy accretions, deletions, or changes to the SSA data
governed by this CMPP A Agreement to update lheir master files of federully
fundc.d statu-administered benefit program upplicm1ts and re-cipienls, which will
be retained in accordance with applicable state laws governing CHl!S
Departments' retcnti.ori of records.
D. CHHS Departments may nol create separate files or records comprised soleiy of
the data provided by SSA to administer prngrnms governed by this CfvfPPA
Agreement.
F SSA will delete electronic data input files received frmn Cffi-lS Departments aft.er
it processes the applicable match. SSA will retire its data in accordance with the
Federal Records Retention Schedule (44 U.S.C. § 3303a).
VIIT. Security Proccdurc:s
1he State Agency will ensure that CHHS Depurtments using SSA data comply wi·th
the security and safeguarding reqi.1irernents of the Plivncy Act, as amended hy tho
Computer Matchi.ng and Privacy Protection Act, relatl.'!d OMB guideline~, the
Federal Infomrntion Security Management Act of 2002, and related NIST guidelines.
Jn uddition, CHHS Departments using SSA data will have in plllce administrative,
technical, and physical safeguards for the matched. data and rc\su.lts of such matche~>
Additional administrative, techniCt)l, and physical security requirements governing
all data SSA provides electronically to CHHS Dcpartm~nt~, including specific
guidance on safeguarding and reporting responsibilities for PII, are set fo1th in the
IE As.
lX. Records Usage, Duplication, and Rcdisclosurc RestrictiorJs
A. cm:is Dcpartrnents will use and access SSA data and the record'.; created using
that data only for the purpose of verifying eligibility for the ~pecific fcdernlty
funded benefit programs identified in the JEA.
J3. CHHS Departments will comply with the following lirnittitions on USl\
duplication, und redisclosure of SSA dma:
1. CHI-IS Departments will not use or redisclose the data disclosed by SSA for
any purpose other than to determine eligibility for, or the amount oi: benefits
under the state-administered income/health mai11tenance programs ide.nlificr]
in this CMPPA Agreement.
9
2. CJ-JHS Departments will not use the data disclosed by SSA io exlrnct
infonnation concerning individuals who ar1;J nt:ither applicants for, nor
rcci1iients ot; benefits \l!ldcr the state-administered incmne/heallh maintenance
program Identified in this CMPPA Agreement.
3. CHHS Departments will use the tax rctum data disclosed by SSA ouly tn
dcte1minc individual eligibi.lity for, or the amount ot~ assistance under a state
plan pursuant to Section 1137 programs and child support enforcement.
programs in accordance with 26 lJ .S.C. § 6103( l )(8). Contractors and agents
actiJig on behalf of the State Agency or a CJIHS Department will only huve
access to tax rerurn data where specifically uulhurit.ed by 26 U.S.C. § 6 l Ol
4. CHHS Departments wi.ll use the citizenship status dala disclosed by SSA
under the Children's 1-leulth lnsuram:e Progrmn R~m1tborizution Act of 2009,
Pub. L. 11 l-J, only for tbe purpose of detcnnining entille111ent to Medicaid
and CHIP pr:ogmm for new applicants.
5. CHHS Departments will restrict access to the data disclosed by SSA lo only
those authorized State employees, contr'ctctors, and a.gents who need such data
to perform their official duties in connection with the purposes i.dentified in
this CMPP A Agreement.
6. CHHS Departments will enter into a vvriltcn agreement with em;h or their
contractors and agents who need SSA data to perform their official duties
whereby such contraclor or agent agrees l.o abide by all relevant federal lnws,
restrictions on access, use, and disclosure, and security rcquin~ments in this
CMPPA Agrccmeni. CHHS Dcpurtments will provide their l~onrructors aml
agenis with copies of this CMPPA /\gre~mient, related IEAs, and all related
uttachroents before initial disclosure of SSA data to such contractors and
agents. Prior to signing this CMPPA Agreement, and thereafter at SSA's
request, each CHHS Department will obtain from its contractors and agents a
Exhibit B.2
cuLTenl list of the employees of such contractors and agenrs with access Lo
SSA data and provide such lists to SSA.
7. CHHS Departments' employees, con1ractor8, and agents who access, use, or
disclose SSA data in a manner or purpose not authorized by this CMPP A
Agrecm.ent may be subject to civ.il and criminal sam.i:ion~ pursuant to
applicable federal statutes.
Exhibit B.2
10
C. CHHS Depa.iiments will not duplicate in a separate file or disseminate, without
prior written permission from SSA, the <lu!a governed by this CMPPA /\greemenl
for any pu1vose othei' than to determine entitlement or eligibility to federally
fu.nd.ed benefits. A CHHS Department proposing the redisclosnre mtl:->1 specify in
writing to SSA what dt~ta is being disclosed, 10 whom, and the 1-c11sorn; th11t justify
the redisclosure. SSA will not give permission for such rcdisdosurc unless 1)l(:,
redisclosure is required by law or essential to the conduct of the matching
pmgrnm and authorized under a routine use,
X. Com(ttroller General Access
The Comptroller General (the Government Accountability Office) may have access
to all records of the State Agency and its CHHS Depanments that the Comptroller
General deem.q necessary to monitor und verify compliance with this CMPPA
Agreement in accordance with 5 U.S.C. § 552u(o)(l)(K).
XI. Duration, Modification, and Tcnniuatiou of the Agreement
A. Duration
1. This CMPPA Agreement is effective from January I, 2010 ("Effective
Date") through June 30, 2011 ("Expiration Dale").
2. In accordance with the CMPPA, SSA will: (a) publish a Computer
Matching Notice rr1 the Federal RcgiS1er at lcnst 30 days prior to the
Effective D<Ue; (b) send re.quired notices to the Congressional conunittet~s of
ju1isdiction under 5 U,S,C. § 552a(o)(2}(A)(i) at least 40 days prior to the
Effective Date; and (c) send the required report to the OMB al lt:ast 40 days
prior to the Effective Dute.
3. Within 3 months prior the Expiration Date, the SSA DIB may, without
additional review, renew this CMPPA Agreement fi:>r a, period not to exceed
12 months, pmsuant to 5 U.S.C. § S52a(o)(2)(D), if:
the applicable data exchm1ge will continue without any chrrnge; and
SSA and !he Stale Agency certify to the DfB in writing that tbe
applicable data cxchnngc has been conducted in compliance with this
CMPPA Agreement.
Exhibit B.2
II
4. If either SSA or the Stale Agency does noi Vvish to renew this CM PP A
Agreement, it must notify the other pmty of its intent not to renew at least J
months prior to lhe Expiration Dute.
B. Modification
Any modification to this CMPPA Agreement must bt: in Y.'Titing, signed by both
panies and approved by 1he SSA DIB.
C. Termination
TI1e partic.s may tem1inate this CMPPA Agreement at any time upon mutual
wTiHen consent of both parties.· Either party may unilaterally tenninate this
CMPPA Agreement upon 90 days advance written notice to the or.her party; such
unilatcrnl tennination will be effective 90 days after the date of tht• notice, or at u
later date specified in the 1101.ice.
SSA muy immediately mid unilan:rally suspend Lhe data flow or tcnninate this
CMPPA Agreement if SSA determines, in its sole discretion, 1hat the State
Agency or a CHHS Department has violated or foiled to comply with thi.s
CMPPA Agreement.
XlI. Reimbursement
In accotdance with Section l 106(b} of the Social Secu1ity Ac.:t, tbc Cumrnissioncr of
SSA has determined not to charge the State Agency and CHHS Departrm:nts the
costs of.furnishing the elet:tronie data from the SSA SOR.~ under this CMPP/\
Agreement.
XIII. Disd11imer
SSA is not liable for any datnages or loss resulting from errors in the data provided
to CHHS DepartmentN under any JEA'i governed by this CMPP A Agreement
Funhcrmore, SSA is not liable for any damage.~ or loss resulting from the dcstrnction
of any materials or data provided by CHHS Departments.
XIV. Points of Contact
A. SSA Point of Contact
Regional Office
Martin White, Director
San Francisco Regional Offkc, Center for Programs Support
1221 Nevin Avenue
Richmond, California 94801
Phone: (510) 970-8243/Fax: (510) 970-8101
Ma.l'tin. White(@ssa.gov
B. State Agency Point of Contact
Lorna Fong, Assistant Secretary
California Health nnd Human Services Agency
1600 9th Street. Room 460
Sacramento, CA 958 l 4
(916) 651-8058/Fax: (916) 440-5004
lfong@chhs.ca.gov
Exhibit B.2
12
Exhibit B.2
JJ
XV. SSA Aul·borizcd Siguaturc and Datil Integrity Board Approval
TI11: sigrrnl"liry below wllfrants and represents that he or she has the c.ompctcnt authority
on behalf of SSA to enter into the obHgations set forth in this CMPPA Agreement.
SOCIAL SECURITY Ai>MiNISTRA TiON
,-yvr ~ /J k!.::r--
Michad G. Gallagher
Assrstanl Deputy Comrni$sioner
for Budget. Finance i:lnd Managcm-ent
J:/'{ /1::~1
I certify that the SSA Data f ntegrity Soard approved this CMPP A Agreement.
l/Ml{;fj
Chairperson ·
SSA Data Integity Board
-'Sf 1 :JI o ' Dn:te
XVL Regional and State Agency Signaiul'es
SOCIAL SECURITY ADMINISTRATION
(~J.-r· ~_:n._ . . --------
Peter I). Spencer
Regional Commissio er
San Francisco
--<f-//J-)_!2?-.-------····----······----·-~ Date
CALJFORi'lIA l:lEALTH AND HUMAN s1mv1c1i:s AGENCY
The s)gnatory below warrants and represents tha1 he or she has the co1npeton1
autl1ority on behalf of the State Agency to enter into the obligaiiQ11s set forth in this
CMPPA Agreement. 'The signator>' below further acknowledges and agrees lhat,_by
his or her signature below, he or she represents CHHS Departmenls and is du!)'
authorized to enter into the obligations sot forth in this CMPPA Agreement ou behalf
of those CHHS Deportments.
Kimberly Oelshc, Secretary
California Health and Human Services Agency
·-----~~-~Q~Q~---·--·------·--·--·-Oate
Exhibit B.2
Agreement 09-6008 A-1
CDSS/SSA
Exhibit B.2
IEA-F
Attachment 1-A
Page 1 of 3
RECERTIFICATION OF THE COMPUTER MATCHING AGREEMENT
BETWEEN
THE SOCIAL S~:Cl.JRJTY ADMJNISTRA TION (SSA)
AND
THE CALIFORNIA HEAL TH AND HUMAN SERVICES AGENCY
(STATE AGENCY)
SSA Match #6000
Under the provisions of the Privacy Act of 1974, amended by the Computer Matching and
Privacy Protection Act of l 988, 5 U.S.C. § 552a(o)(2), a computer matching agreement will
remain in effect for a period not to exceed 18 months. Within 3 months prior to the expiration of
such computer matching agreement. however, the Data Integrity Board (DIB) niay, without
additional. review, renew the oom:puter matching agreenient for a current, ongoing matching
prDgram for a period not to exceed l2 additional months if:
I. such program will be conducted without any changes; and
2. eacl1 party to the agreement certifies to the DlB in \.vriting that the program has been
conducted in compliance with the agreement.
The foflowing match meets the conditions for renewal by this recertification:
r. TITLE .. OF MATCH:
Computer Matching and Privacy Protection Act Agreement Between the Social Security
Administration and the California Health and Human Services Agency (Match #6000)
II. PARTIES TO THE MATCH:
Recipient Agency: California Health and Human Services Agency (State Agency)
Source Agency: Social Security Administration (SSA)
This Computer Matching and Privacy Protection Act (CMPPA) Agreement between SSA
and the California Health and Human Services Agency ("State Agency"), sets forth the
tenns and conditions governing disclosures of records; information, or data (l1ere·in
''data") made by SSA to various depruiments, boards, and other organiza6ons under the
jurisdiction of the State Agency ("CHHS Department-s") that administer federally funded
benefit program under various provisions of the Social Security Act ("Act''}; such as
Secrion 1137 (42 U.S.C §§ l320b-7)~ including the state.-funded state supplementary
payment programs under Title XVI .of the Act. Under Section 1137 of the Act, lhe State
Agency is required to use an income and eligibility verification system to administer
specified federally funded benefit programs, including the state-funded state
supplementary payment programs under Title XVI of the Act. To assist the State in
det:cnnining entitlement to and eligibility for benefits under those programs, as well as
I ~ Agreement 09-6008 A-1
CDSS/SSA
Exhibit B.2 IEA-F
Attachment 1-A
Page 2 of 3
other federally funded benefit programs, SSA discloses certain data about applicants of
state benefits from SSA Privacy Act Systems of Records (SORS) and verifies the Social
Security Numbers (SSN} of the applicants.
· rv. ORJGINAL EFFECTIVE AND EXPIRATION DATES OF THE MATCH:
Effective Date: January l, 20 l 0
June 30, 2011 Expiration Date:
V. RENEWAL AND NEW EXPIRATION DATES:
Renewal Date: June 30, 201 l
New Expiration Date: June 30, 2012
Vl. CHANGES
By this recertification, SSA and the State make the foHowing non-substantive changes tn
the computer matching agreement:
In Article XIV, "Points of Contact," infonnation under subsection B.,"
State Agency Point of Contact,'' should be deleted in its entirety and replaced with the
following:
Sonia Herrera
California Health and Human Services Agency
1600 9th Street
Sacramento, CA 95814
(916) 651-8058
sherrera@chhs.ca. gov
Social Security Administra.tion
Source Agency. Certification:
As the authorized representative of the source agency named above, I certify that: ( 1) the
subject matching program has been conducted in compliance \Vith the existing computer
matching agreement betV.:een the parties~ and (2) the subject matching program will be
conducted without any change for an additional 12 months, subject to tbe approval of the
Data Integrity Boards.
e er D .. Spencer
Regional Commiss1 ner
San Francisco
Date <./ f !ct/ /t
Agreement 09-6008 A-1
CDSS/SSA
Data Integrity Board Certification:
Exhibit B.2
IEA-F
Attachment 1-A .
Page 3 of 3
As Chair of the Data IntegriiyBoard of the source agen~y named above, r certify that:
(1) the subject matching program has been conducted in compliance with the existing
computer matching agreement bet\<Veen. the parti:es; aud (2)the subject matching program
wil.I be conducted without any change for an additional 12 months.
Dan1el F. Callahan, Chair
Data Integrity Board
Dmc.~_1_._-;2._-_;_,_J..,~0_1_J~~~~~~
California Health and Human Services Agency
Recipient A12encv Certification:
As the authorized representative of the recipient agency named above, I certify that:
(1) the subject matcMng program has been conducted in compliance with the existing
computer matching agreemenrbetween the parties; and (2} the subject matching program
will be conducted without any change for an additional 12 months, subject to the
approval of the Data Integrity Boards of the Social Security Administration.
Diana S. Dooley, Secretary
California Healtl1 and Human.
Date~ I~, ~/I
Exhibit B.2
ATTACHMENT 2
AUTHORIZED DATA EXCHANGE SYSTEM(S)
Agreement 09-6008
COSS/SSA
Autho.-ized Data Exchange System(s)
Page 1 5r~ibit s.2
IEA-F
Attachment 2
BEER (Beneficiary Earnings Exchange Record}: Employer data for the last calendar year.
BENDEX (Beneficiary and Earnings Data Exchange): Primary source for Title II eligibility,
benefit and demographic data.
LIS (Low-Income Subsidy): Data from lhc Low-Income Subsidy Application for Medicare Part
D beneficia1ies --used for Medicare Savings Programs (MSP).
Medicare 1144 (Outreach): Lists of individuals on SSA roles, who may be eligible for medical
assistance for: payment of the cost of Medicare cost-sharing under the Medicaid program
pursuant to Sections l 902(a)( l O)(E) and 1933 of the Act; transitional assistance under Section
l 860D-3 I (f) of the Act; or premiums and cost-sharing subsidies for low-income individuals
under Section l 860D-J 4 of the Act.
PUPS (Prisoner Update Processing System): Confinement data received from over 2000 state
and local institutions (such as jails, prisons, or other penal institutions or correctional facilities) --
PUPS matches the received data with the MBR and SSR benefit data and generates alerts for
review/action.
QUARTERS 01~ COVERAGE (QC): Quarters of Coverage data as assigned and described
under Title II of the Act --The tenn "quarters of coverage" is also referred to as "credits" or
"Social Security credits" in various SSA public infonnation documents, as well as to refer lo
"qualifying quarters" to dete1mine entitlement to receive Food Stamps.
SDX (SSI State Data Exchange): Primary source of Title XVI eligibility, benefit and
demographic data as well as data for Title VIII Special Veterans Benefits (SVB).
SOLQ/SOLQ-1 (State On-line Query/State On"line Query-Internet): A real-time online
system that provides SSN verification and MBR and SSR benefit data similar to duta provided
through SVES.
Exhibit B.2
Attachment 2
SVES (State Verification and Exchange System): A batch system that provides SSN
verification, MBR benefit information, and SSR information through a unifonn data
response based on authorized user-initiated queries. The SVES types are divided into
five different responses as follows:
SVES I:
SVES I/Citizenship*
SVl~S U:
SVES HI:
SVES IV:
This batch provides strictly SSN verification.
This batch provides strictly SSN verification and
citizenship data.
This batch provides strictly SSN verification and
MBR benefit information
This batch provides strictly SSN ve1ification and
SSR/SVB.
This batch provides SSN verification, MBR benefit
information, and SSR/SVB infonnation, which
represents all available S YES data.
*Citizenship status data disclosed by SSA under the Children's Healt/1 Insurance
Program Reauthorization Act of 2009, Pub. L. 111-3 is only for the purpose of
determining entitlement to Medicaid and CHIP program for new applicants.
2
Exhibit B.2
ATTACHMENT 3 OMITTED
Exhibit B.2
ATTACHMENT 4
ELECTRONIC INFORMATION EXCHANGE SECURITY
REQUIREMENTS AND PROCEDURES
Exhibit B.2
ELECTRONIC INFORMATION EXCHANGE
SECURITY REQUIREMENTS AND PROCEDURES
FOR
STATE AND LOCAL AGENCIES EXCHANGING
ELECTRONIC INFORMATION WITH THE SOCIAL
SECURITY ADMINISTRATION
SENSITIVE DOCUMENT
VERSION 6.0.2
April 2014
1
Table of Contents
1. Introdyctjon
2. Electronic Informatjon Exchange Definjtjon
3. Roles and Responsjbilitjes ·
4. General Systems Secyrjty Standards
5. Systems Security Regyjrements
5.1 Overyjew
5.2 General System Security oesjgn and Operating Enyironment
5.3 System Access Control
5.4 Automated Aydit Trail
5.5 personally Identifiable Informatjon
5.6 Monjtorjng and Anomaly petectjon
5.7 Management Oversjgbt and Qualjty Assurance
5.8 pata and Commynjcations Secyrjty
5.9 Incident Reporting
5.10 Securjty Awareness and Employee Sanctions
5.11 Contractors of Electronic Informatjon Exchange partners
6. General--Securjty Certificatjon and Compliance Reyjew programs
6.1 The Secyrjty Certificatjon program
6.2 pocymenting Secyrjty Controls in the Secyrjty pesjgn plan
6.2.1 When the spp and Rjsk A55essment are Regyjred
6.3 The Certification process
6.4 The Compliance Reyjew program and prpcess
6.5.1 EIEP Compliance Reyjew particjpatjon
6.5.2 yerjficatjon of Aydjt Samples
6.6 Scheduling the Oosjte Reyjew
7. Addjtjonal petjnjtjons
8. Regulatory References
9. Fregyently Asked Oyestjons
10. Diagrams
Flow Chart of the OIS Certification process
Flow Chart of the OIS Compliance R¢yjew process
Comp!jance Revjew pecjsjon Matrjx
2
Exhibit B.2
RECEIVING ELECTRONIC INFORMATION FROM THE
SOCIAL SECURITY ADMINISTRATION
1. Introduction 0
Exhibit B.2
The law requires the Social Security Administration (SSA) to maintain oversight and assure the
protection of information it provides to its Electronic Information Exchange Partners (EIEP). EIEPs
are entities that have information exchange agreements with SSA.
The overall aim of this document is twofold. First, to ensure that SSA can properly certify EIEPs as
compliant by the SSA security requirements, standards, and procedures expressed in this document
before we grant access to SSA information in a production environment. Second, to ensure that
EIEPs continue to adequately safeguard electronic information provided to them by SSA.
This document (which SSA considers SENSITIVE 1 and should only be shared with those who need it
to ensure SSA-provided information is safeguarded), describes the security requirements, standards,
and procedures EIEPs must meet and implement to obtain information from SSA electronically. This
document helps EIEPs understand criteria that SSA uses when evaluating and certifying the system
design and security features used for electronic access to SSA-provided information.
The addition, elimination, and modification of security control factors determine which level of
security and due diligence SSA requires for the EIEP to mitigate risks. The emergence of new
threats, attack methods, and the availability of new technology warrants frequent reviews and
revisions to our System Security Requirements (SSR). Consequently, EIEPs should expect SSA's
System Security Requirements to evolve in concert with the industry.
EIEPs must comply with SSA's most current SSRs to gain access to SSA-provided data. SSA will
work with its partners to resolve deficiencies that occur subsequent to, and after, approval for access
if updates to our security requirements cause an agency to be uncompliant. EIEPs may proactively
ensure their ongoing compliance with the SSRs by periodically requesting the most current SSR
package from their SSA contact. Making periodic adjustments is often necessary.
2. Electronic Information Exchange Definition 0
For discussion purposes herein, Electronic Information Exchange (EIE) is any electronic process in
which SSA discloses information under its control to any third party for any purpose, without the
specific consent of the subject individual or agent acting on his or her behalf. EIE involves
individual data transactions and data files processed within the systems of parties to electronic
information sharing agreements with SSA. These processes include direct terminal access or OTA
to SSA systems, batch processing, and variations thereof (e.g., online query) regardless of the
systematic method used to accomplish the activity or to interconnect SSA with the EIEP.
1 Sensitive data -"any information, the loss, misuse, or unauthorized access to or modification of which could adversely affect the
national interest or the conduct of Federal programs, or the privacy to which individuals are entitled under 5 U .S .C. Section 552a
(The Privacy Act), but that has riot been specifically authorized under criteria established by an Executive Order or an Act of
Congress to be kept classified in the interest of national defense or foreign policy but is to be protected in accordance with the
requirements of the Computer Security Act of 1987 (P.L.100-235)."
3
Exhibit B.2
3. Roles and Responsibilities
The SSA Office of Information Security (OIS) has agency-wide responsibility for interpreting,
developing, and implementing security policy; providing security and integrity review
requirements for all major SSA systems; managing SSA's fraud monitoring and reporting
activities; developing and disseminating security training and awareness materials; and
providing consultation and support for a variety of agency initiatives. SSA's security reviews
ensure that external systems receiving information from SSA are secure and operate in a
manner consistent with SSA's Information Technology (IT) security policies and in compliance
with the terms of electronic information sharing agreements executed by SSA with outside
entities. Within the context of SSA's security policies and the terms of electronic information
sharing agreements with SSA's EIEPs, OIS exclusively conducts and brings to closure initial
security certifications and periodic security compliance reviews of EIEPs that process, maintain,
transmit, or store SSA-provided information in accordance with pertinent Federal requirements
which include the following (see also Requlatorv References):
a. The Federal Information Security Management Act (FISMA) requires the protection of
"Federal information in contractor systems, including those systems operated by state and
local governments."
b. The Social Security Administration requires EIEPs to adhere to the policies, standards,
procedures, and directives published in this Systems Security Requirements (SSR)
document.
Personally Identifiable Information (PII), covered under several Federal laws and statutes, is
information about an individual including, but not limited to, personal identifying information
including the Social Security Number (SSN).
The data (last 4 digits of the SSN) that SSA provides to its EIEPs for purposes of the Help
America Vote Act (HAVA) does not identify a specific individual; therefore, is not "PII" as
defined by the Act.
However, SSA is diligent in discharging its responsibility for establishing appropriate
administrative, technical, and physical safeguards to ensure the security, confidentiality, and
availability of its records and to protect against any anticipated threats or hazards to their
security or integrity.
NOTE: Disclosure of Federal Tax Information (FTI) is limited to certain Federal
agencies and state programs supported by federal statutes under Sections 1137,
453, and 1106 of the Social Security Act. For information regarding safeguards for
protecting FTI, consult IRS Publication 1075, Tax Information Security Guidelines
for Federal, State, and Local Agencies.
The SSA Regional Data Exchange Coordinators (DECs) serve as a bridge between SSA and
state EIEPs. In the security arena, DECs assist OIS in coordinating data exchange security
review activities with state and local EIEPs; e.g., they provide points of contact with state
agencies, assist in setting up security reviews, etc. DECs are also the first points of contact
for states if an employee of a state agency or an employee of a state agency's contractor or
4
Exhibit B.2
agent becomes aware of a suspected or actual loss of SSA-provided Personally Identifiable
Information (PII).
4. General Systems Security Standards 0
EIEPs that request and receive information electronically from SSA must comply with the
following general systems security standards concerning access to and control of SSA-
provided information.
NOTE: EIEPs may not create separate files or records comprised solely of the
information provided by SSA.
a. EIEPs must ensure that means, methods, and technology used to process, maintain,
transmit, or store SSA-provided information neither prevents nor impedes the EIEP"s
ability to
• safeguard the information in conformance with SSA requirements,
• efficiently investigate fraud, data breaches, or security events that involve
SSA-provided information, or
• detect instances of misuse or abuse of SSA-provided information
For example, utilization of cloud computing may have the potential to
jeopardize an EIEP's compliance with the terms of their agreement or SSA's
associated system security requirements and procedures.
b. EIEPs must use the electronic connection established between the EIEP and SSA
only in support of the current agreement(s) between the EIEP and SSA.
c. EIEPs must use the software and/or devices provided to the EIEP only in support of
the current agreement(s) between the EIEP and SSA.
d. SSA prohibits modifying any software or devices provided to the EIEPs by SSA.
e. EIEPs must ensure that SSA-provided information is not processed, maintained,
transmitted, or stored in or by means of data communications channels, electronic
devices, computers, or computer networks located in geographic or virtual areas not
subject to U.S. law.
f. EIEPs must restrict access to the information to authorized users who need it to
perform their official duties.
NOTE: Contractors and agents (hereafter referred to as contractors) of the
EIEP who process, maintain, transmit, or store SSA-provided information are
held to the same security requirements as employees of the EIEP. Refer to the
section Contractors of Electronjc lnformatjqn Exchange Partners in the Systems
Securjty Requirements for additional information.
g. EIEPs must store information received from SSA in a manner that, at all times, is
physically and electronically secure from access by unauthorized persons.
5
Exhibit B.2
h. The EIEP must process SSA-provided information under the immediate supervision
and control of authorized personnel.
i. EIEPs must employ both physical and technological safeguards to prevent
unauthorized retrieval of SSA-provided information via computer, remote terminal,
or other means.
j. EIEPs must have formal PII incident response procedures. When faced with a
security incident caused by malware, unauthorized access, software issues, or acts
of nature, the EIEP must be able to respond in a manner that protects SSA-provided
information affected by the incident.
k. EIEPs must have an active and robust employee security awareness program, which
is mandatory for all employees who access SSA-provided information.
I. EIEPs must advise employees with access to SSA-provided information of the
confidential nature of the information, the safeguards required to protect the
information, and the civil and criminal sanctions for non-compliance contained in
the applicable Federal and state laws.
m. At its discretion, SSA or its designee must have the option to conduct onsite
security reviews or make other provisions to ensure that EIEPs maintain adequate
security controls to safeguard the information we provide.
5. Systems Security Requirements 0
5.1 Overview 0
SSA must certify that the EIEP has implemented controls that meet the requirements and
work as intended, before we will authorize initiating transactions to and from SSA
through batch data exchange processes or online processes such as State Online Query
(SOLQ} or Internet SOLQ (SOLQ-1).
The Technical Systems Security Requirements (TSSRs) address management,
operational, and technical aspects of security safeguards to ensure only the authorized
disclosure and use of SSA-provided information by SSA's EIEPs.
SSA recommends that the EIEP develop and publish a comprehensive Systems Security
Policy document that specifically addresses:
• the classification of information processed and stored within the network,
• administrative controls to protect the information stored and processed within the
network,
• access to the various systems and subsystems within the network,
• Security Awareness Training,
o Employee Sanctions Policy,
6
Exhibit B.2
• Incident Response Policy, and
• the disposal of protected information and sensitive documents derived from the
system or subsystems on the network.
SSA's systems security requirements represent the current state-of-the-practice security
controls, safeguards, and countermeasures required for Federal information systems by
Federal regulations, statutes, standards, and guidelines. Additionally, SSA's systems
security requirements also include organizationally defined interpretations, policies, and
procedures mandated by the authority of the Commissioner of Social Security in areas
when or where other cited authorities may be silent or non-specific.
5.2 General System Security Design and Operating Environment 0
EIEPs must provide descriptions and explanations of their overall system design,
configuration, security features, and operational environment and include explanations of
how they conform to SSA's requirements. Explanations must include the following:
o Descriptions of the operating environment(s) in which the EIEP will utilize, maintain,
and transmit SSA-provided information
o Descriptions of the business process( es) in which the EIEP will use SSA-provided
information
o Descriptions of the physical safeguards employed to ensure that unauthorized
personnel cannot access SSA-provided information and details of how the EIEP keeps
audit information pertaining to the use and access to SSA-provided information and
associated applications readily available
o Descriptions of electronic safeguards, methods, and procedures for protecting the
EIEP's network infrastructure and for protecting SSA-provided information while in
transit, in use within a process or application, and at rest (stored or not in use)
o Descriptions of how the EIEP prevents unauthorized retrieval of SSA-provided
information by computer, remote terminal, or other means, including descriptions of
security software other than access control software (e.g., security patch and anti-
malware software installation and maintenance, etc.)
o Descriptions of how the configurations of devices (e.g., servers, workstations, and
portable devices) involving SSA-provided information comply with recognized industry
standards and SSA's system security requirements
o Description of how the EIEP implements adequate security controls (e.g., passwords
enforcing sufficient construction strength to defeat or minimize risk-based identified
vulnerabilities)
7
Exhibit B.2
5.3 System Access Control
EIEPs must utilize and maintain technological (logical) access controls that limit access to
SSA-provided information and associated transactions and functions to only those users,
processes acting on behalf of authorized users, or devices (including other information
systems) authorized for such access based on their official duties or purpose(s). EIEPs
must employ a recognized user access security software package (e.g. RAC-F, ACF-2,
TOP SECRET) or a security software design which is equivalent to such products. The
access control software must utilize personal identification numbers (PIN) and passwords
or Biometric identifiers in combination with the user's system identification code (userID).
The access control software must employ and enforce (1) PIN/password, and/or (2)
PIN/biometric identifier, and/or (3) SmartCard/biometric identifier, etc., for
authenticating users).
Depending on the computing platform (e.g., client/server (PC), mainframe) and the
access software implementation, the terms "PIN" and "user system identification code
(userID)" may be, for practical purposes, synonymous. For example, the PIN/password
combination may be required for access to an individual's PC after which, the
userID/password combination may be required for access to a mainframe application. A
biometric identifier may supplant one element in the pair of those combinations. SSA
strongly recommends Two-Factor Authentication.
The EIEP's implementation of the control software must comply with recognized industry
standards. Password policies should enforce sufficient construction strength (length and
complexity) to defeat or minimize risk-based identified vulnerabilities and ensure
limitations for password repetition. Technical controls should enforce periodic password
changes based on a risk-based standard (e.g., maximum password age of 90 days,
minimum password age of 3 - 7 days) and enforce automatic disabling of user accounts
that have been inactive for a specified period of time (e.g., 90 days).
The EIEP's password policies must also require more stringent password construction
(e.g., passwords greater than eight characters in length requiring upper and lower case
letters, numbers, and special characters; password phrases) for the user accounts of
persons, processes, or devices whose functions require access privileges in excess of
those of ordinary users.
EIEPs must have management control and oversight of the function of authorizing
individual user access to SSA-provided information and to oversee the process of issuing
and managing access control PINs, passwords, biometric identifiers, etc. for access to the
EIEP's system.
The EIEP's systems access rules must cover least privilege and individual accountability.
The EIEP's rules should include procedures for access to sensitive information and
transactions and functions related to it. Procedures should include control of transactions
by permissions module, the assignment and limitation of system privileges, disabling
accounts of separated employees (e.g., within 24 hours), individual accountability, work
at home, dial-up access, and connecting to the Internet.
8
Exhibit B.2
5.4 Automated Audit Trail
SSA requires EIEPs to implement and maintain a fully automated audit trail system
(ATS). The system must be capable of creating, storing, protecting, and efficiently
retrieving and collecting records identifying the individual user who initiates a request for
information from SSA or accesses SSA-provided information. At a minimum, individual
audit trail records must contain the data needed (including date and time stamps) to
associate each query transaction or access to SSA-provided information with its initiator,
their action, if any, and the relevant business purpose/process (e.g., SSN verification for
Medicaid). Each entry in the audit file must be stored as a separate record, not overlaid
by subsequent records. The Audit Trail System must create transaction files to capture
all input from interactive internet applications which access or query SSA-provided
information.
If a State Transmission Component (STC) handles and audits the EIEP's transactions with
SSA, the EIEP is responsible for ensuring that the STC's audit capabilities meet SSA's
requirements for an automated audit trail system. The EIEP must also establish a process
to obtain specific audit information from the STC regarding the EIEP's SSA transactions.
Access to the audit file must be restricted to authorized users with a "need to know."
Audit file data must be unalterable (read-only) and maintained for a minimum of three
(preferably seven) years. Information in the audit file must be retrievable by an
automated method. EIEPs must have the capability to make audit file information
available to SSA upon request. EIEPs must back-up audit trail records on a regular basis
to ensure their availability. EIEPs must apply the same level of protection to backup
audit files that apply to the original files.
If the EIEP retains SSA-provided information in a database (e.g., Access database,
SharePoint, etc.), or if certain data elements within the EIEP's system indicate to users
that SSA verified the information, the EIEP's system must also capture an audit trail
record of users who viewed SSA-provided information stored within the EIEP's system.
The retrieval requirements for SSA-provided information at rest and the retrieval
requirements for regular transactions are identical.
5.5 Personally Identifiable Information (PU)
PII is any information about an individual maintained by an agency, including (1)
any information that can be used to distinguish or trace an individual's identity,
such as name, social security number, date and place of birth, mother's maiden
name, or biometric records; and (2) any other information that is linked or linkable
to an individual, such as medical, educational, financial, and employment
information. An item such as date and place of birth, mother's maiden name, or
father's surname is PII, regardless of whether combined with other data.
SSA defines a PII loss as a circumstance when SSA has reason to believe that
information on hard copy or in electronic format, which contains PII provided by SSA,
left the EIEP's custody or the EIEP disclosed it to an unauthorized individual or entity.
PII loss is a reportable incident (refer to Incictent Reporting).
9
Exhibit B.2
If a PII loss involving SSA-provided information occurs or is suspected, the EIEP
must be able to quantify the extent of the loss and compile a complete list of the
individuals potentially affected by the incident (refer to Iacjdeat Repoctjag).
5.6 Monitoring and Anomaly Detection 0
SSA recommends that EIEPs use an Intrusion Protection System (IPS) or an
Intrusion Detection System (IDS). The EIEP must establish and/or maintain
continuous monitoring of its network infrastructure and assets to ensure the following:
o The EIEP's security controls continue to be effective over time
o Only authorized individuals, devices, and processes have access to SSA-
provided information
o The EIEP detects efforts by external and internal entities, devices, or processes to
perform unauthorized actions (i.e., data breaches, malicious attacks, access to
network assets, software/hardware installations, etc.) as soon as they occur
o The necessary parties are immediately alerted to unauthorized actions
performed by external and internal entities, devices, or processes
o Upon detection of unauthorized actions, measures are immediately initiated to
prevent or mitigate associated risk
o In the event of a data breach or security incident, the EIEP can efficiently determine
and initiate necessary remedial actions
o The trends, patterns, or anomalous occurrences and behavior in user or network
activity that may be indicative of potential security issues are readily discernible
The EIEP's system must include the capability to prevent employees from unauthorized
browsing of SSA records. SSA strongly recommends the use of a transaction-driven
permission module design, whereby employees are unable to initiate transactions not
associated with the normal business process. If the EIEP uses such a design, they then
need anomaly detection to detect and monitor employee's unauthorized attempts to gain
access to SSA-provided information and attempts to obtain information from SSA for
clients not in the EIEP's client system. The EIEP should employ measures to ensure the
permission module's integrity. Users should not be able to create a bogus case and
subsequently delete it in such a way that it goes undetected.
If the EIEP's design does not currently use a permission module and is not transaction-
driven, until at least one of these security features exists, the EIEP must develop and
implement compensating,security controls to deter employees from browsing SSA
records. These controls must include monitoring and anomaly detection features, either
systematic, manual, or a combination thereof. Such features must include the
capability to detect anomalies in the volume and/or type of transactions or queries
requested or initiated by individuals and include systematic or manual procedures for
verifying that requests and queries of SSA-provided information comply with valid
official business purposes. The system must also produce reports that allow
management and/or supervisors to monitor user activity, such as the following:
10
Exhibit B.2
• User ID Exception Reports:
This type of report captures information about users who enter incorrect user IDs
when attempting to gain access to the system or to the transaction that initiates
requests for information from SSA, including failed attempts to enter a password.
• Inquiry Match Exception Reports:
This type of report captures information about users who may be initiating
transactions for SSNs that have no client case association within the EIEP's system
(the EIEP's management should review 100 percent of these cases).
• System Error Exception Reports:
This type of report captures information about users who may not understand
or may be violating proper procedures for access to SSA-provided information.
• Inquiry Activity Statistical Reports:
This type of report captures information about transaction usage patterns
among authorized users and is a tool which enables the EIEP's management to
monitor typical usage patterns in contrast to extraordinary usage patterns.
The EIEP must have a process for distributing these monitoring and exception reports to
appropriate local managers/supervisors or to local security officers. The process must
ensure that only those whose responsibilities include monitoring anomalous activity of
users, to include those who have exceptional system rights and privileges, use the
reports.
5.7 Management Oversight and Quality Assurance 0
The EIEP must establish and/or maintain ongoing management oversight and quality
assurance capabilities to ensure that only authorized employees have access to SSA-
provided information. They must ensure ongoing compliance with the terms of the EIEP's
electronic information sharing agreement with SSA and the SSRs established for access to
SSA-provided information. The entity responsible for management oversight must consist
of one or more of the EIEP's management officials whose job functions include
responsibility to ensure that the EIEP only grants access to the appropriate employees and
position types which require SSA-provided information to do their jobs.
The EIEP must ensure that employees granted access to SSA-provided information
receive adequate training on the sensitivity of the information, associated safeguards,
operating procedures, and the penalties for misuse.
SSA recommends that EIEPs establish the following job functions and require that
employees tasked with these job functions do not also share the same job functions as
personnel who request or use information from SSA.
• Perform periodic self-reviews to monitor the EIEP's ongoing usage of SSA-
provided information.
• Perform random sampling of work activity that involves SSA-provided
information to determine if the access and usage comply with SSA's
requirements.
11
Exhibit B.2
5.8 Data and Communications Security 0
EIEPs must encrypt PII and SSA-provided information when transmitting across dedicated
communications circuits between its systems, intrastate communications between its local
office locations, and on the EIEP's mobile computers, devices and removable media. The
EIEP's encryption methods should align with the Standards established by the National
Institute of Standards and Technology (NIST). SSA recommends the Advanced
Encryption Standard (AES) or triple DES (Data Encryption Standard 3), if AES is
unavailable, encryption method for securing SSA-provided information during transport.
Files encrypted for external users (when using tools such as Microsoft WORD
encryption,) require a key length of nine characters. We also recommend that the key
(also referred to as a password) contain both special characters and a number. SSA
requires that the EIEP deliver the key so that the key does not accompany the media.
The EIEP must secure the key when not in use or unattended.
SSA discourages the use of the public Internet for transmission of SSA-provided
information. If however, the EIEP uses the public Internet or other electronic
communications, such as emails and faxes to transmit SSA-provided information, they
must use a secure encryption protocol such as Secure Socket Layer (SSL) or Transport
Layer Security {TLS). SSA also recommends 256-bit encryption protocols or more
secure methods such as Virtual Private Network technology. The EIEP should only send
data to a secure address or device to which the EIEP can control and limit access to only
specifically authorized individuals and/or processes. SSA recommends that EIEPs
use Media Access Control (MAC) Filtering and Firewalls to protect access points
from unauthorized devices attempting to connect to the network.
EIEPs should not retain SSA-provided information any longer than business
purpose(s) dictate. The Information Exchange Agreement with SSA stipulates a time
for data retention. The EIEP should delete, purge, destroy, or return SSA-provided
information when the business purpose for retention no longer exists.
The EIEP may not save or create separate files comprised solely of information provided
by SSA. The EIEP may apply specific SSA-provided information to the EIEP's matched
record from a preexisting data source. Federal law prohibits duplication and redisclosure
of SSA-provided information without written approval. The prohibition applies to both
internal and external sources who do not have a "need-to-know2 ." SSA recommends
that EIEPs use either Trusted Platform Module (TPM) or Hardware Security
Module (HSM) technology solutions to encrypt data at rest on hard drives and
other data storage media.
EIEPs must prevent unauthorized disclosure of SSA-provided information after they
complete processing and after the EIEP no longer requires the information. The EIEP's
operational processes must ensure that no residual SSA-provided information remains on
the hard drives of user's workstations after the user exits the application(s) that use
SSA-provided information. If the EIEP must send a computer, hard drive, or other
computing or storage device offsite for repair, the EIEP must have a non-disclosure
clause in their contract with the vendor. If the EIEP used the item in connection with a
business process that involved SSA-provided information and the vendor will retrieve or
may view SSA-provided information during servicing, SSA reserves the right to inspect
2 Need-to-know -access to the information must be necessary for the conduct of one's official duties.
12
Exhibit B.2
the EIEP's vendor contract. The EIEP must remove SSA-provided information from
electronic devices before sending it to an external vendor for service. SSA expects the
EIEP to render it unrecoverable or destroy the electronic device if they do not need to
recover the data. The same applies to excessed, donated, or sold equipment placed into
the custody of another organization.
To sanitize media, the EIEP should use one of the following methods:
• Overwriting
Overwrite utilities can only be used on working devices. Overwriting is appropriate only for
devices designed for multiple reads and writes. The EIEP should overwrite disk drives,
magnetic tapes, floppy disks, USB flash drives, and other rewriteable media. The overwrite
utility must completely overwrite the media. SSA recommends the use of purgjag media
sanitization to make the data irretrievable and to protect data against laboratory attacks or
forensics. Please refer to Definitions for more information regarding Medja
Sanjtjzatjoa). Reformatting the media does not overwrite the data.
o Degaussing
Degaussing is a sanitization method for magnetic media (e.g., disk drives, tapes,
floppies, etc.). Degaussing is not effective for purging non-magnetic media (e.g.,
optical discs). Degaussing requires a certified tool designed for particular types of
media. Certification of the tool is required to ensure that the magnetic flux applied to
the media is strong enough to render the information irretrievable. The degaussing
process must render data on the media irretrievable by a laboratory attack or
laboratory forensic procedures (refer to Defiajtjoas for more information regarding
Medja Sanjtization).
o Physical destruction
Physical destruction is the method when degaussing or over-writing cannot be
accomplished (for example, CDs, floppies, DVDs, damaged tapes, hard drives,
damaged USB flash drives, etc.). Examples of physical destruction include shredding,
pulverizing, and burning.
State agencies may retain SSA-provided information in hardcopy only if required to
fulfill evidentiary requirements, provided the agencies retire such data in accordance
with applicable state laws governing retention of records. The EIEP must control print
media containing SSA-provided information to restrict its access to authorized
employees who need such access to perform their official duties. EIEPs must destroy
print media containing SSA-provided information in a secure manner when it is no longer
required for business purposes. The EIEP should destroy paper documents that contain
SSA-provided information by burning, pulping, shredding, macerating, or other similar
means that ensure the information is unrecoverable.
NOTE: Hand tearing or lining through documents to obscure information
does not meet SSA's requirements for appropriate destruction of PII.
The EIEP must employ measures to ensure that communications and data furnished to
SSA contain no viruses or other malware.
Special Note: If SSA-provided information will be stored in a commercial
13
Exhibit B.2
cloud, please provide the name and address of the cloud provider. Also,
please describe the securitY features contractually required of the cloud
provider to protect SSA-provided information.
5.9 Incident Reporting 0
SSA requires EIEPs to develop and implement policies and procedures to respond to
data breaches or PII loses. You must explain how your policies and procedures
conform to SSA's requirements. The procedures must include the following
information:
If the EIEP experiences or suspects a breach or loss of PII or a .security incident,
which includes SSA-provided information, they must notify the State official
responsible for Systems Security designated in the agreement. That State official or
delegate must then notify the SSA Regional Office Contact and the SSA Systems
Security Contact identified in the agreement. If, for any reason, the responsible State
official or delegate is unable to notify the SSA Regional Office or the SSA Systems
Security Contact within one hour, the responsible State Agency official or delegate
must report the incident by contacting SSA's National Network Service Center
(NNSC) toll free at 877-697-4889 (select "Security and PI! Reporting" from the
options list). The EIEP will provide updates as they become available to the SSA
contact, as appropriate. Refer to the worksheet provided in the agreement to
facilitate gathering and organizing information about an incident.
The EIEP must agree to absorb all costs associated with notification and remedial actions
connected to security breaches, if SSA determines that the risk presented by the
breach or security incident requires the notification of the subject individuals. SSA
recommends that EIEPs seriously consider establishing incident response
teams to address PII breaches.
5.10 Security Awareness and Employee Sanctions 0
The EIEP must designate a department or party to take the responsibility to provide
ongoing security awareness training for employees who access SSA-provided
information. Training must include:
o The sensitivity of SSA-provided information and address the Privacy Act and other
Federal and state laws governing its use and misuse
o Rules of behavior concerning use and security in systems processing SSA-provided
information
o Restrictions on viewing and/or copying SSA-provided information
o The employee's responsibility for proper use and protection of SSA-provided
information including its proper disposal
o Security incident reporting procedures
o Basic understanding of procedures to protect the network from malware attacks
14
Exhibit B.2
a Spoofing, Phishing, and Pharming scam prevention
a The possible sanctions and penalties for misuse of SSA-provided information
SSA requires the EIEP to provide security awareness training to all employees and
contractors who access SSA-provided information. The training should be annual,
mandatory, and certified by the personnel who receive the training. SSA also requires
the EIEP to certify that each employee or contractor who views SSA-provided data also
certify that they understand the potential criminal and administrative sanctions or
penalties for unlawful disclosure.
5.11 Contractors of Electronic Information Exchange Partners 0
As previously stated in The General Systems Securjty Stanctards, contractors of the
EIEP must adhere to the same security requirements as employees of the EIEP. The
EIEP is responsible for the oversight of its contractors and the contractor's compliance
with the security requirements. The EIEP will enter into a written agreement with each
of its contractors and agents who need SSA data to perform their official duties,
whereby such contractors or agents agree to abide by all relevant Federal laws,
restrictions on access, use, disclosure, and the security requirements in this
Agreement.
The EIEP's employees, contractors, and agents who access, use, or disclose
SSA data in a manner or purpose not authorized by this Agreement may be subject to
both civil and criminal sanctions pursuant to applicable Federal statutes. The EIEP will
provide its contractors and agents with copies of this Agreement, related
IEAs, and all related attachments before initial disclosure of SSA data to such
contractors and agents. Prior to signing this Agreement, and thereafter at SSA's
request, the EIEP will obtain from its contractors and agents a current list of
the employees of such contractors and agents with access to SSA data and provide
such lists to SSA.
The EIEP must be able to provide proof of the contractual agreement If the contractor
processes, handles, or transmits information provided to the EIEP by SSA or has
authority to perform on the EIEP's behalf, the EIEP should clearly state the specific roles
and functions of the contractor. The EIEP will provide SSA written certification that the
contractor is meeting the terms of the agreement, including SSA security requirements.
The certification will be subject to our final approval before redisclosing our information.
The EIEP must also require that contractors who will process, handle, or transmit
information provided to the EIEP by SSA sign an agreement with the EIEP that obligates
the contractor to follow the terms of the EIEP's data exchange agreement with SSA. The
EIEP or the contractor must provide a copy of the data exchange agreement to each of
the contractor's employees before disclosing data and make certain that the contractor's
employees receive the same security awareness training as the EIEP's employees. The
EIEP should maintain awareness-training records for the contractor's employees and
require the same annual certification procedures.
The EIEP will be required to conduct the review of contractors and is responsible
for ensuring compliance of its contractors with security and privacy requirements and
limitations. As such, the EIEP will subject the contractor to ongoing security compliance
15
Exhibit B.2
reviews that must meet SSA standards. The EIEP will conduct compliance
reviews at least triennially commencing no later than three ( 3) years after the approved
initial security certification to SSA; and must provide SSA with written documentation of
recurring compliance reviews, with the contractor, subject to our approval.
If the EIEP's contractor will be involved with the processing, handling, or transmission
of information provided to the EIEP by SSA offsite from the EIEP, the EIEP must have
the contractual option to perform onsite reviews of that offsite facility to ensure that the
following meet SSA's requirements:
o safeguards for sensitive information
o computer system safeguards
o security controls and measures to prevent, detect, and resolve unauthorized
access to, use of, and redisclosure of SSA-provided information
o continuous monitoring of the EIEP contractors' network infrastructures and assets
6. General --Security Certification and Compliance Review Programs 0
SSA's security certification and compliance review programs are distinct processes. The
certification program is a one-time process when an EIEP initially requests electronic access to
SSA-provided information. The certification process entails two rigorous stages intended to
ensure that technical, management, and operational security measures work as designed. SSA
must ensure that the EIEPs fully conform to SSA's security requirements and satisfy both
stages of the certification process before SSA will permit online access to its data in a
production environment.
The compliance review program, however, ensures that the suite of security measures
implemented by an EIEP to safeguard SSA-provided information remains in full compliance with
SSA's security standards and requirements. The compliance review program applies to both
online and batch access to SSA-provided information. Under the compliance review program,
EIEPs are subject to ongoing and periodic security reviews by SSA.
6.1 The Security Certification Program 0
The security certification process applies to EIEPs that seek online electronic access to SSA
information and consists of two general phases:
• Phase One: The Security Design Plan (SDP) phase is a formal written plan authored
by the EIEP to comprehensively document its technical and non-technical security
controls to safeguard SSA-provided information (refer to Documenting Security
Controls ja the Security Desjgn Plan).+
NOTE: SSA may have legacy EIEPs (EIEPs not certified under the current
process) who have not prepared an SOP. OIS strongly recommends that
these EIEPs prepare an SOP.
The EIEP's preparation and maintenance of a current SOP will aid them in
determining potential compliance issues prior to reviews, assuring
continued compliance with SSA's security requirements, and providing for
16
Exhibit B.2
more efficient security reviews.
• Phase 2: The SSA Onsite Certification phase is a formal onsite review conducted by
SSA to examine the full suite of technical and non-technical security controls
implemented by the EIEP to safeguard data obtained from SSA electronically (refer to
The Cectificatjon Pwce,ss).
6.2 Documenting Security Controls in the Security Design Plan (SOP) 0
6.2.1 When the SOP and Risk Assessment are Required 0
EIEPs must submit an SDP and a security risk assessment (RA) for evaluation when one or
more of the following circumstances apply. The RA must be in electronic format. It must
include discussion of the measures planned or implemented to mitigate risks identified by
the RA and (as applicable) risks associated with the circumstances below:
• to obtain approval for requested access to SSA-provided information for an initial
agreement
• to obtain approval to reestablish previously terminated access to SSA-provided data
• to obtain approval to implement a new operating or security platform that will involve
SSA-provided information
• to obtain approval for significant changes to the EIEP's organizational structure,
technical processes, operational environment, data recovery capabilities, or security
implementations planned or made since approval of their most recent SDP or of their
most recent successfully completed security review
• to confirm compliance when one or more security breaches or incidents involving
SSA-provided information occurred since approval of the EIEP's most recent SDP
or of their most recent successfully completed security review
o to document descriptions and explanations of measures implemented as the result
of a data breach or security incident
• to document descriptions and explanations of measures implemented to resolve
non-compliancy issue(s)
• to obtain a new approval after SSA revoked approval of the most recent SDP
SSA may require a new SDP if changes occurred (other than those listed above) that
may affect the terms of the EIEP's information sharing agreement with SSA.
SSA will not approve the SDP or allow the initiation of transactions and/or access
to SSA-provided information before the EIEP complies with the SSRs.
An SDP must satisfactorily document the EIEP's compliance with all of SSA's SSRs in order to
provide the minimum level of security acceptable to SSA for its EIEP's access to SSA-provided
information.
EIEP's must correct deficiencies identified through the evaluation of the SDP and submit a
revised SDP that incorporates descriptions and explanations of the measures implemented to
17
Exhibit B.2
eliminate the deficiencies. SSA cannot grant access to SSA-provided information until the EIEP
corrects the deficiencies, documents the SDP, and SSA approves the revisions. The EIEP will
communicate the implementation of corrective actions to SSA on a regular basis. SSA will
withhold final approval until the EIEP can rectify all deficiencies.
SSA may revoke the approval of the EIEP's SDP and its access to SSA-provided information if we
learn the EIEP is non-compliant with one or more SSRs. The EIEP must submit a revised SDP,
which incorporates descriptions and explanations of the measures the EIEP will implement to
resolve the non-compliance issue(s). The EIEP must communicate the progress of corrective
action(s) to SSA on a regular basis. SSA will consider the EIEP in non-compliant status until
resolution of the issue(s), the EIEP's SDP documents the corrections, and we approve the SDP.
If, within a reasonable time as determined by SSA, the EIEP is unable to rectify a deficiency
determined by SSA to present a substantial risk to SSA-provided information or to SSA, SSA will
withhold approval of the SOP and discontinue the flow of SSA-provided information.
NOTE: EIEPs that function only as an STC, transferring SSA-provided information
to other EIEPs must, per the terms of their agreements with SSA, adhere to SSA's
System Security Requirements (SSR) and exercise their responsibilities regarding
protection of SSA-provided information.
6.3 The Certification Process 0
Once the EIEP has successfully satisfied Phase 1, SSA will conduct an onsite certification
review. The objective of the onsite review is to ensure the EIEP's non-technical and
technical controls safeguard SSA-provided information from misuse and improper disclosure
and that those safeguards function and work as intended.
At its discretion, SSA may request that the EIEP participate in an onsite review and
compliance certification of their security infrastructure.
The onsite review may address any or all of SSA's security requirements and include, when
appropriate:
• a demonstration of the EIEP's implementation of each requirement
• random sampling of audit records and transactions submitted to SSA
• a walkthrough of the EIEP's data center to observe and document physical security
safeguards
• a demonstration of the EIEP's implementation of electronic exchange of data with SSA
• discussions with managers/supervisors
• examination of management control procedures and reports (e.g., anomaly detection
reports, etc.)
• demonstration of technical tools pertaining to user access control and if appropriate,
browsing prevention, specifically:
o If the design is based on a permission module or similar design, or it is transaction
driven, the EIEP will demonstrate how the system triggers requests for information
from SSA.
18
Exhibit B.2
o If the design is based on a permission module, the EIEP will demonstrate how the
process for requests for SSA-provided information prevent SSNs not present in the
EIEP's system from sending requests to SSA. We will attempt to obtain information
from SSA using at least one, randomly created, fictitious number not known to the
EIEPs system.
During a certification or compliance review, SSA or a certifier acting on its behalf, may
request a demonstration of the EIEP's audit trail system (ATS) and its record retrieval
capability. The certifier may request a demonstration of the ATS' capability to track the
activity of employees who have the potential to access SSA-provided information within the
EIEP's system. The certifier may request more information from those EIEPs who use an
STC to handle and audit transactions. We will conduct a demonstration to see how the EIEP
obtains audit information from the STC regarding the EIEP's SSA transactions.
If an STC handles and audits an EIEP's transactions, SSA requires the EIEP to demonstrate
both their own in-house audit capabilities and the process used to obtain audit information
from the STC.
If the EIEP employs a contractor who processes, handles, or transmits the EIEP's SSA-
provided information offsite, SSA, at its discretion, may include the contractor's facility in
the onsite certification review. The inspection may occur with or without a representative
of the EIEP.
Upon successful completion of the onsite certification exercise, SSA will authorize
electronic access to production data by the EIEP. SSA will provide written notification of
its certification to the EIEP and all appropriate internal SSA components.
The following is a high-level flow chart of the OIS Certification Process: 0
Kickoff Meeting
to discuss certification process with
EIEP
Evaluate SOP for approval
Conduct onsite review
Certify the EIEP
19
Exhibit B.2
6.5 The Compliance Review Program and Process 0
Similar to the certification process, the compliance review program entails a rigorous
process intended to ensure that EIEPs who receive electronic information from SSA are in full
compliance with the Agency's security requirements and standards. As a practice, SSA
attempts to conduct compliance reviews following a two to five year periodic review
schedule. However, as circumstances warrant, a review may take place at any time. Three
prominent examples that would trigger an ad hoc review are:
• a significant change in the outside EIEP's computing platform
• a violation of any of SSA's systems security requirements
• an unauthorized disclosure of SSA information by the EIEP
The following is a high-level flow chart of the OIS Compliance Review Process: 0
Make ris~ed-based selection of target
Determine method of review
Gather background information
Set review date
Conduct compliance review
Finalize review documentation
Monitor findings
SSA may conduct onsite compliance reviews and include both the EIEP's main facility and a field
office.
SSA may, also at its discretion, request that the EIEP participate in an onsite compliance
review of their security infrastructure.to confirm the implementation of SSA's security
requirements.
20
Exhibit B.2
The onsite review may address any or all of SSA's security requirements and include, where
appropriate:
• a demonstration of the EIEP's implementation of each requirement
• random sampling of audit records and transactions submitted to SSA
• a walkthrough of the EIEP's data center to observe and document physical security
safeguards
• a demonstration of the EIEP's implementation of online exchange of data with SSA
• discussions with managers/supervisors
• examination of management control procedures and reports (e.g. anomaly detection
reports, etc.)
• demonstration of technical tools pertaining to user access control and, if appropriate,
browsing prevention:
a If the design uses a permission module or similar design, or is transaction driven, the
EIEP will demonstrate how the system triggers requests for information from SSA.
a If the design uses a permission module, the EIEP will demonstrate the process used to
request SSA-provided information and prevent the EIEP's system from processing SSNs
not present in the EIEP's system. We can accomplish this by attempting to obtain
information from SSA using at least one, randomly created, fictitious number not known
to the EIEP's system.
SSA may, at its discretion, perform an onsite or remote review for reasons including, but
not limited to the following:
• the EIEP has experienced a security breach or incident involving SSA-provided information
• the EIEP has unresolved non-compliancy issue(s)
• to review an offsite contractor's facility that processes SSA-provided information
• the EIEP is a legacy organization that has not yet been through SSAs security certification
and compliance review programs
• the EIEP requested that SSA perform an IV & V (Independent Verification and Validation
review)
During the compliance review, SSA, or a certifier acting on its behalf, may request a
demonstration of the system's audit trail and retrieval capability. The certifier may request a
demonstration of the system's capability for tracking the activity of employees who view SSA-
provided information within the EIEP's system. The certifier may request EIEPs that have STCs
that handle and audit transactions with SSA to demonstrate the process used to obtain audit
information from the STC.
If an STC handles and audits the EIEP's transactions with SSA, we may require the EIEP to
demonstrate both their in-house audit capabilities and the processes used to obtain audit
information from the STC regarding the EIEP's transactions with SSA.
21
Exhibit B.2
If the EIEP employs a contractor who will process, handle, or transmit the EIEP's SSA-provided
information offsite, SSA, at its discretion, may include in the onsite compliance review an onsite
inspection of the contractor's facility. The inspection may occur with or without a representative
of the EIEP. The format of the review in routine circumstances (i.e., the compliance review is
not being conducted to address a special circumstance, such as a disclosure violation) will
generally consist of reviewing and updating the EIEP's compliance with the systems security
requirements described above in this document. At the conclusion of the review, SSA will issue
a formal report to appropriate EIEP personnel. The Final Report will address findings and
recommendations from SSA's compliance review, which includes a plan for monitoring each issue
until closure.
NOTE: SSA handles documentation provided for compliance reviews as sensitive
information. The information is only accessible to authorized individuals who have a
need for the information as it relates to the EIEP's compliance with its electronic
information sharing agreement with SSA and the associated system security
requirements and procedures. SSA will not retain the EIEP's documentation any longer
than required. SSA will delete, purge, or destroy the documentation when the
retention requirement expires.
The following is a high-level example of the analysis that aids SSA in making a preliminary
determination as to which review format is appropriate. We may also use additional factors to
determine whether SSA will perform an onsite or remote compliance review.
• High/Medium Risk Criteria
o undocumented closing of prior review finding(s)
o implementation of technical/operational controls that affect security of SSA-provided
information (e.g. implementation of new data access method)
o PII breach
• Low Risk Criteria
o no prior review finding(s) or prior finding(s) documented as closed
o no implementation of technical/operational controls that impact security of SSA-provided
information (e.g. implementation of new data access method)
o no PII breach
6.5.1 EIEP Compliance Review Participation 0
SSA may request to meet with the following persons during the compliance review:
• a sample of managers and/or supervisors responsible for enforcing and monitoring
ongoing compliance to security requirements and procedures to assess their level of
training to monitor their employee's use of SSA-provided information, and for
reviewing reports and taking necessary action
• the individuals responsible for performing security awareness and employee sanction
functions to learn how you fulfill this requirement
• a sample of the EIEP's employees to assess their level of training and
understanding of the requirements and potential sanctions applicable to the use
and misuse of SSA-provided information
22
Exhibit B.2
• the individual(s) responsible for management oversight and quality assurance
functions to confirm how your agency accomplishes this requirement
• additional individuals as deemed appropriate by SSA
6.5.2 Verification of Audit Samples 0
Prior to or during the compliance review, SSA will present to the EIEP a sampling
of transactions previously submitted to SSA for verification. SSA requires the
EIEP to verify whether each transaction was, per the terms of their agreement
with SSA, legitimately submitted by a user authorized to do so.
SSA requires the EIEP to provide a written attestation of the transaction review
results. The document must provide:
• confirmation that each sample transaction located in the EIEP's audit file
submitted by its employee(s) was for legitimate and authorized business
purposes
• an explanation for each sample transaction located in the EIEP's audit file(s)
determined to have been unauthorized
• an explanation for each sample transaction not found in the EIEP's ATS
When SSA provides the sample transactions to the EIEP, detailed instructions will be
included. Only an official responsible for the EIEP is to provide the attestation.
6.6 Scheduling the Onsite Review 0
SSA will not schedule the onsite review until we approve the EIEP's SOP. SSA will send
approval notification via email. There is no prescribed period for arranging the subsequent
onsite review (certification review for an EIEP requesting initial access to SSA-provided
information for an initial agreement or compliance review for other EIEPs). Unless there
are compelling circumstances precluding it, the onsite review will follow as soon as
reasonably possible.
However, the scheduling of the onsite review may depend on additional factors including:
• the reason for submission of a plan
• the severity of security issues, if any
• circumstances of the previous review, if any
• SSA workload considerations
Although the scheduling of the review is contingent upon approval of the SOP, SSA may
perform an onsite review prior to approval if we determine that it is necessary to
complete our evaluation of a plan.
23
Exhibit B.2
(THIS PAGE HAS BEEN LEFT BLANK INTENTIONALLY)
24
Exhibit B.2
7. Additional Definitions 0
Back Button:
Refers to a button on a web browser's toolbar, the backspace button on a
computer keyboard, a programmed keyboard button or mouse button, etc.,
that returns a user to a previously visited web page or application screen.
Breach:
Refers to actual loss, loss of control, compromise, unauthorized disclosure,
unauthorized acquisition, unauthorized access, or any similar term referring to
situations where unauthorized persons have access or potential access to PII or
Covered Information, whether physical, electronic, or in spoken word or
recording.
Browsing:
Requests for or queries of SSA-provided information for purposes not related to
the performance of official job duties.
Choke Point:
The firewall between a local network and the Internet is a choke point in
network security, because any attacker would have to come through that
channel, which is typically protected and monitored.
Cloud Computing:
The term refers to Internet-based computing derived from the cloud
drawing representing the Internet in computer network diagrams. Cloud
computing providers deliver on-line and on-demand Internet services.
Cloud Services normally use a browser or Web Server to deliver and store
information.
Cloud Computing (NIST SP 800-145 Excerpt):
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a
shared pool of configurable computing resources (e.g., networks, servers, storage, applications,
and services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction. This cloud model is composed of five essential characteristics, three
service models, and four deployment models.
Essential Characteristics:
·On-demand self-service -A consumer can unilaterally provision computing capabilities, such as
server time and network storage, as needed automatically without requiring human interaction
with each service provider.
Broad network access -Capabilities are availab.le over the network and accessed through
standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g.,
25
Exhibit B.2
mobile phones, tablets, laptops, and workstations).
Resource pooling -The provider's computing resources are pooled to serve multiple consumers
using a multi-tenant model, with different physical and virtual resources dynamically assigned and
reassigned according to consumer demand. There is a sense of location independence in that the
customer generally has no control or knowledge over the exact location of the provided resources
but may be able to specify location at a higher level of abstraction (e.g., country, state, or
datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
Rapid elasticity -Capabilities can be elastically provisioned and released, in some cases
automatically, to scale rapidly outward and inward commensurate with demand. To the
consumer, the capabilities available for provisioning often appear to be unlimited and can be
appropriated in any quantity at any time.
Measured service -Cloud systems automatically control and optimize resource use by leveraging
a metering capabilityl at some level of abstraction appropriate to the type of service (e.g.,
storage, processing, bandwidth, and active user accounts). Resource usage can be monitored,
controlled, and reported, providing transparency for both the provider and consumer of the
utilized service.
Service Models:
Software as a Service (SaaS) -The capability provided to the consumer is to use the provider's
applications running on a cloud infrastructure2. The applications are accessible from various client
devices through either a thin client interface, such as a web browser (e.g., web-based email), or a
program interface. The consumer does not manage or control the underlying cloud infrastructure
including network, servers, operating systems, storage, or even individual application capabilities,
with the possible exception of limited user-specific application configuration settings.
Platform as a Service (PaaS) -The capability provided to the consumer is to deploy onto the cloud
infrastructure consumer-created or acquired applications created using programming languages,
libraries, services, and tools supported by the provider.3 The consumer does not manage or
control the underlying cloud infrastructure including network, servers, operating systems, or
storage, but has control over the deployed applications and possibly configuration settings for the
application-hosting environment.
Infrastructure as a Service (laaS) -The capability provided to the consumer is to provision
processing, storage, networks, and other fundamental computing resources where the consumer
is able to deploy and run arbitrary software, which can include operating systems and
applications. The consumer does not manage or control the underlying cloud infrastructure but
has control over operating systems, storage, and deployed applications; and possibly limited
control of select networking components (e.g., host firewalls).
26
Exhibit B.2
Deployment Models:
Private cloud -The cloud infrastructure is provisioned for exclusive use by a single organization
comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by
the organization, a third party, or some combination of them, and it may exist on or off premises.
Community cloud -The cloud infrastructure is provisioned for exclusive use by a specific
community of consumers from organizations that have shared concerns (e.g., mission, security
requirements, policy, and compliance considerations). It may be owned, managed, and operated
by one or more of the organizations in the community, a third party, or some combination of
them, and it may exist on or off premises .
. · Public cloud -The cloud infrastructure is provisioned for open use by the general public. It may be
owned, managed, and operated by a business, academic, or government organization, or some
combination of them. It exists on the premises of the cloud provider.
Hybrid cloud -The cloud infrastructure is a composition of two or more distinct cloud
infrastructures (private, community, or public) that remain unique entities, but are bound
together by standardized or proprietary technology that enables data and application portability
(e.g., cloud bursting for load balancing between clouds).
1 Typically this is done on a pay-per-use or charge-per-use basis.
2 A cloud infrastructure is the collection of hardware and software that enables the five essential
characteristics of cloud computing. The cloud infrastructure can be viewed as containing both a physical
layer and an abstraction layer. The physical layer consists of the hardware resources that are necessary to
support the cloud services being provided, and typically includes server, storage and network components.
The abstraction layer consists of the software deployed across the physical layer, which.manifests the
essential cloud characteristics. Conceptually the abstraction layer sits above the physical layer.
3 This capability does not necessarily preclude the use of compatible programming languages, libraries,
services, and tools from other sources.
Cloud Drive:
A cloud drive is a Web-based service that provides storage space on a remote
server.
Cloud Audit:
Cloud Audit is a specification developed at Cisco Systems, Inc. that provides
cloud computing service providers a standard way to present and share
detailed, automated statistics about performance and security.
27
Exhibit B.2
Commingling:
Commingling is the creation of a common database or repository that stores and
maintains both SSA-provided and preexisting EIEP PII.
Degaussing:
Degaussing is the method of using a "special device" (i.e., a device that
generates a magnetic field) in order to disrupt magnetically recorded
information. Degaussing can be effective for purging damaged media and media
with exceptionally large storage capacities. Degaussing is not effective for
purging non-magnetic media (e.g., optical discs).
Dial-up:
Sometimes used synonymously with dial-in, refers to digital data transmission
over the wires of a local telephone network.
Function:
One or more persons or organizational components assigned to serve a
particular purpose, or perform a particular role. The purpose, activity, or role
assigned to one or more persons or organizational components.
Hub:
As it relates to electronic data exchange with SSA, a hub is an organization,
which serves as an electronic information conduit or distribution collection
point. The term Hub is interchangeable with the terms "StateTransmission
Component," "State Transfer Component," or "STC."
ICON:
Interstate Connection Network (various entities use 'Connectivity' rather than
'Connection')
IV & V:
Independent Verification and Validation
Legacy System:
A term usually referring to a corporate or organizational computer system or
network that utilizes outmoded programming languages, software, and/or
hardware that typically no longer receives support from the original vendors or
developers.
Manual Transaction:
A user-initiated operation (also referred to as a "user-initiated transaction").
This is the opposite of a system-generated automated process.
Example: A user enters a client's information including the client's SSN and
presses the "ENTER" key to acknowledge that input of data is complete. A
new screen appears with multiple options, which include "VERIFY SSN" and
28
"CONTINUE". The user has the option to verify the client's SSN or perform
alternative actions.
Media Sanitization:
• Disposal: Refers to the discarding (e.g., recycling) of media that
contains no sensitive or confidential data.
Exhibit B.2
• Clearing: This type of media sanitization is adequate for protecting
information from a robust keyboard attack. Clearing must prevent retrieval
of information by data, disk, or file recovery utilities. Clearing must be
resistant to keystroke recovery attempts executed from standard input
devices and from data scavenging tools. For example, overwriting is an
acceptable method for clearing media. Deleting items, however, is not
sufficient for clearing.
This process may include overwriting all addressable locations of the data, as
well as its logical storage location (e.g., its file allocation table). The aim of
the overwriting process is, to replace or obfuscate existing information with
random data. Most rewriteable media may be cleared by a single overwrite.
This method of sanitization is not possible on un-writeable or damaged media.
• Purging: This type of media sanitization is a process that protects
information from a laboratory attack. The terms clearing and purging are
sometimes synonymous. However, for some media, clearing is not
sufficient for purging (i.e., protecting data from a laboratory attack).
Although most re-writeable media requires a single overwrite, purging
may require multiple rewrites using different characters for each write
cycle.
This is because a laboratory attack involves threats with the capability to
employ non-standard assets (e.g., specialized hardware) to attempt data
recovery on media outside of that media's normal operating environment.
Degaussing is also an example of an acceptable method for purging magnetic
media. The EIEP should destroy media if purging is not a viable method for
sanitization.
• Destruction: Physical destruction of media is the most effective form of
sanitization. Methods of destruction include burning, pulverizing, and
shredding. Any residual medium should be able to withstand a laboratory
attack.
Permission module:
A utility or subprogram within an application, which automatically enforces
the relationship of a request for or query of SSA-provided information to an
authorized process or transaction before initiating a transaction. For
example, requests for verification of an SSN for issuance of a driver's license
happens automatically from within a state driver's license application. The
System will not allow a user to request information from SSA unless the
EIEP's client system contains a record of the subject individual's SSN.
Screen Scraping:
29
Exhibit B.2
Screen scraping is normally associated with the programmatic collection of visual
data from a source. Originally, screen scraping referred to the practice of
reading text data from a computer display terminal's screen. This involves
reading the terminal's memory through its auxiliary port, or by connecting the
terminal output port of one computer system to an input port on another. The
term screen scraping is synonymous with the term bidirectional exchange of
data.
A screen scraper might connect to a legacy system via Telnet, emulate the
keystrokes needed to navigate the legacy user interface, process the resulting
display output, extract the desired data, and pass it on to a modern system.
More modern screen scraping techniques include capturing the bitmap data
from a screen and running it through an optical character reader engine, or
in the case of graphical user interface applications, querying the graphical
controls by programmatically obtaining references to their underlying
programming objects.
Security Breach:
An act from outside an organization that bypasses or violates security policies,
practices, or procedures.
Security Incident:
A security incident happens when a fact or event signifies the possibility that a
breach of security may be taking place, or may have taken place. All threats are
security incidents, but not all security incidents are threats.
Security Violation:
An act from within an organization that bypasses or disobeys security
policies, practices, or procedures.
Sensitive data:
Any information, the loss, misuse, or unauthorized access to or modification of
which could adversely affect the national interest of the conduct of federal
programs, or the privacy to which individuals are entitled under section 552a of
title 5, United States Code (the Privacy Act), but which has not been specifically
authorized under criteria established by an Executive Order or an Act of Congress
to be kept secret in the interest of national defense or foreign policy.
SMDS (Switched Multimegabit Data Service (SMDS):
SMDS is a telecommunications service that provides connectionless, high-
performance, packet-switched data transport. Although not a protocol, it
supports standard protocols and
communications interfaces using current technology.
SSA-provided data/ information:
Synonymous with "SSA-supplied data/information." Defines information under
the control of SSA that is provided to an external entity under the terms of an
information exchange agreement with SSA. The following are examples of
30
Exhibit B.2
SSA-provided data/information:
• SSA's response to a request from an EIEP for information from SSA (e.g., date
of death)
• SSA's response to a query from an EIEP for verification of an SSN
SSA data/information:
This term, sometimes used interchangeably with "SSA-provided data/information',
denotes
information under the control of SSA that is provided to an external entity under
the terms of an information exchange agreement with SSA. However, "SSA
data/information" also includes information provided to the EIEP by a source
other than SSA, but which the EIEP attests to that SSA verified it, or the EIEP
couples the information with data from SSA as to to certify the accuracy of the
information. The following are examples of SSA information:
• SSA's response to a request from an EIEP for information from SSA (e.g., date
of death)
• SSA's response to a query from an EIEP for verification of an SSN
• Display by the EIEP of SSA's response to a query for verification of an
SSN and the associated SSN provided by SSA
• Display by the EIEP of SSA's response to a query for verification of an
SSN and the associated SSN provided to the EIEP by a source other
than SSA
• Electronic records that contain only SSA's response to a query for verification of
an SSN
and the associated SSN whether provided to the EIEP by SSA or a source
other than SSA
SSN:
Social Security Number
STC:
A State Transmission/Transfer Component is an organization that performs as an
electronic information conduit or collection point for one or more other entities
(also referred to as a hub).
System-generated transaction:
A transaction automatically triggered by an automated system process.
Example: A user enters a client's information including the client's SSN on an
input screen and presses the "ENTER" key to acknowledge that input of data is
complete. An automated process then matches the SSN against the
organization's database and when the systems finds no match, automatically
sends an electronic request for verification of the SSN to SSA. ·
31
Systems process:
The Term "Systems Process" refers to a software program module that runs
in the background within an automated batch, online, or other process.
Third Party:
Exhibit B.2
This term pertains to an entity (person or organization) provided access to SSA-
provided information by an EIEP or other SSA business partner for which one or
more of the following apply:
• is not stipulated access to SSA-provided information by an information-sharing
agreement between an EIEP and SSA
• has no information-sharing agreement with SSA
• SSA does not directly authorize access to SSA-provided information
Transaction-driven:
This term pertains to an automatically initiated online query of or request for
SSA information by an automated transaction process (e.g., driver license
issuance, etc.). The query or request will only occur the automated process
meets prescribed conditions.
Uncontrolled transaction:
This term pertains to a transaction that falls outside a permission module. An
uncontrolled transaction is not subject to a systematically enforced relationship
between an authorized process or application and an existing client record.
(THE REST OF THIS PAGE HAS BEEN LEFT BLANK INTENTIONALLY)
32
8. Regulatory References
0
Federal Information Processing Standards
(FIPS) Publications Federal Information
Security Management Act of 2002 (FISMA)
Homeland Security Presidential Directive
(HSPD-12)
National Institute of Standards and Technology (NIST) Special Publications
Office of Management and Budget (OMB) Circular A-123, Management's
Responsibility for Internal
Control
Office of Management and Budget (OMB) Circular A-130, Appendix III,
Management of Federal
Information Resources
Exhibit B.2
Office of Management and Budget (OMB) Memo M-06-16, Protection of Sensitive
Agency
Information, June 23, 2006
Office of Management and Budget (OMB) Memo M-07-16, Memorandum for the
Heads of Executive
Departments and Agencies May 22, 2007
Office of Management and Budget (OMB) Memo M-07-17, Safeguarding Against
and Responding to the Breach of Personally Identifiable Information, May 22,
2007
Privacy Act of 1974
(THE REST OF THIS PAGE HAS BEEN LEFT BLANK INTENTIONALLY)
33
9. Frequently Asked Questions 0
(Click links for answers or additional information)
1. Q: What is a breach of data?
A: Refer also to Security Breach, Security Incident, and Security_
Violation.
2. Q: What is employee browsing?
Exhibit B.2
A: Requests for or queries of SSA-provided information for purposes not
related to the performance of official job duties
3. Q: Okay, so the SDP was submitted. Can the Onsite Review be
scheduled now?
A: Refer to Scheduling the Onsite Review.
4. Q: What is a "Permission Module"?
A: A utility or subprogram within an application, which
automatically enforces the relationship of a request for or query
of SSA-provided information to an authorized process or
transaction before initiating a transaction. For example, if
requests for verification of an SSN· for issuance of a driver's
license happens automatically from within a state driver's
license application. The System will not allow a user to request
information from SSA unless the EIEP's client system contains a
record of the subject individual's SSN.
5. Q: What is meant by Screen Scraping?
A: Screen scraping is normally associated with the programmatic
collection of visual data from a source. Originally, screen scraping
referred to the practice of reading text data from a computer display
terminal's screen. This involves reading the terminal's memory
through its auxiliary port, or by connecting the terminal output port
of one computer system to an input port on another. The term
screen scraping is synonymous with the term bidirectional exchange
of data.
A screen scraper might connect to a legacy system via Telnet,
emulate the keystrokes needed to navigate the legacy user
interface, process the resulting display output, extract the desired
data, and pass it on to a modern system.
More modern screen scraping techniques include capturing the
bitmap data from a screen and running it through an optical
character reader engine, or in the case bf graphical user
interface applications, querying the graphical controls by
programmatically obtaining references to their underlying
programming objects.
6. Q: When does an EIEP have to submit an SDP?
A: Refer to When the SDP and RA are Required.
7. Q: Does an EIEP have to submit an SDP when the agreement is
34
Exhibit B.2
renewed?
A: The EIEP does not have to submit an SDP because the agreement
between the EIEP and SSA was renewed. There are, however,
circumstances that require an EIEP to submit an SDP. Refer to
When the SOP and RA are Required.
8. Q: Is it acceptable to save SSA data with a verified indicator on a
( EIEP) workstation if the EIEP uses an encrypted hard drive? If not,
what options does the agency have?
A: There is no problem with an EIEP saving SSA-provided information
on the encrypted hard drives of computers used to process SSA
data if the EIEP retains the information only as provided for in the
EIEP's data-sharing agreement with SSA. Refer to Data and
Communications Security.
9. Q: Does SSA allow EIEPs to use caching of SSA-provided information on
the EIEP's workstations?
A: Caching during processing is not a problem. However, SSA-provided
information must clear from the cache when the user exits the
application. Refer to Data and Communications Security_.
10. Q: What does the term "interconnections to other systems" mean?
A: As used in SSA's system security requirements document, the term
"interconnections" is the same as the term "connections."
11. Q: Is it acceptable to submit the SDP as a .PDF file?
A: No, it is not. The document must remain editable.
12. Q: Should the EIEP write the SOP from the standpoint of my agency's
SVES access itself, or from the standpoint of access to all data
provided. to us by SSA?
A: The SDP is to encompass your agency's electronic access to SSA-
provided information as per the electronic data sharing agreement
between your agency and SSA. Refer to Developing the SDP.
13. Q: If we have a "transaction-driven" system, do we still need a
permission module? If employees cannot initiate a query to
SSA, why would we need the permission module?
A: "Transaction driven" basically means that queries automatically
submit requests (and it might depend on the transaction).
Depending on the system's design, queries might not be automatic or
it may still permit manual transactions. A system may require
manual transactions to correct an error. SSA does not prohibit
manual transactions if an ATS properly tracks such transactions. If a
"transaction-driven" system permits any type of alternate access; it still
requires a permission module, even if it restricts users from performing
manual transactions. If the system does not require the user to be
in a particular application or the query to be for an existing record in
the EIEP's system before the system will allow a query to go through
to SSA, it would still need a permission module.
14. Q: What is an Onsite Compliance Review?
35
Exhibit B.2
A: The Onsite Compliance Review is the process wherein SSA performs
periodic site visits to its Electronic Information Exchange Partners
(EIEP) to certify whether the EIEP's technical, managerial, and
operational security measures for protecting data obtained
electronically from SSA continue to conform to the terms of the EIEP's
data sharing agreements with SSA and SSA's associated system
security requirements and procedures. Refer to the Compliance
Review Program and Process.
15. Q: What are the criteria for performing an Onsite Compliance Review?
A: The following are criteria for performing the Onsite
Compliance Review:
• EIEP initiating new access or new access method for obtaining
information from SSA
o EIEP's cyclical review (previous review was performed remotely)
• EIEP has made significant change(s) in its operating or security
platform involving SSA-provided information
• EIEP experienced a breach of SSA-provided personally identifying
information (PII)
• EIEP has been determined to be high-risk
Refer also to the Review Determination Matrix.
16. Q: What is a Remote Compliance Review?
A: The Remote Compliance Review is when SSA conducts the meetings
remotely (e.g., via conference calls). SSA schedules conference calls
with its EIEPs to determine whether the EIEPs technical, managerial,
and operational security measures for protecting data obtained
electronically from SSA continue to conform to the terms of the EIEP's
data sharing agreements with SSA and SSA"s associated system
security requirements and procedures. Refer to the Compliance
Review Program and Process.
17. Q: What are the criteria for performing a Remote Compliance Review?
A: The EIEP must satisfy the following criteria to qualify for a Remote
Compliance Review:
• EIEP's cyclical review (SSA's previous review yielded no findings
or the EIEP satisfactorily resolved cited findings)
• EIEP has made no significant change(s) in its operating or
security platform involving SSA-provided information
• EIEP has not experienced a breach of SSA-provided
personally identifiable information (PII) since its
previous compliance review.
• SSA rates the EIEP as a low-risk agency or state
36
Exhibit B.2
Refer also to the Review Determination Matrix
37
Exhibit B.2
ATTACHMENT 5
WORKSHEET FOR REPORTING LOSS OR POTENTIAL LOSS
OF PERSONALLY IDENTIFIABLE INFORMATION
Agreement 09-6008 A-1
COSS/SSA
Exhibit B.2
Attachment A. (GAM 15.02) Worksheet for Reporting Loss or Potential Loss of Pll
IEA-F
Attachment 5
Page 1 of 3
The "Worksheet for Reporting Loss or Potential Loss of Personally Identifiable Information" is intended to
assist you to quickly organize and report the needed information about the potential incident.
1. Information about the individual making the report to the NNSC:
Name: I
Position: I
Deputy Commissioner Level Organization: I
Phone Numbers:
~·
Work: I I Cell: I I Home/Other: i
Email Address: I
Check one of the following:
Manaoement Official I I Security Officer I I Non-Manaqement I
2. Information about the data that was lost/stolen:
Describe what was lost or stolen (e.g., case file, MBR data):
Which element(s) of Pll did the data contain?
Name Bank Account Info
SSN Medical/Health Information
Date of Birth Benefit Payment Info
Place of Birth Mother's Maiden Name
Address Other (describe):
Estimated volume of records involved:
3. How was the data physically stored, packaged and/or contained?
Paper or Electronic? (Circle one):
If El h tt ectronic, w a ype o fd . ? ev1ce.
Laptop USS Drive Backup Tape Blackberrv I
Workstation Server CD/DVD Mobile Phone#
Hard Drive Floppy Disk Cell (not
Blackberry)
Other (describe):
Additional Questions if Electronic:
Yes No Not
Sure
a. Was the device encrypted?
b. Was the device password protected?
c. If a laptop, was a VPN SmartCard lost? I
d. If laptop, powerstat~ when I Off I I Sleep I I Hibernate J Not
Agreement 09-6008 A-1
COSS/SSA
lost?
Cardholder's Name:
Cardholder's_?SA logon PIN:
Hardware Make/Model:
Hardware Serial Number:
Add". IQ r f P 1t1ona ues ions i aper:
I I
a. Was the information in a locked briefcase?
Exhibit B.2
I I I
b. Was the information in a locked cabinet or drawer?
c. Was the information in a locked vehicle trunk?
d. Was the information redacted?
e. Other circumstances:
I
--
-Yes
I
I Sure I
IEA-F
Attachment 5
Page 2 of 3
No Not Sure
4. If the employee/contractor who was In possession of the data or to whom the data was
assigned is not the person making the report to the NNSC (as listed in #1), information about
this employee/contractor:
Name: . I
Position: I
Deputy Commissioner Level Ornanization: I
Phone Numbers:
Work: I I Cell: I I Home/Other: I
Email Address: I
5. Circumstances of the loss:
a. When was it losUstolen:
b. Brief description of how the loss/theft occurred:
c. When was it reported to SSA management official (date and time)?
6. Have any other SSA components been contacted? If so, who? (Include deputy commissioner
level, agency level, regional/associate level component names)
7. Which reports have been filed? (include FPS, local police, and SSA reports)
Report Filed ·--Yes I No Reoort Number
Federal Protective Service i
Local Police I
OIG I
Yes No
SSA-3114 (Incident Alert)
SSA-342 (Report of Survey)
Security Assessments and Funded Enhancements (SAFE)