Stanton City Council
January 27, 2026

If a member of the county's workforce, as defined at 45 CFR 160.103 and inclusive of an MA-063-25010752 Page 31 of 58 December 8, 2025
employee, contractor, or agent is subject to an adverse action by the organization (e.g., reduction in pay, disciplinary action, termination of employment, termination of contract for services), DHCS and CDSS recommends the organization remove his or her access to PII in advance of the adverse action to reduce the possibility that will the individual will perform unauthorized activities that involve PII, if applicable.

Supplemental
Guidance (from
NIST 800-53)
Organizational sanctions processes reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Sanctions processes are described in access agreements and can be included as part of general personnel policies and procedures for organizations. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions. Related controls: PL-4, PS-6.

11. Physical and Environmental Protection (PE)
Control
Number
PE-3
Title Physical Access Control

DHCS & CDSS
Requirement
The organization must:
a. Enforce physical access authorizations at entry and exit points to the facility where the information system resides by;

1. Verifying individual access authorizations before granting access to the facility; and

2. Controlling ingress/egress to the facility using physical access control systems/devices and/or guards;
b. Maintain physical access audit logs for entry and exit points; c. Provide security safeguards to control access to areas within the facility officially designated as publicly accessible;
d. Escort visitors and monitors visitor activity;
e. Secure keys, combinations, and other physical access devices; f. Inventory physical access devices; and
g. Changes combinations and keys at minimum when keys are lost, combinations are compromised, or individuals are transferred or terminated Supplemental
Guidance (from
NIST 800-53)
This control applies to organizational employees and visitors. Individuals (e.g., employees, contractors, and others) with permanent physical access authorization credentials are not considered visitors. Organizations determine the types of facility guards needed including, for example, professional physical security staff or other personnel such as administrative staff or information system users. Physical access devices include, for example, keys, locks, combinations, and card readers. Safeguards for publicly accessible areas within organizational facilities include, for example, cameras, monitoring by guards, and isolating selected information systems and/or system components in secured areas. Physical access control systems comply with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. The Federal Identity, Credential, and Access Management Program provides implementation guidance for identity, credential, and access management capabilities for physical access control systems. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural (e.g., a written log of MA-063-25010752 Page 32 of 58 December 8, 2025
individuals accessing the facility and when such access occurred), automated (e.g., capturing ID provided by a PIV card), or some combination thereof. Physical access points can include facility access points, interior access points to information systems and/or components requiring supplemental access controls, or both.

Components of organizational information systems (e.g., workstations, terminals) may be located in areas designated as publicly accessible with organizations safeguarding access to such devices. Related controls: AU-2, AU-6, MP-2, MP-4, PE-2, PE-4, PE-5, PS-3, RA-3.

Control
Number
PE-6
Title Monitoring Physical Access

DHCS & CDSS
Requirement
The organization must:
a. Monitors physical access to the facility where the information system resides to detect and respond to physical security incidents;
b. Reviews physical access logs organization-defined frequency and upon occurrence of security incidents; and
c. Coordinates results of reviews and investigations with the organizational incident response capability.

Supplemental
Guidance (from
NIST 800-53)
Organizational incident response capabilities include investigations of and responses to detected physical security incidents. Security incidents include, for example, apparent security violations or suspicious physical access activities. Suspicious physical access activities include, for example:
(i) accesses outside of normal work hours;
(ii) repeated accesses to areas not normally accessed;
(iii) accesses for unusual lengths of time; and (iv) out-of-sequence accesses.

Related controls: CA-7, IR-4, IR-8.

12. Planning (PL)
Control
Number
PL-1
Title Security Planning Policy and Procedures

DHCS & CDSS
Requirement
The organization must:
a. Develop, document, and disseminate to personnel and organizations with access to PII:

1. A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

2. Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and
b. Reviews and updates the current:

1. Security planning policy; and

2. Security planning procedures.

Supplemental This control addresses the establishment of policy and procedures for the effective MA-063-25010752 Page 33 of 58 December 8, 2025
Guidance (from
NIST 800-53)
implementation of selected security controls and control enhancements in the PL family.

Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control:

PM-9.

Control
Number
PL-2
Title System Security Plan

DHCS & CDSS
Requirement
The organization must:
a. Develop a security plan for the information system that:

1. Is consistent with the organization’s enterprise architecture;

2. Explicitly defines the authorization boundary for the system;

3. Describes the operational context of the information system in terms of missions and business processes;

4. Provides the security categorization of the information system including supporting rationale;

5. Describes the operational environment for the information system and relationships with or connections to other information systems;

6. Provides an overview of the security requirements for the system;

7. Identifies any relevant overlays, if applicable;

8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring decisions; and

9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;
b. Distribute copies of the security plan and communicates subsequent changes to the plan to personnel and organizations with security responsibilities; c. Review the security plan for the information system; d. Update the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and e. Protect the security plan from unauthorized disclosure and modification.

Organization's security plan should include detailed information specific to safeguarding Medi- Cal PII.

Supplemental
Guidance (from
NIST 800-53)
Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent MA-063-25010752 Page 34 of 58 December 8, 2025
determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations).

Appendix I provides guidance on developing overlays.

Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition.

For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA- 17.

13. Risk Assessment (RA)
Control
Number
RA-1
Title Risk Assessment Policy and Procedures

DHCS & CDSS
Requirement
The organization must:
a. Develop, document, and disseminate to system owners using PII:

1. A risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

2. Procedures to facilitate the implementation of the risk assessment policy and associated risk assessment controls.

Supplemental
Guidance (from
NIST 800-53)
This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the RA family.

Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures. Related control: PM-9.

Control
Number
RA-3
Title Risk Assessment
DHCS & CDSS The organization must:

MA-063-25010752 Page 35 of 58 December 8, 2025
Requirement a. Conduct an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits; b. Documents risk assessment results in a risk assessment report or organization defined risk report document.
c. Review risk assessment results annually; and
e. Update the risk assessment whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system.

Supplemental
Guidance (from
NIST 800-53)
Clearly defined authorization boundaries are a prerequisite for effective risk assessments.

Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related Eauthentication initiatives, authentication of public users accessing federal information systems may also be required to protect nonpublic or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems.

Risk assessments (either formal or informal) can be conducted at all three tiers in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any phase in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including categorization, security control selection, security control implementation, security control assessment, information system authorization, and security control monitoring. RA-3 is noteworthy in that the control must be partially implemented prior to the implementation of other controls in order to complete the first two steps in the Risk Management Framework.

Risk assessments can play an important role in security control selection processes, particularly during the application of tailoring guidance, which includes security control supplementation. Related controls: RA-2, PM- 9.

Control
Number
RA-5
Title Vulnerability Scanning

DHCS & CDSS
Requirement
The organization must:
a. Scan for vulnerabilities in the information system and hosted applications at a minimum of a monthly basis and when new vulnerabilities potentially affecting the system/applications are identified and reported;
b. Employ vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:

1. Enumerating platforms, software flaws, and improper configurations; a. Analyze vulnerability scan reports and results from security control assessments; b. Remediate legitimate vulnerabilities within organization defined time periods in accordance with an organizational assessment of risk; and MA-063-25010752 Page 36 of 58 December 8, 2025
c. Share information obtained from the vulnerability scanning process and security control assessments with all impacted system owners to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).

Supplemental
Guidance (from
NIST 800-53)
Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example:
(i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA- 2, RA-3, SA-11, SI-2.

14. Security Assessment and Authorization (CA)
Control
Number
CA-2
Title Security Assessments

DHCS & CDSS
Requirement
The organization must:
a. Develops a security assessment plan that describes the scope of the assessment including:

1. Security controls and control enhancements under assessment;

2. Assessment procedures to be used to determine security control effectiveness; and

3. Assessment environment, assessment team, and assessment roles and responsibilities;
b. Assesses the security controls in the information system and its environment of operation wit organization-defined frequency to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements;
c. Produces a security assessment report that documents the results of the assessment; and d. Provides the results of the security control assessment to organization-defined individuals or roles.

MA-063-25010752 Page 37 of 58 December 8, 2025
Supplemental
Guidance (from
NIST 800-53)
Organizations assess security controls in organizational information systems and the environments in which those systems operate as part of: (i) initial and ongoing security authorizations; (ii) FISMA annual assessments; (iii) continuous monitoring; and (iv) system development life cycle activities. Security assessments: (i) ensure that information security is built into organizational information systems; (ii) identify weaknesses and deficiencies early in the development process; (iii) provide essential information needed to make risk-based decisions as part of security authorization processes; and (iv) ensure compliance to vulnerability mitigation procedures. Assessments are conducted on the implemented security controls from Appendix F (main catalog) and Appendix G (Program Management controls) as documented in System Security Plans and Information Security Program Plans. Organizations can use other types of assessment activities such as vulnerability scanning and system monitoring to maintain the security posture of information systems during the entire life cycle.

Security assessment reports document assessment results in sufficient detail as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements. The FISMA requirement for assessing security controls at least annually does not require additional assessment activities to those activities already in place in organizational security authorization processes. Security assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of security authorization decisions are provided to authorizing officials or authorizing official designated representatives.

To satisfy annual assessment requirements, organizations can use assessment results from the following sources: (i) initial or ongoing information system authorizations; (ii) continuous monitoring; or (iii) system development life cycle activities. Organizations ensure that security assessment results are current, relevant to the determination of security control effectiveness, and obtained with the appropriate level of assessor independence. Existing security control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. Subsequent to initial authorizations and in accordance with OMB policy, organizations assess security controls during continuous monitoring. Organizations establish the frequency for ongoing security control assessments in accordance with organizational continuous monitoring strategies. Information Assurance Vulnerability Alerts provide useful examples of vulnerability mitigation procedures. External audits (e.g., audits by external entities such as regulatory agencies) are outside the scope of this control. Related controls: CA-5, CA-6, CA-7, PM-9, RA-5, SA-11, SA-12, SI-4.

Control
Number
CA-3
Title System Interconnections

DHCS & CDSS
Requirement
The organization must:
a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements; b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and
c. Reviews and updates Interconnection Security Agreements [Assignment: organizationdefined frequency].

MA-063-25010752 Page 38 of 58 December 8, 2025
Supplemental
Guidance (from
NIST 800-53)
This control applies to dedicated connections between information systems (i.e., system interconnections) and does not apply to transitory, user-controlled connections such as email and website browsing. Organizations carefully consider the risks that may be introduced when information systems are connected to other systems with different security requirements and security controls, both within organizations and external to organizations. Authorizing officials determine the risk associated with information system connections and the appropriate controls employed. If interconnecting systems have the same authorizing official, organizations do not need to develop Interconnection Security Agreements. Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and nonfederal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls.

Related controls: AC-3, AC-4, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4.

Control
Number
CA-7
Title Continuous Monitoring

DHCS & CDSS
Requirement
The organization must develop a continuous monitoring strategy and implement a continuous monitoring program that includes:
a. Establishment of PII security controls to be monitored; c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;
d. Ongoing security status monitoring of PII security controls in accordance with the organizational continuous monitoring strategy;
e. Correlation and analysis of security-related information generated by assessments and monitoring;
f. Response actions to address results of the analysis of security-related information; and g. Reporting the security status of organization and the information system to organizationdefined personnel or roles and to DHCS and CDSS when requested.

Supplemental
Guidance (from
NIST 800-53)
Continuous monitoring programs facilitate ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions. The terms continuous and ongoing imply that organizations assess/analyze security controls and information security- related risks at a frequency sufficient to support organizational risk-based decisions. The results of continuous monitoring programs generate appropriate risk response actions by organizations.

Continuous monitoring programs also allow organizations to maintain the security authorizations of information systems and common controls over time in highly dynamic environments of operation with changing mission/business needs, threats, vulnerabilities, and technologies.

Having access to security-related information on a continuing basis through reports/dashboards MA-063-25010752 Page 39 of 58 December 8, 2025
gives organizational officials the capability to make more effective and timely risk management decisions, including ongoing security authorization decisions. Automation supports more frequent updates to security authorization packages, hardware/software/firmware inventories, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely.

Continuous monitoring activities are scaled in accordance with the security categories of information systems. Related controls: CA-2, CA-5, CA-6, CM-3, CM-4, PM-6, PM-9, RA-5, SA- 11, SA-12, SI-2, SI-4.

Control
Number
CA-8
Title Penetration Testing

DHCS & CDSS
Requirement
The organization must conduct penetration testing annually on systems storing, processing, or transmitting PII.

Supplemental
Guidance (from
NIST 800-53)
Penetration testing is a specialized type of assessment conducted on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Such testing can be used to either validate vulnerabilities or determine the degree of resistance organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills). Penetration testing attempts to duplicate the actions of adversaries in carrying out hostile cyber-attacks against organizations and provides a more in- depth analysis of security-related weaknesses/deficiencies. Organizations can also use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls. A standard method for penetration testing includes, for example:
(i) pretest analysis based on full knowledge of the target system; (ii) pretest identification of potential vulnerabilities based on pretest analysis; and (iii) testing designed to determine exploitability of identified vulnerabilities. All parties agree to the rules of engagement before the commencement of penetration testing scenarios. Organizations correlate the penetration testing rules of engagement with the tools, techniques, and procedures that are anticipated to be employed by adversaries carrying out attacks. Organizational risk assessments guide decisions on the level of independence required for personnel conducting penetration testing. Related control: SA-12.

15. System and Communications Protection (SC)
Control
Number
SC-7
Title Boundary Protection

DHCS & CDSS
Requirement
The organization information system must:
a. Monitor and control communications at the external boundary of the system and at key internal boundaries within the system;
b. Implements subnetworks for publicly accessible system components that are physically and logically separated from internal organizational networks; and MA-063-25010752 Page 40 of 58 December 8, 2025
c. Connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.

Supplemental
Guidance (from
NIST 800-53)
Managed interfaces include, for example, gateways, routers, firewalls, guards, network-based malicious code analysis and virtualization systems, or encrypted tunnels implemented within a security architecture (e.g., routers protecting firewalls or application gateways residing on protected subnetworks). Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational information systems includes, for example, restricting external web traffic to designated web servers within managed interfaces and prohibiting external traffic that appears to be spoofing internal addresses. Organizations consider the shared nature of commercial telecommunications services in the implementation of security controls associated with the use of such services. Commercial telecommunications services are commonly based on network components and consolidated management systems shared by all attached commercial customers, and may also include third party-provided access lines and other service elements.

Such transmission services may represent sources of increased risk despite contract security provisions. Related controls: AC-4, AC-17, CA-3, CM-7, CP-8, IR-4, RA-3, SC-5, SC-13.

Control
Number
SC-8
Title Transmission Confidentiality and Integrity

DHCS & CDSS
Requirement
The organization information system must:

Protect the confidentiality of transmitted information.

Supplemental
Guidance (from
NIST 800-53)
This control applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and/or integrity of organizational information can be accomplished by physical means (e.g., by employing protected distribution systems) or by logical means (e.g., employing encryption techniques).

Organizations relying on commercial providers offering transmission services as commodity services rather than as fully dedicated services (i.e., services which can be highly specialized to individual customer needs), may find it difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission confidentiality/integrity. In such situations, organizations determine what types of confidentiality/integrity services are available in standard, commercial telecommunication service packages. If it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, organizations implement appropriate compensating security controls or explicitly accept the additional risk.

Related controls: AC-17, PE-4.

Control
Number
SC-8(1)
Title Transmission Confidentiality and Integrity | Cryptographic or Alternate Physical Protection DHCS & CDSS The organization information system must implement cryptographic mechanisms to prevent MA-063-25010752 Page 41 of 58 December 8, 2025
Requirement unauthorized disclosure of information during transmission.

Supplemental
Guidance (from
NIST 800-53)
Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Alternative physical security safeguards include, for example, protected distribution systems. Related control: SC-13.

Control
Number SC-13
Control Number SC-13
Title Cryptographic Protection
CDSS
Requirement
The organization information system must implement FIPS 140-3 compliant encryption modules in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Supplemental
Guidance (from
NIST 800-53)
Cryptography can be employed to support a variety of security solutions including, for example, the protection of classified and Controlled Unclassified Information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals.

Cryptography can also be used to support random number generation and hash generation.

Generally applicable cryptographic standards include FIPS-validated cryptography and NSAapproved cryptography. This control does not impose any requirements on organizations to use cryptography. However, if cryptography is required based on the selection of other security controls, organizations define each type of cryptographic use and the type of cryptography required (e.g., protection of classified information: NSA-approved cryptography; provision of digital signatures: FIPS-validated cryptography). Related controls: AC-2, AC-3, AC-7, AC-17, AC- 18, AU-9, AU-10, CM-11, CP-9, IA-3, IA-7, MA-4, MP-2, MP-4, MP-5, SA-4, SC-8, SC12, SC-28, SI-7.

Control
Number
SC-28
Title Protection of Information at Rest

DHCS & CDSS
Requirement
The organization information system must: Protect the confidentiality of PII at rest.

Supplemental
Guidance (from
NIST 800-53)
This control addresses the confidentiality and integrity of information at rest and covers user information and system information. Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. System-related information requiring protection includes, for example, configurations or rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content.

Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing Write-Once-Read-Many (WORM) technologies. Organizations may also employ other security controls including, for example, secure off-line storage in lieu of online storage when adequate protection of information at rest cannot otherwise be achieved and/or continuous monitoring to identify malicious code at rest.

Related controls: AC-3, AC-6, CA-7, CM-3, CM-5, CM-6, PE-3, SC-8, SC-13, SI-3, SI-7.

16. System and Information Integrity (SI)
MA-063-25010752 Page 42 of 58 December 8, 2025
Control
Number
SI-2
Title Flaw Remediation

DHCS & CDSS
Requirement
The organization must:
a. Identify, report, and correct information system flaws; b. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
c. Installs security-relevant software and firmware updates, within acceptable organization standards, of the release of the updates; and
d. Incorporatesflaw remediation into the organizational configuration management process.

Supplemental
Guidance (from
NIST 800-53)
Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures.

Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical, for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security- relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related controls: CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11.

Control
Number
SI-3
Title Malicious Code Protection

DHCS & CDSS
Requirement
The organization must:
a. Employ malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code;
b. Update malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures; MA-063-25010752 Page 43 of 58 December 8, 2025
c. Configure malicious code protection mechanisms to:

1. Perform periodic scans of the information system and real-time scans of files from external sources at the endpoint and network entry/exit points as the files are downloaded, opened, or executed in accordance with organizational security policy; and

2. Block malicious code or quarantine malicious code, and send alert to administrator for incident handling in response to malicious code detection; and d. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system Supplemental
Guidance (from
NIST 800-53)
Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers, proxy servers, remote-access servers, workstations, notebook computers, and mobile devices. Malicious code includes, for example, viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode), contained within compressed or hidden files, or hidden in files using steganography.

Malicious code can be transported by different means including, for example, web accesses, electronic mail, electronic mail attachments, and portable storage devices. Malicious code insertions occur through the exploitation of information system vulnerabilities. Malicious code protection mechanisms include, for example, anti-virus signature definitions and reputationbased technologies. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Pervasive configuration management and comprehensive software integrity controls may be effective in preventing execution of unauthorized code. In addition to commercial off-the-shelf software, malicious code may also be present in custom-built software. This could include, for example, logic bombs, back doors, and other types of cyber attacks that could affect organizational missions/business functions. Traditional malicious code protection mechanisms cannot always detect such code. In these situations, organizations rely instead on other safeguards including, for example, secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to help ensure that software does not perform functions other than the functions intended.

Organizations may determine that in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, actions in response to detection of malicious downloads, and/or actions in response to detection of maliciousness when attempting to open or execute files.

Related controls: CM-3, MP-2, SA-4, SA-8, SA-12, SA-13, SC-7, SC-26, SC-44, SI-2, SI-4, SI7.

Control
Number
SI-4
Title Information System Monitoring

DHCS & CDSS
Requirement
The organization must:
a. Monitor the information system to detect:

1. Attacks and indicators of potential attacks in accordance with organization-defined monitoring objectives; and

2. Unauthorized local, network, and remote connections; b. Identify unauthorized use of the information system through organization-defined MA-063-25010752 Page 44 of 58 December 8, 2025
techniques and methods;
c. Deploy monitoring devices:

1. Strategically within the information system to collect organization-determined essential information; and

2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;
d. Protect information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;
e. Heighten the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information; Relevant risk would apply to anything impacting the confidentiality integrity or availability of the information system. f. Obtain legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and
g. Provides organization-defined information system monitoring information to organization- defined personnel and DHCS and CDSS as needed.

Supplemental
Guidance (from
NIST 800-53)
Information system monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. Organizations can monitor information systems, for example, by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. Information system monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include, for example, selected perimeter locations and near server farms supporting critical applications, with such devices typically being employed at the managed interfaces associated with controls SC-7 and AC-17.

Einstein network monitoring devices from the Department of Homeland Security can also be included as monitoring devices. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of information systems to support such objectives. Specific types of transactions of interest include, for example, Hyper Text Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. Information system monitoring is an integral part of organizational continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Related controls: AC-3, AC-4, AC-8, AC17, AU-2, AU-6, AU-7, AU-9, AU-12, CA-7, IR-4, PE-3, RA-5, SC-7, SC-26, SC-35, SI-3, SI7.

Control SI-4(5)
MA-063-25010752 Page 45 of 58 December 8, 2025
Number
Title Information System Monitoring | System Generated Alerts

DHCS & CDSS
Requirement
The information system alerts County Worker when the following indications of compromise or potential compromise occur. County will notify Contractor as needed.

1. Protected system files or directories have been modified without notification from the appropriate change/configuration management channels.

2. System performance indicates resource consumption that is inconsistent with expected operating conditions.

3. Auditing functionality has been disabled or modified to reduce audit visibility.

4. Audit or log records have been deleted or modified without explanation.

5. The system is raising alerts or faults in a manner that indicates the presence of an abnormal condition.

6. Resource or service requests are initiated from clients that are outside of the expected client membership set.

7. The system reports failed logins or password changes for administrative or key service accounts.

8. Processes and services are running that are outside of the baseline system profile.

9. Utilities, tools, or scripts have been saved or installed on production systems without clear indication of their use or purpose.

Supplemental
Guidance (from
NIST 800-53)
Alerts may be generated from a variety of sources, including, for example, audit records or inputs from malicious code protection mechanisms, intrusion detection or prevention mechanisms, or boundary protection devices such as firewalls, gateways, and routers. Alerts can be transmitted, for example, telephonically, by electronic mail messages, or by text messaging.

Organizational personnel on the notification list can include, for example, system administrators, mission/business owners, system owners, or information system security officers. Related controls: AU-5, PE-6.

Control
Number
SI-4(13)
Title Information System Monitoring | Analyze Traffic / Event Patterns

DHCS & CDSS
Requirement
The organization must:
a. Analyzes communications traffic/event patterns for the information system; b. Develops profiles representing common traffic patterns and/or events; and c. Uses the traffic/event profiles in tuning system-monitoring devices to reduce the number of false positives and the number of false negatives.

Supplemental
Guidance (from
NIST 800-53)
None

17. System and Services Acquisition (SA)
Control
Number
SA-9
MA-063-25010752 Page 46 of 58 December 8, 2025
Title External Information System Services

DHCS & CDSS
Requirement
The organization must:
a. Require that providers of external information system services comply with organizational information security requirements and employ organization-defined security controls in accordance with DHCS and CDSS PSA, applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance; b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and
c. Employs organization-defined processes, methods, and techniques to monitor security control compliance by external service providers on an ongoing basis.

The state organization will provide its contractors and agents with copies of the Agreement, related IEAs, and all related attachments before initial disclosure of PII to such contractors and agents. Prior to signing the Agreement, and thereafter at DHCS’s and CDSS’s request, the state organization will obtain from its contractors and agents a current list of the employees of such contractors and agents with access to PII and provide such lists to DHCS and CDSS.

Supplemental
Guidance (from
NIST 800-53)
External information system services are services that are implemented outside of the authorization boundaries of organizational information systems. This includes services that are used by, but not a part of, organizational information systems. FISMA and OMB policy require that organizations using external service providers that are processing, storing, or transmitting federal information or operating information systems on behalf of the federal government ensure that such providers meet the same security requirements that federal agencies are required to meet. Organizations establish relationships with external service providers in a variety of ways including, for example, through joint ventures, business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, and supply chain exchanges.

The responsibility for managing risks from the use of external information system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a level of confidence that each participating provider in the potentially complex consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust varies based on the relationships between organizations and the external providers. Organizations document the basis for trust relationships so the relationships can be monitored over time. External information system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define expectations of performance for security controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance. Related controls: CA-3, IR-7, PS-7.

Control
Number
SA-11
Title Developer Security Testing And Evaluation

DHCS & CDSS
Requirement
The organization must require the developer of the information system, system component, or information system service to:
a. Create and implement a security assessment plan;
b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage]; MA-063-25010752 Page 47 of 58 December 8, 2025
c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation;
d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during security testing/evaluation Supplemental
Guidance (from
NIST 800-53)
Supplemental Guidance: Developmental security testing/evaluation occurs at all post-design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2.
[Remainder of page intentionally left blank]
MA-063-25010752 Page 48 of 58 December 8, 2025
B. Minimum Cloud Security Requirements
Contractor and any agents, subcontractors, and vendors storing PII in a cloud service must comply with the Cloud Computing Policy, State Administration Manual (SAM) Sections 4983-4983.1, and employ the capabilities in the Cloud Security Standard, SIMM 5315-B to protect information and systems in cloud services as outlined below.

1. Identify and classify assets to focus and prioritize efforts in aligning business needs and risk management.

2. Each information asset for which the Contractor entity has ownership responsibility shall be inventoried and identified to include the following:
a. Description and value of the information asset.
b. Owner of the information asset.
c. Custodians of the information asset.
d. Users of the information asset.
e. Classification of information.
f. FIPS Publication 199 categorization and level of protection (Low, Moderate, or High).
g. Importance of information assets to the execution of the Agency/state entity’s mission and program function.
h. Potential consequences and impacts if confidentiality, integrity, and availability of the information asset were compromised.

3. Security of cloud services stems from managing authentication and fine- grained authorization. To safeguard cloud systems, Contractor shall establish processes and procedures to ensure:
a. Maintenance of user identities, including both provisioning and de- provisioning; b. Enforcement of password policies or more advanced multifactor mechanisms to authenticate users and devices;
c. Management of access control rules, limiting access to the minimum necessary to complete defined responsibilities;
d. Separation of duties to avoid functional conflicts;
e. Periodic recertification of access control rules to identify those that are no longer needed or provide overly broad clearance;
f. Use of privileged accounts that can bypass security are restricted and audited; g. Systems to administer access based on roles are defined and installed; and h. Encryption keys and system security certificates are effectively generated, exchanged, stored and safeguarded.

4. Infrastructure protection controls limit the impact of unintended access or potential vulnerabilities. PaaS and SaaS resources may already have these controls implemented by the service provider. Contractor must configure information assets to provide only essential capabilities.

MA-063-25010752 Page 49 of 58 December 8, 2025

5. Contractor is entrusted with protecting the integrity and confidentiality of data processed by their information systems. Cloud technologies simplify data protection by providing managed data storage services with native protection and backup features, but these features must be configured and managed appropriately.

6. Detective controls identify potential security threats or incidents, supporting timely investigation and response. Contractor must continuously identify and remediate vulnerabilities.

7. Response controls enable timely event and incident response which is essential to reducing the impact if an incident were to occur. Compliance with incident management requirements as outlined in VII. Notification and Investigation of Breaches and Security Incidents.

8. Recover controls facilitate long-term recovery activities following events or incidents.

With cloud services, primarily SaaS solutions, the services provider hosts the data in its application, and unless properly planned and provisioned for in the contract with the service provider it may be difficult or impossible to obtain the data in a usable format at contract termination. Contractor must ensure agreements with cloud service providers include recover controls.

C. Minimum Necessary. Only the minimum necessary amount of PII required to perform required business functions applicable to the terms of this Agreement may be used, disclosed, copied, downloaded, or exported.

D. Transmission and Storage of PII. All persons that will be working with PII shall employ FIPS 140-2 or greater approved security functions as described in section 6.2.2 of NIST SP 800-140Cr1 encryption of PII at rest and in motion unless Contractor determines it is not reasonable and appropriate to do so based upon a risk assessment, and equivalent alternative measures are in place and documented as such. In addition, Contractor shall maintain, at a minimum, the most current industry standards for transmission and storage of County of Orange data and other confidential information.

E. DHCS Remote Work Policy. Contractor, its Contractor Workers and any agents, subcontractors, and vendors accessing PII pursuant to this PSA when working remotely, shall follow reasonable policies and procedures that are equivalent to or better than the DHCS Remote Work Policy, as published in Medi-Cal Eligibility Division Informational Letter (MEDIL) | 23-35E. Working remotely means working from a physical location not under the control of the person’s employer.

If DHCS changes the terms of the DHCS Remote to Work Policy, DHCS will, as soon as reasonably possible, supply copies to the County of Orange or its designee as well as DHCS’ proposed target date for compliance. For a period of 30 days, DHCS will accept input from the County of Orange or its designee on the proposed changes. DHCS will issue a new policy in a future MEDIL. If the Contractor is unable to comply with these standards, the Contractor will be asked to develop a Plan of Action and Milestones (POA&M) MA-063-25010752 Page 50 of 58 December 8, 2025
detailing a concrete roadmap to becoming fully compliant with the policy’s standard. The POA&M must be provided to the County of Orange for review and approval. Any Contractor who is under a POA&M will be required to provide quarterly updates to the County of Orange until the fully compliant.

VI. AUDIT CONTROLS
A. Audit Control Mechanisms. The Contractor shall ensure audit control mechanisms are in place that are compliant with the Technical Security Controls within Section V of this Agreement.

B. Anomalies. When the Contractor or the County of Orange suspects MEDS usage anomalies, the Contractor shall work with the County of Orange to investigate the anomalies and report conclusions of such investigations and remediation to the County of Orange.

C. Notification to the County of Orange in event Contractor is subject to other Audit. If Contractor is the subject of an audit, compliance review, investigation, or any proceeding that is related to the performance of its obligations pursuant to this Agreement, or is the subject of any judicial or administrative proceeding alleging a violation of law related to the privacy and security of PII, including but not limited to Medi-Cal PII, the Contractor shall promptly notify the County of Orange unless it is legally prohibited from doing so.

VII. PAPER, RECORD, AND MEDIA CONTROLS
A. Supervision of Data. PII shall not be left unattended at any time, unless it is locked in a file cabinet, file room, desk or office at the individual’s place of employment or at home when working remotely. Unattended means that information may be observed by an individual not authorized to access the information.

B. Data in Vehicles. The Contractor shall have policies that include, based on applicable risk factors, a description of the circumstances under which the Contractor Workers can transport PII, as well as the physical security requirements during transport. A Contractor that chooses to permit its Contractor Workers to leave records unattended in vehicles, shall include provisions in its policies to provide that the PII is stored in a non-visible area such as a trunk, that the vehicle is locked, and that under no circumstances permit PII to be left unattended in a vehicle overnight or for other extended periods of time.

C. Public Modes of Transportation. PII shall not be left unattended at any time in airplanes, buses, trains, etc., inclusive of baggage areas. This should be included in training due to the nature of the risk.

D. Escorting Visitors. Visitors to areas where PII is contained shall be escorted, and PII shall be kept out of sight while visitors are in the area.

MA-063-25010752 Page 51 of 58 December 8, 2025
E. Confidential Destruction. PII shall be disposed of through confidential means, such as cross cut shredding or pulverizing.

F. Removal of Data. PII shall not be removed from the premises of Contractor except for justifiable business purposes.

G. Faxing.

1. Faxes containing PII shall not be left unattended and fax machines shall be in secure areas.

2. Faxes shall contain a confidentiality statement notifying persons receiving faxes in error to destroy them and notify the sender.

3. Fax numbers shall be verified with the intended recipient before sending the fax.

H. Mailing.

1. Mailings containing PII shall be sealed and secured from damage or inappropriate viewing of PII to the extent possible.

2. Mailings that include 500 or more individually identifiable records containing PII in a single package shall be sent using a tracked mailing method that includes verification of delivery and receipt.

VIII. NOTIFICATION AND INVESTIGATION OF BREACHES AND SECURITY

INCIDENTS
During the term of this Agreement, the Contractor agrees to implement reasonable systems for the discovery and prompt reporting of any breach or security incident, and to take the following steps:

A. Initial Notice to the County of Orange:

The Contractor shall notify the County of Orange using County online incident reporting portal of any suspected security incident, intrusion, or unauthorized access, use, or disclosure of PII or potential loss of PII. When making notification, the following applies:

1. If a suspected security incident involves PII provided or verified by SSA, the Contractor shall immediately notify the County of Orange upon discovery. For more information on SSA data, please see the Definition section of this Agreement.

2. If a suspected security incident does not involve PII provided or verified by SSA, the Contractor shall notify the County of Orange promptly and in no event later than one working day of discovery of:

MA-063-25010752 Page 52 of 58 December 8, 2025
a. Unsecured PII if the PII is reasonably believed to have been accessed or acquired by an unauthorized person;
b. Any suspected security incident which risks unauthorized access to PII and/or; c. Any intrusion or unauthorized access, use, or disclosure of PII in violation of this Agreement; or
d. Potential loss of PII affecting this Agreement.

Notice to County shall include all information known at the time the incident is reported.

Contractor shall submit notice via the link County of Orange Incident Reporting Portal and email contact using the information listed in subsection H..

If County online incident reporting portal is unavailable, notice to County can instead be made via email using the County Privacy Incident Report (PIR) form, which the County will coordinate with Contractor.

A breach shall be treated as discovered by the Contractor 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 the Contractor.

Upon discovery of a breach, security incident, intrusion, or unauthorized access, use, or disclosure of PII, the Contractor shall take:

1. Prompt corrective action to mitigate any risks or damages involved with the security incident or breach; and

2. Any action pertaining to such unauthorized disclosure required by applicable Federal and State laws and regulations.

B. Investigation of Security Incident or Breach. The Contractor shall immediately investigate such a security incident, breach, or unauthorized use of PII.

C. Complete Report. Within 10 working days of the discovery the Contractor shall provide any additional information related to the incident requested by the County of Orange. The Contractor shall make reasonable efforts to provide the County of Orange with such information.

The complete report must include an assessment of all known factors relevant to a determination of whether a breach occurred under applicable federal and state laws. The report shall include a full, detailed corrective action plan (CAP) including mitigating measures that were taken to halt and/or contain the improper use or disclosure.

If the County of Orange requests additional information related to the incident, the Contractor shall make reasonable efforts to provide the County of Orange with such information. If necessary, the Contractor shall submit an updated report with revisions and/or additional information after the Completed Report has been provided. The County of Orange will review and determine whether a breach occurred and whether individual MA-063-25010752 Page 53 of 58 December 8, 2025
notification is required. The County of Orange will maintain the final decision making over a breach determination.

D. Notification of Individuals. If the cause of a breach is solely attributable to the Contractor or its agents, Contractor shall notify individuals accordingly and shall pay all costs of such notifications as well as any costs associated with the breach. The notifications shall comply with applicable federal and state law. The County of Orange and DHCS shall approve the time, manner, and content of any such notifications and their review and approval must be obtained before the notifications are made. The County of Orange and the Contractor shall work together to ensure that notification of individuals is done in compliance with statutory deadlines within applicable federal and state law.

If the cause of a breach is solely attributable to the County of Orange, the County of Orange shall pay all costs of such notifications as well as any costs associated with the breach. If there is any question as to whether the County of Orange or the Contractor is responsible for the breach or the County of Orange and the Contractor acknowledge that both are responsible for the breach, the County of Orange and the Contractor shall jointly determine responsibility for purposes of allocating the costs.

1. All notifications (regardless of breach status) regarding beneficiaries’ PII shall comply with the requirements set forth in Section 1798.29 of the California Civil Code and Section 17932 of Title 42 of United States Code, inclusive of 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 daysfrom discovery.

E. Responsibility for Reporting of Breaches

1. Breach Attributable to Contractor. If the cause of a breach of PII is attributable to the Contractor or its agents, subcontractors, or vendors, the Contractor shall be responsible for all required reporting of the breach.

2. Breach Attributable to the County of Orange. If the cause of the breach is attributable to the County of Orange, the County of Orange shall be responsible for all required reporting of the breach.

F. Coordination of Reporting. When applicable law requires the breach be reported to a federal or state agency, or that notice be given to media outlets, the County of Orange and the Contractor shall coordinate to ensure such reporting is compliant with applicable law and prevent duplicate reporting and to jointly determine responsibility for purposes of allocating the costs of such reports, if any.

G. Submission of Sample Notification to Attorney General: If the cause of the breach is attributable to the Contractor or an agent, subcontractor, or vendor of the Contractor and if notification to more than 500 individuals is required pursuant to California Civil Code section 1798.29, regardless of whether Contractor is considered only a custodian and/or non-owner of the PII, Contractor shall, at its sole expense and at the sole election of the MA-063-25010752 Page 54 of 58 December 8, 2025
County of Orange, either:

1. Electronically submit a single sample copy of the security breach notification, excluding any personally identifiable information, to the Attorney General pursuant to the format, content, and timeliness provisions of Section 1798.29, subdivision (e).

Contractor shall inform the County of Orange Privacy Officer of the time, manner, and content of any such submissions prior to the transmission of such submissions to the Attorney General; or

2. Cooperate with and assist the County of Orange in its submission of a sample copy of the notification to the Attorney General.

H. County of Orange Contact Information. The Contractor shall utilize the below contact information to direct all communication/notifications of breach and security incidents to the County of Orange. The County of Orange reserves the right to make changes to the contact information by giving written notice to the Contractor. Said changes shall not require an amendment to this Agreement or any other agreement into which it is incorporated.

County of Orange Breach and Security Incident Reporting Andrew Alipanah, MBA, CISSP
Chief Information Security Officer
County of Orange
Enterprise Privacy & Cybersecurity
721 S. Parker St., Ste. 200
Orange, CA 92868
Email: [email protected]
Telephone: (714) 567-7611
Linda Le, CHC, CHPC, CHP
County Privacy Officer
County of Orange
Enterprise Privacy & Cybersecurity
721 S. Parker St., Suite 200
Orange, CA 92868
Email: [email protected]
[email protected]
[email protected]
Telephone: (714) 834-4082
MA-063-25010752 Page 55 of 58 December 8, 2025
Karen Vu
Procurement Contract Manager, Senior
Contracts Services
County of Orange
Social Services Agency
500 N. State College Blvd.

Orange, CA 92868
Email: [email protected]
Telephone: 714-541-7785
Alin Buna
Procurement Contract Manager, Senior
Procurement Services
County of Orange
Social Services Agency
500 N. State College Blvd.

Orange, CA 92868
Email: [email protected]
Telephone: 714-541-7767
The preferred method of communication is email, when available. Do not include any PII unless requested by the County of Orange.

IX. RESERVED
The Contractor shall utilize the below contact information for any PSA-related inquiries or questions. The County of Orange reserves the right to make changes to the contact information by giving written notice to the Contractor. Said changes shall not require an amendment to this Agreement or any other agreement into which it is incorporated. Please use the contact information listed in Section X of this Agreement for any PII incident or breach reporting.

PSA Inquiries and Questions
County of Orange Social Services Agency
500 N. State College Blvd.

Orange, CA 92868
Email: [email protected]
X. COMPLIANCE WITH SSA AGREEMENT
The Contractor agrees to comply with applicable privacy and security requirements in the Computer Matching and Privacy Protection Act Agreement (CMPPA) between SSA and the California Health and Human Services Agency (CalHHS), in the Information Exchange Agreement (IEA) between SSA and DHCS and CDSS, and in the Electronic Information Exchange Security Requirements and Procedures for State and Local Agencies Exchanging Electronic Information with SSA (TSSR), which are incorporated into this Agreement within section V.

Technical Security Controls and Exhibit A (available upon request).

If there is any conflict between a privacy and security standard in the CMPPA, IEA or TSSR, and a standard in this Agreement, the most stringent standard shall apply. The most stringent standard means the standard which provides the greatest protection to PII.

If SSA changes the terms of its agreement(s) with DHCS and CDSS, the County of Orange will, as soon as reasonably possible after receipt from DHCS and CDSS, supply copies to the Contractor MA-063-25010752 Page 56 of 58 December 8, 2025
as well as DHCS’ and CDSS’ proposed target date for compliance. Once a target date for compliance is determined by SSA, the County of Orange will supply copies of the changed agreement to the Contractor after receipt from DHCS and CDSS, along with the compliance date expected by SSA. If the Contractor is not able to meet the SSA compliance date, the Contractor will be asked to develop a POA&M detailing a concrete roadmap to becoming fully compliant with the policy’s standard. The POA&M must be provided to the County of Orange for review and approval. Any Contractor who is under a POA&M will be required to provide quarterly updates to the County of Orange until the fully compliant.

A copy of Exhibit A can be requested by the Contractor from the County of Orange using the contact information listed in Section VIII.H of this Agreement.

XI. COMPLIANCE WITH DEPARTMENT OF HOMELAND SECURITY

AGREEMENT
The Contractor agrees to comply with substantive privacy and security requirements in the Computer Matching Agreement (CMA) between the Department of Homeland Security, United States Citizenship and Immigration Services (DHS-USCIS), DHCS and CDSS, which is hereby incorporated into this Agreement (Exhibit B) and available upon request. If there is any conflict between a privacy and security standard in the CMA and a standard in this Agreement, the most stringent standard shall apply. The most stringent standard means the standard which provides the greatest protection to PII.

If DHS-USCIS changes the terms of its agreement(s) with DHCS and CDSS, the County of Orange will, as soon as reasonably possible after receipt from DHCS and CDSS, supply copies to the Contractor as well as DHCS’ and CDSS’ proposed target date for compliance. Once a target date for compliance is determined by DHS-USCIS, the County of Orange will supply copies of the changed agreement to Contractor after receipt from DHCS and CDSS, along with the compliance date expected by DHS-USCIS. If the Contractor is not able to meet the DHS-USCIS compliance date, the POA&M must be provided to the County of Orange for review and approval. Any Contractor who is under a POA&M will be required to provide quarterly updates to the County of Orange until the fully compliant.

A copy of Exhibit B can be requested by the Contractor from the County of Orange using the contact information listed in Section VIII.H of this Agreement.

XII. CONTRACTOR’S AGENTS, SUBCONTRACTORS, AND VENDORS
The Contractor agrees to enter into written agreements with all agents, subcontractors and vendors that have access to Contractor PII. These agreements will impose, at a minimum, the same restrictions and conditions that apply to the Contractor with respect to PII upon such agents, subcontractors, and vendors. These shall include, (1) restrictions on disclosure of PII, (2) conditions regarding the use of appropriate administrative, physical, and technical safeguards to protect PII, and, where relevant, (3) the requirement that any breach, security incident, intrusion, or unauthorized access, use, or disclosure of PII be reported to the Contractor. If the agents, subcontractors, and vendors of Contractor access data provided to the County of Orange by DHCS MA-063-25010752 Page 57 of 58 December 8, 2025
and/or CDSS by SSA or DHS-USCIS, the Contractor shall also incorporate the Agreement’s Exhibits into each subcontract or subaward with agents, subcontractors, and vendors.

Contractors who would like assistance or guidance with this requirement are encouraged to coordinate with the County of Orange.

XIII. ASSESSMENTS AND REVIEWS
In order to enforce this Agreement and ensure compliance with its provisions and Exhibits, the Contractor agrees to assist the County of Orange in performing compliance assessments. These assessments may involve compliance review questionnaires, and/or review of the facilities, systems, books, and records of the Contractor, with reasonable notice from the County Orange.

Such reviews shall be scheduled at times that take into account the operational and staffing demands. The Contractor agrees to promptly remedy all violations of any provision of this Agreement and certify the same to the County of Orange in writing, or to enter into a POA&M with the County of Orange containing deadlines for achieving compliance with specific provisions of this Agreement.

XIV. ASSISTANCE IN LITIGATION OR ADMINISTRATIVE PROCEEDINGS In the event of litigation or administrative proceedings involving the County of Orange based upon claimed violations by the Contractor of the privacy or security of PII or of federal or state laws or agreements concerning privacy or security of PII, the Contractor shall make all reasonable effort to make itself and Contractor Workers assisting in the administration of Medi-Cal programs and using or disclosing PII available to the County of Orange at no cost to the County of Orange to testify as witnesses. The County of Orange shall also make all reasonable efforts to make itself and any subcontractors, agents, and employees available to the Contractor at no cost to the Contractor to testify as witnesses, in the event of litigation or administrative proceedings involving the Contractor based upon claimed violations by the County of Orange of the privacy or security of PII or of state or federal laws or agreements concerning privacy or security of PII.

XV. AMENDMENT OF AGREEMENT
The County of Orange and the Contractor acknowledge that federal and state laws relating to data security and privacy are rapidly evolving and that amendment of this Agreement may be required to ensure compliance with such changes. Upon request by the County of Orange, the Contractor agrees to promptly enter into negotiations with the County of Orange concerning an amendment to this Agreement as may be needed by changes in federal and state laws and regulations or NIST 800-53. In addition to any other lawful remedy, the County of Orange may terminate this Agreement upon 30 days written notice if the Contractor does not promptly agree to enter into negotiations to amend this Agreement when requested to do so or does not enter into an amendment that the County of Orange deems necessary.

XVI. TERMINATION
This Agreement shall terminate on September 1, 2028, regardless of the date the Agreement is MA-063-25010752 Page 58 of 58 December 8, 2025
executed by the parties. The parties can agree in writing to extend the term of the Agreement.

Contractor’s requests for an extension shall be approved by the County of Orange and limited to no more than a six (6) month extension.

A. Survival: All provisions of this Agreement that provide restrictions on disclosures of PII and that provide administrative, technical, and physical safeguards for the PII in the Contractor’s possession shall continue in effect beyond the termination or expiration of this Agreement and shall continue until the PII is destroyed or returned to the County of Orange.

XVII. TERMINATION FOR CAUSE
Upon the County of Orange’s knowledge of a material breach or violation of this Agreement by the Contractor, the County of Orange may provide an opportunity for the Contractor to cure the breach or end the violation and may terminate this Agreement if the Contractor does not cure the breach or end the violation within the time specified by the County of Orange. This Agreement may be terminated immediately by the County of Orange if the Contractor has breached a material term and the County of Orange determines, in its sole discretion, that cure is not possible or available under the circumstances. Upon termination of this Agreement, the Contractor shall return or destroy all PII in accordance with Section VII, above. The provisions of this Agreement governing the privacy and security of the PII shall remain in effect until all PII is returned or destroyed and the County of Orange receives a certificate of destruction. 1 CITY OF STANTON

REPORT TO THE CITY COUNCIL
TO: Honorable Mayor and Members of the City Council
DATE: January 27, 2026
SUBJECT: PRESENTATION ON UNFUNDED ACCRUED LIABILITY (UAL) REPORT IN BRIEF:

Staff will provide a presentation on the City’s and OCFA’s UAL.

RECOMMENDED ACTION:

1. City Council find that this item is not subject to California Environmental Quality Act (“CEQA”) pursuant to Sections 15378(b)(5) (Organizational or administrative activities of governments that will not result in direct or indirect physical changes in the environment); and

2. Receive and file.

BACKGROUND:

In response to a Council Member-initiated request on September 23, 2025, made by Mayor Shawver, the City Council directed staff to return with a presentation on UAL.

FISCAL IMPACT:

There is no fiscal impact associated with the recommended action.

ENVIRONMENTAL IMPACT :

This item is not subject to California Environmental Quality Act (“CEQA”) pursuant to Sections 15378(b)(5) (Organizational or administrative activities of governments that will not result in direct or indirect physical changes in the environment).

Item: 11A
Click here to return to the agenda.
2 LEGAL REVIEW:

None.

PUBLIC NOTIFICATION :

Through the normal agenda posting process.

STRATEGIC GOAL:

Goal 5. Maintain and promote a responsive, high-quality and transparent government.

Prepared by: Hannah Shin-Heydorn, City Manager
Approved by: Hannah Shin-Heydorn, City Manager
1 CITY OF STANTON

REPORT TO THE CITY COUNCIL
TO: Honorable Mayor and Members of the City Council
DATE: January 27, 2026
SUBJECT: CITY COUNCIL CONSIDERATION FOR APPOINTMENT TO FILL ONE (1)

VACANCY ON THE STANTON PUBLIC SAFETY COMMITTEE FOR

TERMS COINCIDING WITH THE CITY COUNCIL ELECTION
REPORT IN BRIEF:

Consideration for appointment to fill one (1) vacancy on the Stanton Public Safety Committee. There is currently one (1) vacancy within the Stanton Public Safety Committee due to an unexpected vacancy, with a term expiring in November 2026.

The Mayor/Council Member holding the seat number corresponding to the numbered seat on the Committee shall be responsible for the appointment of one Committee Member, with majority approval of the City Council. The terms of office shall coincide with the term of office of the Mayor or Council Member who made the appointment.

RECOMMENDED ACTION:

1. City Council find that this item is not subject to California Environmental Quality Act (“CEQA”) pursuant to Sections 15378(b)(5)(Organizational or administrative activities of governments that will not result in direct or indirect physical changes in the environment); and

2. Conduct an interview with each applicant; and

3. Make appointment to fill seat #2-Shawver on the Stanton Public Safety Committee.

BACKGROUND AND ANALYSIS:

Section 2.06.030 of the Stanton Municipal Code requires the submission of applications and interviews prior to appointment to any position. The open recruitment process to fill one (1) seat on the Stanton Public Safety Committee began on September 17, 2025, and remained open to the public for three months closing on December 12, 2025. Upon closing of the application process, applicants were notified and scheduled for interviews.

Item: 12A
Click here to return to the agenda.
2 Eligible Applicants:

1. Jonathan Bengco

2. Yahir Olguin-Rodriguez
The Stanton Public Safety Committee consists of five members who meet once every three months. As part of the strategic plan, the Stanton Public Safety Committee aligns the City with its core goal of “Providing a Safe Community”. The purpose of this committee is to foster and maintain effective interaction with law enforcement, fire services, emergency medical services and emergency preparedness.

Seat Status on the Stanton Public Safety Committee:

Commissioner Seat Number Term
Debi Grand #1 (Taylor) Expires: November, 2026
Vacant #2 (Shawver) Expires: November, 2026
Sandra L. Verdugo #3 (Torres) Expires: November, 2026
Douglas Makino #4 (Warren) Expires: November, 2028
Martin H. Ross #5 (Barrios) Expires: November, 2028
FISCAL IMPACT:

The Public Safety Committee consists of five members serving in a non-paid and voluntary position.

ENVIRONMENTAL IMPACT:

This item is not subject to California Environmental Quality Act (“CEQA”) pursuant to Sections 15378(b)(5)(Organizational or administrative activities of governments that will not result in direct or indirect physical changes in the environment).

LEGAL REVIEW:

None.

PUBLIC NOTIFICATION:

Notification through the regular agenda process.

STRATEGIC GOAL:

N/A
Prepared by: Patricia A. Vazquez, City Clerk
Approved by: Hannah Shin-Heydorn, City Manager
City Council Initiated Item
15D
_S hms mte  does not conti mn i sti \ reportẒ(
Item 15D:
“Discussion regarding Codification of City Flag.”
Item: 15D
Click here to return to the agenda.