rfq_13325_data_security_checklist_cprtraining.xlsx
XLSX spreadsheet 47 KB Posted
- Solicitation number
- BPM013325
- Issued by
- California
About this file
This is a Data Security Checklist for the County of San Diego's procurement of online software license subscriptions for self-directed CPR training. The document serves as a comprehensive security assessment tool designed to evaluate cloud-based solutions and vendors against the County's baseline security requirements. The checklist addresses data classification, identification of data types handled by the solution, vendor security capabilities, and compliance with federal and state regulations including HIPAA, IRS Publication 1075 (Federal Tax Information), Payment Card Industry standards, Criminal Justice Information requirements, and Automated Clearing House protocols. The evaluation process requires vendors to complete multiple assessment tabs based on their solution's data classification level: Open to Public, Sensitive, or Confidential. County departments must identify the specific data classification and associated data types before vendor responses are solicited, with additional review by the County Chief Information Security Officer required for solutions handling Criminal Justice Information or Payment Card Industry data.
The checklist incorporates security frameworks from NIST publications (SP 800-53, 800-125, 800-145, 800-146, 800-144, and 800-37 Rev 2) and establishes a moderate baseline of security requirements across multiple control domains including access control, audit and accountability, configuration management, contingency planning, identification and authentication, incident response, risk assessments, system and services acquisition, system and communications protection, and system and information integrity. Vendors must provide SOC 2 Type II audit reports for any Sensitive or Confidential data classification, demonstrate support for Single Sign-On integration with the County's identity provider, maintain daily backup solutions with a minimum 180-day retention period, implement annual penetration testing and weekly vulnerability scanning, remediate high-severity vulnerabilities within 30 days, and ensure all data processing and storage occurs within United States geographic boundaries. The document was most recently updated on December 16, 2025, reflecting evolving security standards and requirements including newly added Single Sign-On and Multi-Factor Authentication frequently asked questions.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| rfq_13325.pdf | ||
| rfq_13325_it_requirements_cprtraining.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Revision History
| Revision Date | Revised By | Comments | Version |
| 4/25/22 | Chad Vargason | Updated FTI Tab to reflect updated IRS1075 requirements | 1 |
| 4/25/22 | Chad Vargason | Added Department Questionnaire Worksheet | 1 |
| 4/25/22 | Chad Vargason | Added Cover Sheet | 1 |
| 4/26/22 | Chad Vargason | Modified Cover Sheet | 2 |
| 4/26/22 | Chad Vargason | Modified Open to public | 2 |
| 4/26/22 | Chad Vargason | Removed Data Type Questions and consolidated to classifications tab | 2 |
| 4/27/22 | Felicia Walton | Edited text, layout and formatting | 2.1 |
| 7/13/22 | Chad Vargason | Added question to cover sheet for Cloud Service Provider | 2.2 |
| 7/2/22 | Chad Vargason | Removed P1/P2 App Priority Question | 2.3 |
| 9/29/22 | Chad Vargason | Updated line 17 of Moderate Baseline Requirements tab | 2.4 |
| 1/11/23 | Felicia Walton | Updated line 37 on the Cover Sheet tab to indicate ITMC approval not required for renewals | 2.5 |
| 11/7/23 | Felicia Walton | Added rows 27-29 | 2.6 |
| 5/21/24 | Felicia Walton | Added rows 10-11 on Open to Public tab | 2.7 |
| 3/7/25 | Chad Vargason | Added SOC Comments to instructions tab | 2.8 |
| 5/16/25 | Chad Vargason | Updated intructions tab, Data Classification tab. Updated open to public tab requirements. Updated Moderate tab requirements. Updated Sensitive PII Tab requirements. Updated the EPHI HIPAA Tab and ACH NACHA Tab with updated requirements and removed CORI CLETS CJIS tab | 2.9 |
| 6/25/25 | Aaron Turner | Updated instructions. Added tab colors in alignment with responsible party/roles. | 3 |
| 12/9/25 | Chad Vargason | Updated Instructions tab and added SSO MFA FAQs and updated Data Classifications tab | 3.1 |
| 12/16/25 | Felicia Walton | Removed rows 38-43 on the Cover Sheet that referenced ITMC. | 3.2 |
Instructions
| Responsible Party | Step | Instructions |
| County Department | 1 | Fill out the Cover Sheet then have vendor supply responses to applicable tabs for their cloud solution |
| County Department | 2 | Identify the Data Classification (Open to Public, Sensitive, or Confidential) and Data Type (Sensitive PII, EPHI HIPAA, CJIS, ACH NACHA, PCI) using the Data Classifications tab. If the Data Classifcation is Open to Public, complete the Open to Public tab only and submit to TPA. If the Data Classification is Sensitive or Confidential move to step 2. |
If the data classification includes CJI or PCI, please contact the County CISO for review and requirements.
| Vendor | 3 | Based on the data classification, complete the moderate baseline requirements tab plus appropriate data type tabs. Please have the prospective vendor select "Yes or No" indicating whether they can comply with the requirement. For every "No", please include in the "exceptions explanation" column why the requirement cannot be met. |
| Vendor / County Department | 3 | If the data classification is Sensitive or Confidential, a SOC 2 Type 2 Report is required at procurement and annually thereafter. For vendors that do not perform SOC2 audits please contact the County CISO for review. Complementary User Entity Controls if applicable should be implemented. |
| The Requirements are based on the following resources, as updates to these sources are published, our requirements will be updated: | ||
| ▪ NIST SP 800-53 Rev. 5, Security and Privacy Controls for Federal Information Systems and Organizations | ||
| ▪ NIST SP 800-125 Gude to Security for Full Virtualization Technologies, January 2011 | ||
| ▪ NIST SP 800-145, The NIST Definition of Cloud Computing, September 2011 | ||
| ▪ NIST SP 800-146, Cloud Computing Synopsis and Recommendations, May 2012 | ||
| ▪ NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing, Dec 2011 | ||
| ▪ NIST SP 800-37 Rev 2. Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy | ||
| ▪ IRS Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies November 2021) |
SSO MFA FAQs
| Responsible Party | Step | Instructions | Requirement |
| County Department | 1 | If not able to able to implement SSO at the time of go live and are approved for an SSO Temp Waiver, departments will be expected to implement a strong user name and complex password that adhere to county policy. | Enforce Password History - 10 passwords remembered Maximum Password Age 90 Days Minimum Password Age 1 Days Minimum Password Length 8 characters Password must meet complexity requirements - enabled, Account lockout threshold 5 bad invalid attempts Account lockout duration 15 minutes |
| County Department/Vendor | 2 | All application local accounts not using SSO must be disabled and terminated in the application when personnel transfer out of the department and or if they terminate employment. This applies to contractors and sub-contractors that the department is managing the access for. | If not using SSO, Application local user accounts are required to be disabled, terminated, when personnel terminate or transfer and no logner require access to the application. Departments who administer the application accounts will use the schedule 28 report monthly to validate active and not active users. |
| County Department | 3 | If not able to able to implement SSO and mfa is avaiable, departments are to enable MFA on the application local accounts | MFA must be implemented for any application local account if available |
| County Department/Vendor | 4 | If a possible user account compromise, departments administering user access must reset the password and or disable the account(s) impacted and report incident to CTO Security immediately or County CISO | Compromised user account passwords must be reset at time of discovery or disabled until confirmed contained and incidents must be reported to county cto security and or county CISO at CTO office |
Data Classifications
| Please Reference CAO Policy 0400-11 COUNTY INFORMATION – CLASSIFICATION, PROTECTION LEVEL, AND PROPER SECURITY |
| County Information shall be classified in one of three classifications Open to public, Sensitve, Confidential |
| The County has developed data classification guidelines to assist in determining the security, protection and handling protocol for the different types of County Information. County Information is classified based on legal and regulatory protection requirements from unauthorized disclosure and the criticality of the information for conducting County business. |
Once information is classified, the proper security controls are then determined. Separate and apart from legal classifications, a County appointed information owner may require additional or special authorization for County information because of its value and sensitivity. Some information may have a higher sensitivity to loss or disclosure and/or have an adverse impact to the County if improperly safeguarded, or is misused, mismanaged or disclosed without proper authorization. The County has established policies and procedures to protect the confidentiality, integrity and availability of County information. Departmental procedures may increase security controls as needed. In the performance of regular duties and assignments, authorized users shall be familiar with and observe the policies and procedures governing County information and the information systems for which information resides.
All user access to County Information and Information Systems shall be provided on a need-to-know basis to protect the information from unauthorized disclosure, damage, modification, or misuse.
| “County Information” shall mean all information, data, records and documents, of any kind, including but not limited to “public records” as defined by the California Public Records Act, created, stored, contained or transmitted on County Information Systems. “Information Owner” shall mean the County department, office, agency or organization that is accountable for specified information and responsibility for establishing the criteria for its creation, collection, controls, processing, access, dissemination, retention, and disposal. |
| Information System security controls and protection levels shall be maintained to the highest classification category of any County Information stored on that system or device. |
| County Information classified as “Confidential” shall not be stored outside of the Information System of Record without an Agreement between the Information Owner and the other party (i.e., any department, agency or 3rd party that is not originally accountable for the information) setting the terms and conditions of the storage of the County Information. |
County Information classified as “Sensitive” shall not be stored on any 3rd party Information System residing outside of the Information System of Record without an Agreement between the Information Owner and the 3rd party (i.e., any 3rd party that is not an agency or department of the County) setting the terms and conditions of the storage of the County Information.
County Information Systems are to include technical, physical and procedural controls to adequately protect the confidentiality, integrity, and availability of the information residing within the system. Users shall not store County Information on any 3rd Party Information System, non- County owned device, or other resource that has not been authorized by the County and/or the Information Owner.
| Information Classification | Security Control | Risk Factor | Restrictions/ | Relationship to California Public Records Act | Examples |
| Considerations | |||||
| Confidential | Highest | Unauthorized disclosure, alteration or destruction could cause a significant level of damage to the County (liability, financial loss or serious damage to credibility) | Information in this category includes that which is protected by federal or State laws pertaining to privacy, confidentiality, public safety. Also, information protected by confidentiality agreements (contracts and/or State Agreements). | Information that is (1) not a “public record” by statute, (2) subject to mandatory non-disclosure laws or (3) a County or department policy of nondisclosure or agreement with a third party that requires assertion of a discretionary exemption to disclosure. | (1) Gov. Code 54957.2 (Brown Act); Rev & Tax Code 408; (2) Pen Code 832.7 (Peace officers records); Information Practices Act of 1977; (3) Attorney-client communications; Board policy A-131; (4) 42 CFR Part 164 (HIPAA) and information subject to a State Agreement; (5) CA Civil Code 1798.24 |
Sensitive Moderate For Official Use Only. Unauthorized disclosure, alteration or destruction could cause a moderate level of risk to the County’s conducting business, functioning or credibility. Information in this category includes that which is intended for internal use only and not for general circulation outside the County; information that may fall within discretionary exemptions. Information that is “public record” by definition (Gov Code 6252) but subject to discretionary CPRA exemptions that are asserted at the option of the County. Discretionary exemptions listed under Gov Code sec 6254, where there is no local policy of non-disclosure, e.g. 6254(a) drafts and memos (email); Gov Code sec 6255 including “deliberative process”
| Open to Public | Low | No risk to County | Information has been reviewed for legal compliance. | None – reviewed and redacted of all confidential & discretionary info | Board letters, docs filed with Clerk; |
| Annual Reports |
| Data Type Descriptions | Classification Notes | County CISO Notes | |
| Protected Health Information (PHI | Protected Health Information (PHI) is regulated by the Health Insurance Portability and Accountability Act (HIPAA) and is defined as individually identifiable health information, including demographic data that relates to: |
• The individual’s past, present, or future physical or mental health or condition;
• The provision of health care to the individual; or
• The past, present, or future payment for the provision of health care to the individual; and
| • That identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual. | A platform must be classified as "confidential" if it includes PHI. | |
| Federal Tax Information (FTI) | Return and Return Information |
IRC § 6103(b)(1) defines a return as any tax or information return, estimated tax declaration or refund claim (including amendments, supplements, supporting schedules, attachments or lists) required by or permitted under the IRC and filed with the IRS by, on behalf of, or with respect to any person or entity. Examples of returns include forms filed on paper or electronically, such as Forms 1040, 941, 1120 and other informational forms, such as 1099 or W -2.1 Forms include supporting schedules, attachments or lists that are supplemental to or part of such a return.
Return information, in general, is any information collected or generated by the IRS regarding any person’s liability or possible liability under the IRC. IRC § 6103(b)(2)(A) defines return information very broadly. It includes but is not limited to:
| • | Information that IRS obtained from any source or developed through any means that relates to the potential liability of any person under the IRC for any tax, penalty, interest, fine, forfeiture or other imposition or offense |
| • | Information extracted from a return, including names of dependents or the location of business |
| • | The taxpayer’s name, address, and identification number |
| • | Information collected by the IRS about any person’s tax affairs, even if identifiers, such as name, address and identification number are deleted |
| • | Status of whether a return was filed, under examination or subject to other investigation or processing, including collection activities |
| • | Information contained on transcripts of accounts |
Personally Identifiable Information (PII) FTI may include Personally Identifiable Information (PII). FTI may include the following PII elements:
| • | Name of a person with respect to whom a return is filed |
| • | Taxpayer mailing address |
| • | Taxpayer identification number |
| • | Email addresses |
| • | Telephone numbers |
| • | Social Security Numbers |
| • | Bank account numbers |
| • | Date and place of birth |
| • | Mother’s maiden name |
| • | Biometric data (e.g., height, weight, eye color, fingerprints) |
| • | Any combination of the above |
For the purposes of Publication 1075 and Safeguarding requirements, PII is FTI when provided by the IRS or a secondary source (i.e., SSA, BFS).
Information Received from Taxpayers or Third Parties Copies of tax returns or return information provided to the agency directly by the taxpayer or their representative (e.g. W-2’s, Form 1040, etc.) or obtained from public information files (e.g. federal tax lien on file with the county clerk, Offers in Compromise available for public inspection, court records, etc.) is not protected FTI that is subject to the safeguarding requirements of IRC § 6103(p)(4). If the agency independently verifies FTI provided by the IRS or a secondary source (i.e., SSA, BFS) with the taxpayer or a third-party source (linked to the taxpayer), the verified information is no longer FTI as long as the IRS source information is replaced or overwritten with the newly provided information.
| A platform must be classified as "confidential" if it includes FTI. | |
| Personally Identifiable Information (PII) | • Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means |
o Information that directly identifies an individual – Name Address Social security number or other identifying number or code Telephone number Email address o Information by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification including a combination of - Gender Race Birth date Geographic indicator Other descriptors).
| • Information permitting the physical or online contacting of a specific individual is the same as personally identifiable information. | A platform may be classified as "confidential" if it will contain personal information and is subject to an HHSA State Agreement. For PII that includes SSN, Drivers License (which is considered Sensitive PII) the plaform will be classified as "confidential". | All other PII use cases please review with County CISO for appropriate data classification designation. |
| Payment Card Industry (PCI) | Payment Card Industry (PCI) data refers to cardholder data that is processed, stored, or transmitted by merchants and includes: |
• Primary Account Number (PAN)
• CID/CAV2/CVC2/CVV2 Number
• Data stored on a card’s magnetic stripe or chip
| • Personal identification numbers entered by the cardholder | A platform must be classified as "confidential" if it includes PCI DSS. | |
| Criminal Justice Information (CJI) | Criminal Justice Information (CJI) refers to all the FBI provided data necessary for law enforcement and civil agencies to perform their missions including: |
• Biometric Data – data derived from one or more intrinsic physical or behavior traits of humans typically for the purpose of uniquely identifying individuals from within a population (e.g. fingerprints, palm prints, iris scans, and facial recognition data)
• Identity History Data – textual data that corresponds with an individual’s biometric data, providing a history of criminal and/or civil events for the identified individual
• Biographic Data – information about individuals associated with a unique case, and not necessarily connected to identity data. Biographic data does not provide a history of an individual, only information related to a unique case.
• Property Data – information about vehicles and property associated with crime when accompanied by an personally identifiable information (PII)
• Case/Incident History – information about the history of criminal incidents
• Criminal History Record Information (CHRI) – subset of CJI which includes:
o Gang files o Known or appropriately suspected terrorist files o Supervised release files o National sex offender release files o Historical protection order files of the NCIC o Identity theft files o Protective interest files o Person with information (PWI) data in the missing person files o Violent person files
| o NICS denied transaction files | A platform must be classified as "confidential" if it includes CJI. | Please consult County CISO for procurements that include CJIS requirements if not already completed during the IT Procurement consultation. |
| The Automated Clearing House (ACH) | The Automated Clearing House (ACH) is the primary system that agencies use for electronic funds transfer (EFT). With ACH, funds are electronically deposited in financial institutions, and payments are made online. |
The ACH Security Framework defines Protected Information as the non-public personal information, including financial information, of a natural person used to create, or contained within, an Entry and any related Addenda Record. This not only covers financial information, but also includes sensitive non-financial information (such as health information) that may be incorporated into the Entry or any related Addenda Record. This Rule applies to consumer information only, which is consistent with existing regulations and also with the approach of aligning the ACH Security Framework with existing industry regulations and guidance. However, impacted ACH participants may wish to apply the rule so that it covers all customers.
Security policies, procedures, and systems of ACH participants covered by this Rule must include controls on system access that comply with applicable regulatory guidelines. The systems impacted include all systems used by the ACH participate to initiate, process, and store Entries.
ACH Activities include:
Credit files – payroll, pensions, corporate-to-corporate payments, tax payments, vendor payments.
Debits files – payments, cash concentration, purchases, donations A platform must be classified as "confidential" if it includes ACH.
Cover Sheet
| Please answer the following questions | Answer |
| Name or Type of IT Solution Required: | |
| Group/Department: | |
| Person completing form: | |
| Phone number for County POC: | |
| Email for County POC: | |
| A-87 or Competitive Procurement: | |
| Has OCC and Risk Management Approved? | |
| Who is the Cloud Service Provider using for hosting the data (AWS, Azure, Google, etc) Commercial/Gov? | |
| What is the DPC Contract number, if applicable? | |
| Application Data | Answer |
| What is the classification of the data that will be entered into the solution? (See Data Classifications tab for definitions.) | |
| If data classification is Sensitive, is the data inherently sensitive? Please explain. (By County definitions, data may be classified as sensitive if it has not been specifically prepared for public consumption. Even though the data could be made available to the public, if it is not already on a public website or otherwise currently available to the public, it must be classified as "Sensitive." This question seeks to determine whether the data is inherently sensitive, not whether it has been prepared for public consumption.) | |
| What types of county data will be stored by this solution? | |
| People's names | |
| Addresses | |
| Email address | |
| Date of Birth | |
| SSN | |
| Healthcare Information (HIPAA, PHI) | |
| PCI (Payment Card Industry) | |
| Driver's License | |
| CJIS | |
| Other sensitive/confidential information (please describe) | |
| Approximately how many individual records will contain these types of data (PI, PII, PHI, etc)? | |
| What is the destination portal/URL that CoSD users will use to access the system? | |
| How many user accounts will access the data, and what is the maximum number of accounts that will be created? | |
| Who will manage the user accounts until SSO is implemented? | |
| Is a department process in place to disable and terminate user access for personnel transfers or terminations? | |
| Has Cyber Liability Insurance been added to the DPC contract? | |
| Has Article 14 for been added to the DPC contract? | |
| Will this be a System of Record for the data? (Policy #0400-11) | |
| Is the data an Official Record? (Policy #0040-09) | |
| How is data entered into the system? | |
| Does this solution input, transmit, receive, manipulate or store County data? | |
| Is data being exported? If yes, explain. | |
| Will this information be shared with any organization outside the department? If yes, explain. |
Moderate Baseline Requirements
| County of San Diego Baseline Security Requirements Checklist | ||||
| Control Section | Requirement | Yes | No | Exception Explanation |
| AC - Access Control | Solution must be able enforce restrictive controls for administrative access, system or application changes, and change/delete access to audit logs | |||
| AC - Access Control | Solution must utilize role-based access to prevent user acess to unapproved content | |||
| AC - Access Control | Solution must display any required approprite privacy and security banners | |||
| AC - Access Control | For systems capable of external sharing, solution must have the ability to authorize, control and limit external sharing | |||
| AU - Audit and Accountability | Solution should have a Security Information and Event Management (SIEM) solution | |||
| AU - Audit and Accountability | Solutions security tools should integrate with a SIEM solution | |||
| AU - Audit and Accountability | Solution security audit logs must be protected from unauthorized access, modification or deletion | |||
| CA - Security Assessment and Authorization | Supplier maintains a current SOC 2 Type II audit report prepared by a third party auditor consisting of a comprehensive internal controls assessment covering the internal controls and information security posture of the contracted service or product. | |||
| CM - Configuration Management | Solution must only utilize technologies and components that are actively supported by maintenance contracts | |||
| CM - Configuration Management | Solution should provide Integrated Change Notification | |||
| CP - Contingency Planning | Solution must provide a daily backup solution | |||
| CP - Contingency Planning | Solution should maintain at a minimum of 180 days of application backup data | |||
| CP - Contingency Planning | Solution must include a viable, annually-tested Disaster Recovery plan | |||
| IA - Identification and Authentication | Solution must be able to integrate with County Identity Provider and Single Sign-on (SAML 2.0, OAUTH or WS-Federation integration). If yes, please indicate which Single Sign-on capability (SAML 2.0, OAUTH or WS-Federation integration) vendor supports. | |||
| IA - Identification and Authentication | Solution must ensure the information system uniquely identifies and authenticates all users | |||
| IA - Identification and Authentication | Solution should provide multi-factor authentication (MFA) | |||
| IA - Identification and Authentication | Solution must ensure information system default account passwords are changed prior to release to production | |||
| IA - Identification and Authentication | Solution must not store passwords or API keys inside source code | |||
| IA - Identification and Authentication | Solution must support periodic application and service account password changes including changing all default administrator passwords, at least annually | |||
| IA - Identification and Authentication | Solution must store and transmit passwords in an encrypted format so that passwords do not display in a clear text | |||
| IR - Incident Response | Solution provider must have a published breach disclosure policy | |||
| IR - Incident Response | Solution should be supported by a 24x7x365 Security Operations Center | |||
| IR - Incident Response | Solution provider must maintain and regularly test an Incident Response Plan and provide investigation support in a breach | |||
| RA - Risk Assessments | Solution provider must perform Penetration Testing annually | |||
| RA - Risk Assessments | Solution provider must ensure vendor-defined high severity and above information system vulnerabilities are remediated prior to release to production | |||
| RA - Risk Assessments | Vulnerability scanning is performed at least weekly for operating systems, system components, dynamic web applications and static code analysis | |||
| RA - Risk Assessments | Security patches for vendor-defined high severity and above vulnerabilities must be implemented within 30 days of availability | |||
| RA - Risk Assessments | Vulnerability mitigations must be put in place for vendor-defined high and above severity vulnerabilities while a full patch is being developed | |||
| SA - System and Services Acquisition | Solution adheres to a privacy policy that discloses the ways the provider gathers, uses, discloses and manages customer data | |||
| SA - System and Services Acquisition | Solution provider must not share County data with another party without explicit permission of the customer | |||
| SA - System and Services Acquisition | All support for the solution must be provided from or at locations within the geographic boundaries of the United States | |||
| SA - System and Services Acquisition | All data stored and processed by the solution must remain within the geographic boundaries of the United States | |||
| SC - System and Communications Protection | Solution must ensure the information system is configured to protect against (or limit the effectiveness of) denial of service attacks | |||
| SC - System and Communications Protection | Solution must ensure the information system monitors and controls communication at the external boundary of the system and at key internal boundaries (such as development) within the system | |||
| SC - System and Communications Protection | Solution's APIs/open interfaces must be secured and encrypted | |||
| SI - System and Information Integrity | Solution must incorporate anti-malware protection at network and host platform levels | |||
| SI - System and Information Integrity | Solution must ensure the information system employs malicious code protection at information system entry and exit points to detect and eradicate malicious code | |||
| SI - System and Information Integrity | Solution must ensure the information system malicious code protection is configured to perform periodic scans and real-time scans of files from external sources as they are downloaded, opened, or executed | |||
| SI - System and Information Integrity | Solution must ensure the information system malicious code protection must block or quarantine malicious code and send an alert to an administrator in response to malicious code detection | |||
| SI - System and Information Integrity | Solution must ensure the information system must be capable of detecting and preventing attacks and indicators of potential attacks and ensure all events are forwarded to the Security Incident and Event Manager | |||
| SI - System and Information Integrity | Solution must have a Firewall | |||
| SI - System and Information Integrity | Solution should have or integrate with a web application firewall (WAF) | |||
| SI - System and Information Integrity | Solution must encrypt data at rest | |||
| SI - System and Information Integrity | Solution must encrypt data in transit | |||
| SI - System and Information Integrity | Multitenant solutions must support partitioning of County data | |||
| SI - System and Information Integrity | Solution must incorporate intrusion prevention and detection capabilities |
Project Req
| Requirement Number | Requirement Description | Supported | Comments |
| Project requirements | |||
| System Documentation Requirements | |||
| T-230 | Online help on system functionality is to be a component of the online system | ||
| T-231 | Online help can be searched based on screen, job function, process name, nouns so that user can find help by topic | ||
| T-232, P-165 | System documentation includes product user guides | ||
| T-233 | System documentation includes technical manuals | ||
| T-234 | System documentation includes data model, tables and attributes | ||
| T-235 | System documentation can be exported into a format that can be annotated electronically and then stored, i.e. product documentation does not need to be re-typed to create custom training material or custom business process documentation | ||
| T-236 | System documentation is available in electronic format that may be stored on county computers | ||
| T-238 | Custom documentation on business processes is developed as part of the project | ||
| T-239 | Custom documentation on configurations and customization made to base product are developed as part of the project | ||
| T-240 | Custom documentation on installation procedures for configurations, customization are developed as part of the project |
| System Training Requirements | |
| T-241 | Training materials need to be accessible online and indexed by job function or process name. |
| T-242, P-166 | Training materials include detail user steps to complete job functions. |
| T-243 | Training materials are provided in electronic format. |
| T-244 | Training class are defined, materials written, classes conducted for end user training, super user training and system application support staff are developed as part of the project |
| WW-189 | Training will be hands-on practical on the installed system, using helpful training documents. |
| Data Extraction, Data Conversion, Data Loading | ||
| T-245 | Data from existing EAM systems, custom Access databases, and excel spreadsheets is extracted, transformed and loaded into new EAM as part of the project | With error messaging on load problems |
| T-246 | Defining the data mapping from existing EAM data sources into the new EAM system is part of the project | |
| WW-190 | Data conversion services as required to transfer existing County data into the new EAM. |
&"Arial,Bold"&14&A
&"Times New Roman,Italic"&11Functional Requirements Page &P of &N &"Times New Roman,Italic"&11&D
&"Times New Roman,Italic"&11Functional Requirements Page &P of &N &"Times New Roman,Italic"&11&D
&"Times New Roman,Italic"&11Functional Requirements Page &P of &N &"Times New Roman,Italic"&11&D
File details come from the government source that posted it. Updated .