Requirements

1. Review Requirements.

2. Review Priority. Priorities are defined as:

● Mandatory: Mission critical requirement.

● Desirable: Requirement enhances functionality or quality of the solution and makes it more desirable.

3. Go to Will Bidder Meet Requirement column. Select one of the two options:

● Yes

● No

4. Go to Response Code column. For each requirement that Bidder answers "Yes", indicate the appropriate Response Code:

● Core: The proposed solution currently provides this requirement as part of the generally available solution.

● Customization: The proposed solution can meet the requirement through a customization or an add-on to the generally available solution.

● Third Party: The proposed solution can meet this requirement through functionality provided by a third party.

5. Go to Written Response column. Provide a written response that addresses how the proposed solution will be met; if customization is required what level of complexity and estimated timeline; and any additional details that may be helpful during review.

NOTE: Bidder can include screen shots or separate documents as attachments, if needed. All attachments must be labeled with the requirement ID number and the Written Response column must indicate the page number and/or section title of where the attachment can be found.

Alternative state type, source type, ID Flows, indicators, measures - Supports state-defined water system flows, measures, and indicators Annual operating period/population served - Used to derive PWS type and calculate TCR schedule Service connections - Used to derive PWS type Points of contact association - Associates legal entities to water systems Water system facility flow - Establishes flow from source to customer. May add treatment train and sequence ID.

Regulating agency association Geographic area association - E.g. state service areas or districts Service area association/primary designation - E.g. municipality Purchases/Wholesales - Establishes relationship between selling PWS water system facility and buying PWS water system facility Activity maintenance, activity reason - Activity status and reason codes Water system history - History of changes to TINWSYS table Activity date GIS Flag for drought/flood Outstanding Performer Indicator - Ground Water Rule

Annual operating period maintenance Points of contact association - Associates a legal entity to a water system facility Sampling point - Adds sampling point associated to selected water system facility Flows, indicators, measures - Supports state-defined water system facility flows, measures, and indicators Activity date Filtration status - E.g. must install, successfully avoiding Locational information - Latitude/Longitude, cadastral information

Date drilled SWAP report Well casings Screen locations Constructed/modification dates Inches above grade Static water level observation date Well capacity Drilling method Activity date Well head protection GUI (Ground Water Under Influence) determination indicator Ground water time of travel - User defined water system facility flow

Treatment units Treatment objective/process associations - Analyte removal or addition e.g. dose Treatment unit flows Treatment unit flows, measures and indicators Treatment objective/process associated analytes Microbial removal Microbial analyte removal/inactivation Assign applicable rules to facilities

Capacity Facility security maintenance

Primary Reason Status Due Date Date of Visit Regulating Agency Water system notification date Highest deficiency severity Category evaluation summary Parties present Calculate next due date Violation type

Associate deficiency from previous visit Add deficiency

Individual samples - Federally reportable results would be reported to SDWIS/Fed Sample summaries (Total Coliform Rule and Lead Copper Rule) Composite samples Results averages - Calculate and include monitoring period average, MCL value, and DBP precursor ratio.

Calculated days out of compliance Units of measure control - Allows the association of two analytes to a given sample e.g. pci/L and ug/L for Uranium MDBP (Microbial and Disinfection Byproducts) summaries Water treatment summaries - For Subpart H systems (Surface Water and GUI) General summaries - Non MDBP/SWTR summaries e.g. fluoridation Facility Analyte Levels Individual filter effluent turbidity Entry point residual disinfectant concentration Sample suspension Susceptibility (SAS) maintenance - (staff will determine rating) but will need to indicate & store ratings in SDWIS Review susceptibility/vulnerability ratings

Facility analyte level - Record analyte levels for water system facilities TCR (Total Coliform Rule) monitoring period association - TCR monitoring periods must be associated to water systems Monitoring requirements Sampling plans - Used for LT2 source water M&R compliance report only.

RTCR (Revised Total Coliform Rule) schedules Non-TCR schedules Display sample schedule history Exception/Override

Lead and copper OCCT (Optimized Corrosion Control Treatment) - E.g.: DEEM, DONE Lead or copper 90th percentile exceedance

Group violations - Individual violations in group are hidden State violation period Violation Status - E.g. preliminary, validated, rejected, deleted or comparable codes History of changes Record MCL in violation record

Sample analytical results Public notice schedule Sample point Compliance schedule activity Sample schedule Facility analyte level Deficiency Originating violation MDBP summary

Records duration of V/E Sample point Analyte/Rule Duration Alternative compliance levels

Standard methods Standard method to analyte association Standard method to laboratory association

Inventory Water system Water system facilities Treatments Geographic areas Population groups Sampling Samples Sample analytical results Analytes Laboratories Compliance Violations Enforcement Actions Compliance Schedules Reviews, Audits and Evaluations Other Look up tables Controlling instruments Technologies Programs and plans Legal entities

Red – Substantial Noncompliance. Not adequate for growth or existing uses.

Blue – Substantial Compliance except does not meet design approval or exceeds number of approved connections. Adequate for existing uses, but not for growth.

Yellow – Substantial Compliance except has been notified of planning requirement but has not satisfied planning requirement. Approved for growth up to approval number unless otherwise limited by compliance agreement. Adequate for existing usage.

Green – Substantial Compliance. Approved for growth up to approval number and existing usage.

General Information Source Information Monitoring Requirements Samples Exceedances Compliance Actions Operating Permits Operators

The acquisition of one Water System by two or more other Water Systems, where the acquired system is inactivated OR

WaTech policies referenced in the security requirements can be found at https://watech.wa.gov/policies.

SEC-NFR-01 Network Security The solution must use a single-tenant or logically single-tenant network architecture with separate environments for development, testing, and production when possible. It must include network segmentation (e.g., DMZ, application, and data layers), boundary protections, and continuous internal/external threat monitoring. Vendors must provide data flow diagrams showing all inbound/outbound connections, including public/private interface boundaries and encryption methods in transit. Per WATech's Network Security Standard SEC-04-05-S.

Accepted Documentation:

Network architecture diagrams Documentation of segmentation and monitoring tools List of independent environments Sample intrusion detection logs

Accepted Documentation:

SOC 2 Type 2 audit reports (or equivalent) Proof of FedRAMP or FISMA certification (if applicable)

Accepted Documentation:

Logging configuration and retention policies Sample logs and audit trail reports

Accepted Documentation:

Encryption architecture and standards Encryption key management policies

Accepted Documentation:

Patch management policy and procedures Documentation of remediation actions

Accepted Documentation:

Role and access control matrix (if applicable) Authentication architecture Evidence of SAML 2.0 and directory integration

Accepted Documentation:

Remote access policies MFA configuration and tool documentation Access audit logs

Accepted Documentation:

Session timeout configuration settings

Accepted Documentation:

SDLC documentation Secure coding policies OWASP Top 10 compliance assessment

Accepted Documentation:

List of implemented operational security controls FedRAMP control mapping matrix (if applicable)

Accepted Documentation:

SOC 2 Type 2 audit reports (or equivalent) Audit remediation plans (if any) Audit timeline (if not yet completed)

Accepted Documentation:

Incident response policy and procedures Notification timeline and sample messages

Accepted Documentation:

DR plan and procedures Annual DR test reports RTO/RPO documentation Backup and data replication architecture

Accepted Documentation:

Hosting and maintenance agreement System management responsibilities matrix Support contact procedures and SLAs System documentation outlining vendor responsibilities

Accepted Documentation:

System scalability architecture overview Documentation of supported scaling methods Performance benchmarks under scaled loads

Accepted Documentation:

High availability and failover architecture diagrams Uptime and monitoring procedures

Accepted Documentation:

Extensibility strategy and documentation Customization/extension framework details Upgrade compatibility documentation

Accepted Documentation:

Release and deployment schedule Release plan templates Configuration management policies and procedures Change/release logs Incident records linked to releases

Accepted Documentation:

Fault tolerance architecture and monitoring strategy Evidence of failover testing Integration with DR/continuity plans (cross-reference to SEC-NFR-13)

Accepted Documentation:

Administrative interface and configuration documentation List of tasks requiring vendor intervention

Accepted Documentation:

Configuration audit logs Version control documentation

Accepted Documentation:

Upgrade lifecycle documentation Downtime mitigation plan Customer notification process

Accepted Documentation:

API documentation and specifications Authentication and authorization schema (e.g., OAuth scopes) List of supported data formats and protocols Sample API calls and responses

Accepted Documentation:

Integration design specification (real-time and batch) Job scheduling and triggering documentation

Accepted Documentation:

Process integration flow diagrams Documentation on supported event/message mechanisms (e.g., webhooks, Kafka)

Accepted Documentation:

List of supported third-party/state interfaces Security and compatibility documentation for each integration

Accepted Documentation:

Monitoring and alert configuration documentation Error logging and notification samples Integration health dashboard screenshots

Accepted Documentation:

API/version deprecation policy Backward compatibility test results Version support matrix

Accepted Documentation:

FHIR Capability Statement - Document showing supported FHIR resources, operations, and endpoints.

USCDI Data Mapping - Table or schema showing how the system supports USCDI data elements.

ISA Compliance Documentation - Evidence of alignment with the latest ISA-approved standards (e.g., versioning, certification status).

Accepted Documentation:

Documentation of export process and schedule Sample exported data files

Accepted Documentation:

Data migration plan with rollback and verification procedures Pre- and post-migration validation checklist

Accepted Documentation:

System configuration documentation demonstrating retention settings Compliance report or audit logs confirming policy enforcement

Accepted Documentation:

Data ownership declaration Export process documentation

Accepted Documentation:

Data dictionary (attributes, definitions, formats) Metadata schema documentation

Accepted Documentation:

Service Level Agreement (SLA) document Uptime monitoring reports

Accepted Documentation:

SLA including defined business hours System uptime tracking logs

Accepted Documentation:

Accessibility compliance statement Accessibility test results or audit report Compliance checklist aligned to WCAG 2.1 Level AA

Accepted Documentation:

Accessibility architecture or implementation plan Vendor attestation of no reliance on overlays

Accepted Documentation:

Completed VPAT document. URL to VPAT resource (https://www.itic.org/policy/accessibility/)

Accepted Documentation:

UI design documentation or wireframes User feedback report or usability test results

Accepted Documentation:

Responsive design test results List of supported mobile platforms and browsers Accessibility validation on mobile devices

Accepted Documentation:

Browser compatibility matrix QA/browser testing results Known issues log by browser (if any)