Appendix F - Additional IT Standards_v5.1.pdf

ADDITIONAL IT STANDARDS

DATA REQUIREMENTS, ADDRESSING, DIGITAL AND WEB CONTENT

ACCESSIBILITY

If applicable, applications or solutions proposed by vendors must be in alignment with these City’s Standards:

Section 1 Data Requirements Standards - All City solicitations that include the purchase of software or services relating to information systems must incorporate the requirements of this policy. This document defines standards to guide implementation of the following current and future policies covering third-party access to City information:

- Data Access Requirements for Third Party Systems

- Master Data Requirements

- Metadata Standards

- Date Formats

- Common Data Elements for Geospatial Data

- Data Protection and Retention

Section 2 Addressing Standards should be adopted for use within all database systems, applications or tables that maintain a property address.

Section 3 General Technical Standards - The City's standard non-functional requirements for IT systems ensure that information systems are resilient and secure so that the City's information is safeguarded, and its staff can continue operations (as supported by IT systems) in the event of a disaster.

Section 4 Digital Standards provide the design, code, and content guidelines for City website and web application development;

Section 5 Web Content Accessibility Standards - All sites produced by vendors for the City, regardless of the hosting environment, shall conform to the Web Content Accessibility Guidelines (WCAG) 2.1 AA. These guidelines will make content more accessible to a wider range of people with disabilities.

Section 6 Security Addendum - All City Data and the systems on which they reside must be protected in accordance with City security and privacy documentation and system risk, to include, at a minimum, adequate safeguards for the following:

Confidentiality, which means preserving authorized restrictions on access and disclosure, based on the security terms found in this contract, including means for protecting personal privacy and proprietary City Data;

Integrity, which means guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity; and

Availability, which means ensuring timely and reliable access to and use of City Data.

Third Party Data Access Standards

SOP No:

SOP Type:

Standard

Family:

System and Services

Acquisition (SA)

Internal [ ]

External [x]

Version:

1.0

Category:

System Acquisition

Originating Unit(s):

Enterprise Architecture

Effective Date:

8/24/2020

Review Cycle:

Annual

Supersedes:

N/A

Forms:

[ ] Yes [x] No

Attachments:

[ ] Yes [x] No

Contact:

Chief Enterprise Architect

Contents

1 Purpose

2 Scope

3 Policy

4 Standards

5 Roles and Responsibilities

6 Compliance

7 Guidance

8 Waivers

9 Definitions

10 Authority

11 Related Links

12 Change Log

13 Approval

1 Purpose

• Ensure City ownership of data in proprietary systems.

Section 1

Third Party Data Access Standards 2

• Assist decision makers, project teams, procurement, and legal departments by clearly defining the expectation of data ownership in vendor systems and related data access capabilities to be considered before choosing a solution.

2 Scope

All City solicitations that include the purchase of software or services relating to information systems must incorporate the requirements of this policy.

3 Policy

This document defines standards to guide implementation of the following current and future policies covering third-party access to City information:

• System and Services Acquisition.

4 Standards

4.1 Data Access Requirements for Third-Party Systems

The City considers all information that is generated or stored in third-party information system to be City property.

In accordance, the City requires perpetual, non-proprietary means to access data in third-party systems implemented by the Applicant or associated Parties.

Examples of non-proprietary means include:

1. A documented and secured web-based Application Programming Interface that meets City standards. The Current City standard API specification is RESTful web services with JSON payload.

2. Secure access to databases using non-proprietary client software that follows ODBC specifications. Documentation of database elements that store City data. Open

Database Connectivity is the City’s standard API for directly accessing database management systems.

3. Secure access to file systems where City information is stored.

4. Other means of securely providing third-party system data to the City, including exporting flat files.

Proposals shall include a statement of the Applicant’s ability to provide access to data in the context of the choices above. The City may consider alternative means on a case-by-case basis.

If these means of access are available through proprietary components of the third-party system, the vendor shall provide, free of charge, an agreed upon amount of service

Third Party Data Access Standards 3 accounts to be used solely for programmatic retrieval of data. The vendor will contractually agree to provide access to data when a given vendor system is replaced or usage is terminated.

Electronic documents stored in proposed third-party systems shall be exportable in non-vendor proprietary formats, including but not limited to:

• Adobe PDF

• Text

• JPEG

• PNG

• Semi-structured documents may be exported in XML or JSON format.

Proposals shall indicate the Applicant will provide data architecture documents including entity relationship diagrams documenting semantic and logical data relationships, along with a data dictionary describing datasets and data attributes. See the section entitled

Metadata Standards for details. Revised documents must be provided to the City should any relevant changes occur.

4.2 Master Data Requirements

The City’s master data strategy includes initiatives to provide vendors with a single source of authoritative data, and for vendor systems to in turn contribute authoritative data back to the City’s enterprise data warehouses. Accordingly, the City requests the Applicant’s proposal include the following:

1. Language indicating that City authoritative data shall be leveraged in the proposed solution if such data exists. City authoritative data is cataloged at https://metadata.phila.gov which must be used as a reference for this activity.

2. The Applicant’s plan shall include the identification of all new datasets generated or stored in third-party information systems implemented under the scope of the proposed project. The plan must include metadata creation as per City Metadata

Standards outlined in the next section.

3. Language indicating that the Applicant shall support the City as needed to meet data governance requirements including assistance with metadata creation and mentoring City Data Stewards on appropriate data usage and sensitivity.

In addition to the above, the Applicant shall provide references or case studies exhibiting integration with data warehouses developed in-house, or with other customers.

Systems integration software code developed by the Applicant or related parties is subject to RFP Section 2.4.4: Software Source Code.

https://metadata.phila.gov/

Third Party Data Access Standards 4

4.3 Metadata Standards

To ensure appropriate use and interpretation of all vendor-supplied data in City systems, the City requires that Applicants provide the following minimum metadata documentation:

1. An overview of the dataset including its scope, purpose, and context for the intended use.

2. A detailed description of the development process for creating the data, including data sources and/or data collection methods; algorithmic, analytical, or manual transformations of the raw data; documentation of any excluded, removed, or redacted data; and any other relevant elements that contributed to the end data product.

3. Documentation of the dates when data was collected, or the timeframe represented.

4. A Data Dictionary documenting the following information for each field in the dataset:

1. The raw field name

2. A human-readable title for that field

3. The type of data stored in that field (e.g., string, integer, GUID, etc.) along with any relevant details such as length, precision, geometry type, grid resolution, as applicable

4. A complete definition of any coded values

5. Identified primary and foreign keys (if applicable)

6. Any other descriptive information relevant to interpreting the data such as the universe, timeframe, or exclusions specific to a given field.

7. Additional details about geospatial data, described below.

4.4 Common Data Elements for Geospatial Data

The City has defined common data elements, defined below, for data that can be associated with a geographic location within the City. The City requires that Applicants conform to the following standards:

4.4.1 Addresses

See OIT Address Standards in Related Links, Below

All systems that process or store address data must use the City’s Address Information

System (AIS) for Philadelphia based address standardization, validation, or geocoding.

4.4.2 Land Records

The City has created a standard Property Identification Number (PIN) used to uniquely identify parcels, condominiums, land rights, and easements. All systems that handle land

Third Party Data Access Standards 5 record related data or documents shall identify property records using the City’s Property

Identification Number (PIN).

4.4.3 Geospatial Vector Data

Vector data consists of points, curves (lines), and polygons and derivations thereof as defined by OGC standards. Systems that store geospatial data in a Relational Database

Management System (RDBMS) shall store the data according to the Open Geospatial

Consortium’s (OGC) standards for simple feature access. The City requires implementations of the OGC standards to follow either the Esri ST_Geometry or PostGIS

Geometry specifications.

Geospatial Vector data stored outside of an RDBMS shall be stored in industry-standard formats including geojson, shapefile, or ESRI File Geodatabase.

Geospatial Vector data shall include a Coordinate Reference System (CRS) deemed appropriate for the dataset. The City requires the use of either the NAD83 or WGS84 datum. The epoch date of the chosen datum shall be documented to ensure the City can perform accurate datum transformations.

4.5 Data Protection and Retention

The Applicant will contractually agree to protect and secure the data in keeping with the

City’s security and all applicable regulatory requirements. This includes meeting retention requirements defined in the data owner’s current Record Retention Schedule issued by the

Department of Records. The buyer should seek counsel from the City Solicitor’s Office, Commercial Law Unit to ensure the appropriate data protection and retention language is in the contract.

Third Party Data Access Standards 6

5 Roles and Responsibilities

Writing Implementing Using Auditing

OIT Enterprise

Architecture

IT Leadership City staff in a procurement role, Software Engineers, Applicants and

Implementers, Staff writing solicitations for systems will store City data

IT Leadership

6 Compliance

If OIT, through its process for reviewing IT implementations, finds a system to be non-compliant, OIT reserves the right to:

• temporarily halt or permanently cancel implementations.

• remove associated systems and assets from the City’s network.

• order hosting and SaaS providers to quarantine or shut down associated assets.

• suspend any accounts associated with the system.

• perform a security review or forensic analysis on the system.

• take further action as needed.

Personnel that violate this policy may be subject to disciplinary action, up to and including, termination of employment, in accordance with the disciplinary policies of his or her agency and, for personnel represented by the Fraternal Order of Police, International

Association of Fire Fighters, District Council 47 or District Council 33, the terms of the applicable collective bargaining agreement.

If a City contractor or third party user knowingly or negligently commits or permits a material violation of this policy, the City may terminate the contract in accordance with its terms, and/or terminate the contractor’s or third party user’s access to City information systems and information, in addition to any legal or remedial actions the City may take to enforce and protect its interests.

Third Party Data Access Standards 7

7 Guidance

Reserved

8 Waivers

Waivers may be requested from the Compliance Office by submitting a justification based on:

• Substantive business case need(s)

• Demonstration of, or a proposal for, establishment of adequate compensating controls that provide a suitable alternative to the mandated protection

The Compliance Office will coordinate with the authorizing bodies within OIT to issue a decision on a waiver for sufficient reasons exercising judgment in the best interests of the

City.

The Compliance Office shall maintain the central repository of all waivers.

9 Definitions

Terms defined in this standard shall have the meanings in this standard that are here provided. Terms not defined in this standard shall have the meanings contained in City

Policies and Standards Glossary of Terms.

10 Authority

City of Philadelphia Executive Order No. 12-11

11 Related Links

OIT Address Standard https://phila.city/display/citygeo/Addressing+Standards https://phila.city/display/citygeo/Addressing+Standards

Third Party Data Access Standards 8

12 Change Log

Version No. Date Author Description

1.0 8/26/2020 Regis Shogan Initial Version

13 Approval

By direction of the Chief Operating Officer:

(Signed original copy on file)

Sandra Carter Date

Chief Operating Officer

CITY OF PHILADELPHIA ADDRESSING STANDARDS

Prepared by the Office of Innovation and Technology in coordination and cooperation with the Office of Property Data v.06.26.2017

GOALS

These standards are consistent with recommendations prepared for Office of Property Data and align with US Postal Service (USPS) and forthcoming Next Generation E-911 National Emergency Number Association (NENA) guidelines.

The standards should be adopted for use within all database systems, applications, or tables prepared by City departments or vendors.

ALIGNMENT AND INTEROPERABILITY WITH EXISTING NATIONAL STANDARDS

The City will use the USPS Publication 28 for address standards whenever possible.

The Next Generation E-911 NENA standards for addressing will be adopted to the extent possible once they are published.

GOVERNANCE

This City has full rights to determine the street names and provide the street name to USPS.

AIS (Address Information System) was created and is maintained by the Office of Innovation and Technology (OIT) to standardize and resolve variations of address for lookup and geographic reference across city systems.

AIS has a component, Passyunk, that is the de facto standardizer and parser for City addresses.

Departments and vendors can use this application to parse and standardize addresses according to standards set by the City (see below).

First line addresses (the house number and street name minus city, state, ZIP Code values) can be stored in tables using either single field or parsed out into the individual components described below.

Direct questions on this standard to the Office of Innovation and Technology at maps@phila.gov Subject line: City Address Standards

Section 2 http://pe.usps.gov/text/pub28/welcome.htm https://github.com/CityOfPhiladelphia/ais https://github.com/CityOfPhiladelphia/passyunk mailto:maps@phila.gov

Office of Innovation and Technology - City Address Standards - v.06.26.2017 page 2

ADDRESS FIELD COMPONENTS

COMPONENT FIELD

TYPE

EXMPLE:

1234B 1/2 E Independence Mall S Ste 12A

NOTES

Address char(12) 1234B 1/2 Cannot be a zero, no leading zeros

Address Number num 1234 Cannot be zero

Address Suffix char B Values that refer to property types should instead be in the unit designator field

R(REAR), S(SIDE)

Address Fraction char(3) 1/2 Exist in Philadelphia

Street Pre Direction char(4) E N,S,E,W City doesn't have NE, SE,NW, SW

Street Name INDEPENDENCE Required

Street Suffix char(4) MALL USPS standards. i.e. AVE not AV

Street Post Direction char(2) S N,S,E,W City doesn't have NE, SE,NW, SW.

The City only has 300 addresses with a post direction. Use should be deprecated if possible

Secondary Unit Designators char(10) STE USPS standards. Avoid # symbol whenever possible

Secondary Unit Number char(10) 12A Optional

City Philadelphia Not used if City only address list

State char(PA) PA Not used if City only address list

ZIP Code char(5) 01234 Optional if City only address list

Zip4 char(4) 0123 Optional if City only address list http://pe.usps.gov/text/pub28/28apd_005.htm http://pe.usps.gov/text/pub28/28api_007.htm http://pe.usps.gov/text/pub28/28api_007.htm http://pe.usps.gov/text/pub28/28apc_002.htm http://pe.usps.gov/text/pub28/28api_007.htm http://pe.usps.gov/text/pub28/28api_007.htm http://pe.usps.gov/text/pub28/28apc_003.htm http://pe.usps.gov/text/pub28/28apc_003.htm http://pe.usps.gov/text/pub28/28c2_003.htm http://pe.usps.gov/text/pub28/28c2_003.htm

Office of Innovation and Technology - City Address Standards - v.06.26.2017 page 3

CountyFips char(5) 42101 Optional

Status Char(1) A Optional:

Active, Retired, Temporary, Provisional

Status Date Date 12/20/2016 Optional

Hyphenated ranged addresses exist where tax lot consolidations have occurred. This condition exists in addresses generated by Office of Property Assessment (OPA). For hyphenated addresses, use the same Address Number component as follows. Additional fields may be used optionally

COMPONENT FIELD

TYPE

EXMPLE:

1201-05 S 58th St

NOTES

Address char(12) 1201-05 Use the hyphen with no spaces between values.

Address Number Low num 1201 Cannot be zero

Address Number High num 1205 Optional. In OPA documentation, this is called HOUSE EXTENSION

SUPPLIMENTAL INFORMATION

1. The City has about 30,000 ranged address numbers. The format looks like this -1201-03 S 58TH ST. This is unique to Philadelphia and will make any enterprise application development more difficult and expensive.

(NYC has hyphenated addresses that have been adopted by USPS, but function differently)

2. Many datasets including Office of Property Assessment (OPA) do not have Secondary Unit Designator. They only have the Secondary Unit Number. Therefore, the default value is a hashtag “#”. The Address Unit Designator must be added to all city address datasets so that the correct APT, UNIT, STE, etc., is used. These values will align with what USPS has. It is understood that buildings do not always have the same standards for this however the City and USPS should be aligned.

http://pe.usps.gov/text/pub28/28apd_002.htm

Office of Innovation and Technology - City Address Standards - v.06.26.2017 page 4

3. The (address) Suffix/Suff fields in OPA and Department of Records (DOR) databases are problematic to matching or geocoding operations of aggregated data from these sources as they are unique to each agency’s address recording operations. See Appendices A and B.

Address suffixes should be used for specific postal address designations that generally have an alpha character at the end of the numeric address number: 1234A Market St, 1234B Market St.

The OPA and DOR versions of these fields are a mix values that don't match postal standards and in many cases refer to types of ownership

a. The value '2' indicates that ' 1/2' is the address number suffix.

b. R = REAR. Should be Secondary Unit Designator?

c. A = Air Rights, S = Subterranean, M = Multiple, L = Leasehold, E = Encroachment, P = Parking... These are not address values and should have their own field

4. No leading zeros in street names: 1317 N 02ND ST should be 1317 N 2ND ST

5. Single digit range numbers should have a leading zero: 1201-3 S 58TH ST should be 1201-03 S 58TH ST

6. Address number fractions in ranged addresses need to be cleaned up and not allowed 909 1/2-11 S 9TH ST.

There are 6 cases known in the city.

7. The OPA database [as of this date of the document] has a constraint on the length of street names. This affects long street names that have been abbreviated: BEN FRANKLIN PKWY, CHRIS COLUMBUS BLV.

8. Per USPS standards, the word SAINT should always be spelled out, not abbreviated to ST.

9. Per USPS standards, the word MOUNT should always be spelled out, not abbreviated to MT.

10. Per USPS standards, abbreviations should not be used in Street Names: POQUESSING CRK DR, wrong.

POQUESSING CREEK DR, correct.

11. Per USPS standards, pre-directions are always abbreviated: N, E, S, W. WEST SOUTH ST, wrong. W SOUTH ST, correct. SOUTH ST - correct.

12. Per USPS standards, address suffix always uses the official USPS abbreviations: POQUESSING CREEK DRIVE, wrong. POQUESSING CREEK DR, correct.

13. There should be no space after MC in street names: MC CALLUM ST, wrong. MCCALLUM ST, correct.

14. The city only has 300 addresses with a post direction. Use should be deprecated, if possible.

15. County, State, and Local Highways. Not all roads in Philadelphia exist solely in Philadelphia. There is a public safety need to standardize the names of roads that cross county and state boundaries. Many of these roads do not have addresses such as Interstate 95. They still need standardized names for E-911 routing, E-911 addressing, crash reporting, etc.

http://pe.usps.gov/text/pub28/28apf.htm

Office of Innovation and Technology - City Address Standards - v.06.26.2017 page 5

16. Not all addresses will have corresponding Centerline Streets. Need to handle these exceptions: GARRISON CT, 78 S PIER, ONE PENN CENTER

17. The Street Centerline Alias table should be cleaned up to only contain Aliases and no Standardizations.

a. Chris Columbus Ave -> Christopher Columbus Ave = Standardization

b. Delaware Ave -> Christopher Columbus Ave = Alias

SUPPLEMENTAL DOCUMENTATION

City of Philadelphia Street Name Issues August 10th 2016

List of street name variations between USPS, Street Centerlines, and OPA

OPA Address Standardization Issues August 2016 CD

List of all the variations between the Passyunk parser and OPA addresses

Street Name Variations May 2016

Slide deck of Street Name variations across systems and street signs.

https://phila.city/download/attachments/10325007/street_name_discrepancies%20v2.docx?version=1&modificationDate=1536168522220&api=v2 https://phila.city/download/attachments/10325007/OPA_address_issues_Aug_2016.pptx?version=1&modificationDate=1536168523887&api=v2 https://phila.city/download/attachments/10325007/Addressing3.pptx?version=1&modificationDate=1536168525590&api=v2

Office of Innovation and Technology - City Address Standards - v.06.26.2017 page 6

APPENDIX A – OFFICE OF PROPERTY ASSESSMENT SUFFIX FIELD

FROM OPA PROPERTY CD DATA DICTIONARY – 2016 CERTIFIED VALUES

PAGE #4 - SUFFIX FIELD

This is an extension of the address. In past years, because of improper planning, no space may have been left between addresses or because the width of the lot was narrow, an address with ½ was created. This is no longer permitted.

The following are the only allowable codes for suffix:

2 - to indicate ½ in address (529) R - to indicate Rear in address (2,111) A - to indicate Air Rights (150) S - to indicate Subterranean Rights (55) M - to indicate Air Rights and Subterranean Rights on a given property. (0) E – Encroachment (1) L - Leasehold (34)

A specific location with multiple properties in the rear will be designated by using the unit number, not the suffix. That is, a frontage property with three properties in the rear would have R1, R2 R3 in the unit number. If there are multiple Air Rights (that is the splitting of the fee simple estate on a vertical basis) they would be expressed as A-1, A-2, A-3 etc.

Office of Innovation and Technology - City Address Standards - v.06.26.2017 page 7

APPENDIX B – DEPARTMENT OF RECORDS DEED PARCELS SUF(SUFFIX) FIELD

DEPT. OF RECORDS DEED PARCEL DATABASE DOMAINS FOR SUF(SUFFIX) FIELD

Code Description

F Front

R Rear

2 1/2

A Air Rights

S Subterranean Rights

M Mixed (Sub and Air)

P Parking

G Garage

B TBD01

C TBD02

D TBD03

L TBD04

Q TBD05

0 TBD06

1 TBD07

3 TBD08

4 TBD09

5 TBD10

6 TGD11

General Technical Standards 1

General Technical Standards

SOP No:

SOP Type:

Standard

Effective Date:

12/1/2022

Review Cycle:

Annual

Version:

1.6

Category:

Configuration

Management

Originating Unit(s):

Enterprise

Architecture

Contact:

Director of Enterprise Architecture

Supersedes:

General Technical Standards v.1.5

Contents

1 Purpose

2 Scope

3 Policy

4 Standards

5 Roles and Responsibilities

6 Compliance

7 Guidance

8 Waivers

9 Definitions

10 Authority

11 Related Links

12 Change Log

13 Approval

Section 3

General Technical Standards 2

1 Purpose

The City's standard non-functional requirements for IT systems ensure that information systems are resilient and secure so that the City's information is safeguarded, and its staff can continue operations (as supported by IT systems) in the event of a disaster.

2 Scope

All city systems are in scope to be reviewed for compliance with this standard.

3 Policy

Reserved

4 Standards

The non-functional requirements listed below must be included in the requirements sections of documents that specify other system or business requirements. These documents include RFX’s.

These requirements must also be adhered by vendors who are developing software for the

City, system implementors, and City staff who are developing software for the City.

General Technical Standards 3

4.1 City Standard Non-Functional Requirements

All systems and applications must meet the following "non-Functional" requirements:

Required For:

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Standard

Operating

System

Compatibility

If the system is server-based, it must be compatible with the latest stable release of

Microsoft Windows Server as defined by

Microsoft, or an approved Linux distribution

(currently Centos 7 and Ubuntu 18.04). If the system has a thick client, it must be compatible with the latest stable release of

Microsoft Windows and Mac OS.

Yes Yes No Yes, but prefer containers or serverless

Standard

Database

Compatibility

If a database is deployed on-premises or in a

City-owned cloud environment, it must be compatible with the latest stable release of

Microsoft SQL Server, PostgreSQL, or Oracle.

Yes Yes No Yes

General Technical Standards 4

Required For:

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Monitoring

The system has the ability to be monitored to provide metrics that can prevent outages and must provide immediate alerts in case of an outage in any system component. Alerting must be interoperable with third-party software (e.g. Pager Duty) via webhooks.

Yes Yes Covered by

SLA

Yes

Browser

Support

The system has been tested to work with the latest versions of popular web browsers, including mobile device browsers.

Yes Yes Yes Yes

Tested

The system has a documented test plan and functional testing is conducted on every update, and has full test suite (smoke, integration, etc.) performed on every release.

The system must have a dedicated test environment where all testing occurs.

Yes Yes Covered by

SLA

Yes

General Technical Standards 5

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Web-Based

APIs

The system's components communicate via web-based APIs wherever possible. The system's business data must preferably be available via a secure API call. APIs should be authenticated and use a role-based authentication mechanism. APIs should be versioned, and as new versions are released adequate time must be given for conversion before older versions are retired.

Yes Yes Yes Yes

Secure

The City expects hosting providers to be able to produce a clean SOC2 for non-financial data. The City’s security policies are based on

NIST 800-53 Rev 4. The system must pass a penetration test to the City's satisfaction, be monitored for security events by the system owner, and ISG must be notified of any malignant events.

Yes Yes Yes Yes

General Technical Standards 6

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Authentication

For City Users: The system supports authentication using SAML 2.0 or OAuth 2.0 –

OpenID Connect via Microsoft Azure Active

Directory.

For External Users: The system supports authentication using SAML 2.0 or OAuth 2.0 -

OpenID Connect, via the City’s login.phila.gov platform. The system should use login.phila.gov if the solution includes public login.

Yes Yes Yes Yes

Multifactor

Authentication

The system provides Multi-factor authentication as per the City MFA Policy.

Yes Yes Yes Yes

Access Control

Access to data and administrative functions is segmented based on a user's role.

Administrative privileges are just-in-time, session based, or assigned to dedicated privileged account(s)

General Technical Standards 7

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Logging

Application and server logs are searchable, accessible, and stored in a discrete fault-tolerant location.

Yes Yes No Yes

Disaster

Recovery

The system can be recovered within the

Recovery Time Objective and to a Recovery

Point defined by the business stakeholders.

No, best effort applies

Yes Yes Yes

Web

Accessibility

User interfaces meet WCAG AA 2.1 Standards.

https://www.w3.org/TR/WCAG21/

Internal:

Recommended

Public Facing:

Yes

Internal:

Recommended

Public Facing:

Yes

Internal:

Recommended

Public Facing:

Yes

Yes

Localization

Software should have localization features for the following recommended languages:

Spanish, Simplified Chinese, Vietnamese, Portuguese, Russian, French, Arabic, Haitian

Creole, Swahili.

Internal:

Recommended

Public Facing:

Yes

Internal:

Recommended

Public Facing:

Yes

Internal:

Recommended

Public Facing:

Yes

Internal:

Recommended

Public Facing:

Yes https://www.w3.org/TR/WCAG21/

General Technical Standards 8

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

User

Experience

The system’s ornamentation, including branding, color schemes, look-and-feel, and navigation schemes et. al. should to adhere to

City Digital Standards. standards.phila.gov

Yes Yes Yes Yes

System documentation

Documentation for administrators and end-users is provided. Administrator documentation includes instructions for deploying, maintaining, and auditing the system for security events such as unauthorized access.

Yes No No Yes

Interface documentation

Documentation must clearly identify integrations, including data sets transferred, frequency and schedules of flows, mechanisms and protocols of transfer, and API services used and offered to others http://standards.phila.gov/

General Technical Standards 9

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Data documentation

The solution design should identify data managed by the solution that is considered

‘system-of-record’, data that is duplicated from other sources and offered to others as

‘authoritative sources’, and data that integrates with any master data management processes.

Yes Yes Yes Yes

User Analytics

The software must provide web page use analytics, such as user interactions, time spent on a page, and site referrals, etc., or otherwise be able to integrate with an analytics package.

Yes Yes Yes Yes

SLA

The system must be available at least 99.9% of the time, or higher if there is a business need. Deploying updates to the system should not cause downtime outside of those scheduled and documented as part of a

Service Level Agreement.

No, best effort Yes Yes Yes

General Technical Standards 10

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Encryption

Data is encrypted in transit and at rest using contemporary standards such as TLS and AES.

For appropriate regulated data (e.g. CJIS) the

City should have the ability to manage the encryption keys.

Yes Yes Yes Yes

Remote

Worker

Friendly

Users should not have to log on to the City’s

VPN in order to establish a secure connection to an application. The system should be able to operate on internal networks and securely over the Internet.

If the above is not possible, the system should be offered on Virtual Desktop Infrastructure

(VDI) that has secure communications with the system and is segmented appropriately from the end users’ PC.

General Technical Standards 11

Requirement Description

City Hosted

COTS

Vendor

Managed

/Hosted

Software as a

Service

Custom App

Shared

Services

The system must use applicable OIT shared services to avoid duplicating capabilities. These include, but are not limited to:

• OIT Middleware such as DataBridge and Software AG Webmethods

• Active Directory

• Monitoring (Solarwinds, CloudWatch)

• Enterprise VxRail or AWS hosting environments

• Enterprise Database environment

A full list of shared services is available via hyperlink at the end of this document and can be exported in MS Word format to share externally as needed.

General Technical Standards 12

Additional requirements for custom apps:

Deployable At least 2 City staff members must know how to deploy the application.

The deployment process is documented.

CI / CD The application has CI and CD in place.

Version Control

• Source code for the application is uploaded to version control environment (Github).

• The app has a supported branching strategy.

Mobile

• Either a fully native version of the app must be developed or a fully responsive version.

• Applications must be developed "mobile first."

Developer

Documentation

• Documentation exists and covers at least the following:

o how to develop the app locally.

o how to deploy the app.

o how to debug the app.

Repository

• City Github account

• City NPM account

• City Terraform Enterprise account

General Technical Standards 13

5 Roles and Responsibilities

Writing Implementing Using Auditing

OIT Enterprise

Architecture

OIT Software

Engineering

IT Leadership City staff in a

Procurement role

Software Engineers

Vendors and

Implementors

Staff writing RFIs and

RFPs

IT Leadership

All City staff responsible for decision-making regarding procuring or developing information systems are responsible for implementing this policy as criteria in their work — including RFP documents, vendor system selection, system assessments/reviews, and system design.

6 Compliance

If OIT, through its process for reviewing IT implementations, finds a system to be non-compliant, OIT reserves the right to:

• temporarily halt or permanently cancel implementations

• remove associated systems and assets from the City’s network

• order hosting and SaaS providers to quarantine or shut down associated assets

• suspend any accounts associated with the system

• perform a security review or forensic analysis on the system, and/or

• take further action as needed.

Personnel that violate this Policy may be subject to disciplinary action, up to and including, termination of employment, in accordance with the disciplinary policies of his or her agency and, for personnel represented by the Fraternal Order of Police, International

Association of Fire Fighters, District Council 47 or District Council 33, the terms of the applicable collective bargaining agreement.

If a City contractor or third party user knowingly or negligently commits or permits a material violation of this policy, the City may terminate the contract in accordance with its terms, and/or terminate the contractor’s or third party user’s access to City information

General Technical Standards 14 systems and information, in addition to any legal or remedial actions the City may take to enforce and protect its interests.

7 Guidance

The table of City Standard Non-functional Requirements must be used as an RFX Appendix.

The list of OIT Shared services is provided as an example and must be changed depending on the type of solution sought. For example, a GIS based solution must list ArcGIS. Refer to OIT Shared Services in the Additional Resources section below for a full list.

8 Waivers

Waivers may be requested from the Compliance Office by submitting a justification based on:

• Substantive business case need(s)

• Demonstration of, or a proposal for, establishment of adequate compensating controls that provide a suitable alternative to the mandated protection

The Compliance Office will coordinate with the authorizing bodies within OIT to issue a decision on a waiver for sufficient reasons exercising judgment in the best interests of the

City.

The Compliance Office shall maintain the central repository of all waivers.

9 Definitions

Terms defined in this policy shall have the meanings in this policy that are here provided.

Terms not defined in this policy shall have the meanings contained in City Policies and

Standards Glossary of Terms.

10 Authority

City of Philadelphia Executive Order no. 12-11

11 Related Links

OIT Shared Services: https://phila.city/display/ea/OIT+Shared+Services https://phila.city/display/ea/OIT+Shared+Services

General Technical Standards 15

City Digital Standards: standards.phila.gov

City of Philadelphia Web Accessibility Policy

WCAG AA 2.1 Standards: https://www.w3.org/TR/WCAG21/

12 Change Log

Version No. Date Author Description

1.0 8/26/2020 Regis Shogan Initial Version

1.1 1/28/2021 Regis Shogan Added Remote

Worker Friendly

Requirement

1.2 10/7/2021 Regis Shogan Annual review

1.3 12/1/2021 Dan Lopez & Regis

Shogan

Add External User

Authentication.

Update Shared

Services examples

1.4 1/12/2022 Regis Shogan Add Encryption

1.5 1/13/2022 Regis Shogan Add interface documentation and data documentation.

Generic Updates

1.6 4/7/2022 Regis Shogan Added matrix for internal / vendor managed / SaaS /

Custom https://www.w3.org/TR/WCAG21/

General Technical Standards 16

13 Approval

By direction of the Chief Operating Officer:

(Signed original copy on file)

Sandra Carter

Chief Operating Officer

Date

CITY OF PHILADELPHIA DIGITAL STANDARDS

Philadelphia’s digital standards provide the design, code, and content guidelines for City websites. These standards were created by the Office of Open Data and Digital Transformation for people who are designing, creating, and writing for the City of Philadelphia. Standards allow as many people as possible to access City information. Standards also help outside vendors and individual departments, offices, commissions, and agencies create a consistent identity for the City of Philadelphia.

These standards are divided into guides for:

• Design and Development: the visual branding elements and tools that define how City websites should look and function.

• Content: all the information you need to write for City websites.

• Analytics: as part of the City’s commitment to open data, we employ a

Unified Web Analytics Strategy and have included the necessary code for employing it.

Please review the guides and technical details at http://standards.phila.gov/

Section 4 http://standards.phila.gov/ http://standards.phila.gov/

CITY OF PHILADELPHIA

WEB CONTENT ACCESSIBILITY STANDARDS

All sites produced by vendors for the City, regardless of the hosting environment, shall conform to the WCAG 2.1 AA Accessibility Guidelines. Click Link to view

Section 5 https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F&data=02%7C01%7CLatisha.Branch%40phila.gov%7C7d34a0b41d4644e6a08208d7565998cd%7C2046864f68ea497daf34a6629a6cd700%7C0%7C0%7C637072815121112307&sdata=vRFPeZN%2BlHWBjD7R8gIK98n8RacepSxeHGbP4CG2pM4%3D&reserved=0 https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F&data=02%7C01%7CLatisha.Branch%40phila.gov%7C7d34a0b41d4644e6a08208d7565998cd%7C2046864f68ea497daf34a6629a6cd700%7C0%7C0%7C637072815121112307&sdata=vRFPeZN%2BlHWBjD7R8gIK98n8RacepSxeHGbP4CG2pM4%3D&reserved=0 https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F&data=02%7C01%7CLatisha.Branch%40phila.gov%7C7d34a0b41d4644e6a08208d7565998cd%7C2046864f68ea497daf34a6629a6cd700%7C0%7C0%7C637072815121112307&sdata=vRFPeZN%2BlHWBjD7R8gIK98n8RacepSxeHGbP4CG2pM4%3D&reserved=0 https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F&data=02%7C01%7CLatisha.Branch%40phila.gov%7C7d34a0b41d4644e6a08208d7565998cd%7C2046864f68ea497daf34a6629a6cd700%7C0%7C0%7C637072815121112307&sdata=vRFPeZN%2BlHWBjD7R8gIK98n8RacepSxeHGbP4CG2pM4%3D&reserved=0

10755949v1

CITY OF PHILADELPHIA SECURITY ADDENDUM

This Security Addendum (“Addendum”) is attached to, incorporated into, and forms a part of, the master service agreement, statement of work, vendor agreement, purchase order, or other terms (the “Agreement”) under which the vendor identified in the Agreement (the “Provider”) provides services to the City of Philadelphia (“City”) (each a “Party” and collectively the “Parties”). In the event of any conflict between the terms of this Addendum, any other documents comprising the Agreement, and any Business Associate Agreement (“City PHI Terms”) and/or Security Addendum by and between the Parties, the conflict will be governed in the following order: (1) the City PHI Terms; (2) this Addendum; (3) the Data Processing Addendum; and (4) the Agreement.

WHEREAS City may provide access to or disclose information, records, documents, and data in relation to the work required under the Agreement, including information about its business, employees, and/or City, as well as Personal Information as that term is defined in the Pennsylvania Breath of Personal Information Notification Act (as amended) (collectively, “City Data”) for the purpose of receiving the Provider’s services under the Agreement; and

All City Data and the systems on which they reside must be protected in accordance with City security and privacy documentation and system risk, to include, at a minimum, adequate safeguards for the following:

Confidentiality, which means preserving authorized restrictions on access and disclosure, based on the security terms found in this contract, including means for protecting personal privacy and proprietary City Data;

Integrity, which means guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity; and

Availability, which means ensuring timely and reliable access to and use of City Data.

NOW, THEREFORE, the Parties agree as follows:

1. FIPS 199. The Provider’s Services and Systems will be categorized by the City and managed by the Provider based on the Federal Information Processing Standard (FIPS) Publication 199 of Low Impact, Moderate Impact, or High Impact.

2. Security and Privacy Governance. Provider shall maintain a cybersecurity program that documents the policies, standards, and controls it uses that secure the information and resources related to the Services. The documentation shall include organizational, administrative, technical, and physical safeguards and standards appropriate to the size, complexity, and scope of the activities, and the sensitivity of the City Data at issue.

3. Artificial Intelligence/Machine Learning Disclosure. The Provider must disclose if their Services and Systems include embedded Artificial Intelligence (AI) and/or Machine Learning (ML) components. If such technologies are utilized, the Provider shall provide documentation detailing the AI frameworks employed and demonstrate adherence to relevant AI compliance frameworks, such as the EU AI Act, NIST AI Risk Management Framework, ISO/IEC 42001

Section 6

(AI Management System), or other recognized AI governance standards. The Provider will update relevant compliance documentation as changes occur and provide notice of any such updates to the City.

4. Network Management.

a. Asset Management. Provider will perform asset management of all end points, or inventory, supporting directly or indirectly the System and City Data. End points include but are not limited to: (i) servers, (ii) workstations, (iii) printers, (iv) cell phones, (v) VoIP, (vi) AV devices, and (vii) physical security devices such as badge readers and CCTV. The Provider will provide an asset inventory list to the City upon request.

b. Host System Configuration. Provider has and will configure host systems according to an industry standard, such as ISO 27001. Systems must be configured to function as required and to prevent unauthorized actions. Provider will provide system configuration documentation to the City upon request.

c. System Network Monitoring. Provider must maintain an up-to-date continuous monitoring program performing a systematic approach for ongoing surveillance, analysis, and evaluation of the System’s security posture and activities. Provider has and will develop and implement an automated process to review and correlate log alerts and security events regularly for all System components in order to identify anomalies or suspicious activity. The review and correlation of log alerts and security events shall include but is not limited to: (i) all security events; (ii) logs of all critical System components; (iii) all privilege access, and (iv) logs of all servers and System components that perform security functions. Server and System component logs must include, but are not limited to, Firewalls, Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), Endpoint Detection & Response (EDR), and authentication servers (e.g., Active Directory domain controllers, RACF). Upon request, the Provider will provide evidence of continuous monitoring activities, including results of the monitoring.

d. Network Controls. Provider must ensure that all data and communications networks are secured to ensure the protection of City Data. All Provider Systems must remain up to date to the current release and be actively monitored with patches promptly installed.

e. Encryption. Provider will encrypt all City Data in transit, in process, and at rest using an encryption solution that meets, at a minimum, Advanced Encryption Standard-256 (AES-256) and Transport Layer Security (TLS) 1.3, or the most secure encryption algorithm available. Provider shall maintain key management practices to safeguard encryption keys used for data handling.

f. Remote Access. Remote access to a network containing City Data or access to City systems will be done via a secure connection with an authentication mechanism approved the City. All extranet connectivity into the City systems will be through City-approved and authorized secure remote connections. If remote access is provided by the City, the Provider is responsible for implementing logging and monitoring mechanisms to track remote access activities. Provider will furnish the City access to the logs upon request.

g. Access Control. Provider will restrict access to City Data to only authorized individuals to ensure that (i) only authorized individuals are permitted access to business applications, systems, networks, and computing devices containing City Data; and (ii) user access is scoped to the least privilege required to complete their assigned duties. Provider will review privileged user access, at a minimum, every three (3) months, and non-privileged users, at a minimum, every six (6) months.

h. Passwords and Multi-Factor Authentication. The Provider will adhere to all City Identification and Authentication requirements outlined in the Password Standards at a minimum. Provider personnel will use unique passwords that must remain confidential and will not be shared between Provider’s employees, contractors, or third-party users. All access shall require the Provider to use a multifactor authentication method when accessing City Data and City systems and networks.

i. Malware Controls. Provider shall ensure the System is protected with up-to-date anti-malware and endpoint detection and response (EDR) software. At all times during the provision of any Services, Provider will make reasonable efforts to ensure that all Services do not contain malicious software or malware. This includes regular scanning, monitoring, and updating of signatures and definitions to safeguard against emerging threats. The City reserves the right to request evidence of implementation and findings.

j. Vulnerability & Threat Management. Provider will ensure a vulnerability management program exists to identify and eliminate vulnerabilities and threats that could be exploited by malware or other technical methods (e.g., exploitation through technical vulnerabilities). The Provider’s program will include, at a minimum, regular vulnerability and compliance scanning, independent penetration testing, and threat intelligence analysis. Upon the Provider’s identification of vulnerabilities or threats, the Provider shall promptly implement appropriate measures. This includes but is not limited to: (a) vulnerability remediation; (b) software and firmware updates and patching; and (c) hardware maintenance. The Provider will not utilize software or hardware that is End of Life (EOL) and will implement appropriate security packages to remain in compliance.

k. Data Backups. To ensure the ability to restore the availability and access to City Data in a timely manner in the event of a physical or technical incident, Provider will ensure that backups of essential information and software, and in particular any City Data, are performed on a regular basis, according to a defined cycle in accordance with Provider’s internal policies and industry best practices, but no less than every 48 hours or as directed by the City in writing. Provider will work with the City to determine the Recovery Time Objective (RTO), Recovery Point Objective (RPO), and Maximum Tolerable Downtime (MTD) for the City’s Data and system. The City reserves the right to require more frequent backup frequencies based on the criticality of the City’s Data and System. Provider shall establish alternate and/or separate storage sites to ensure availability and accessibility of City Data. Provider shall test the backup process at least quarterly.

l. Secure Destruction. Provider will implement methods of destruction that are based on the type of media, including physical, paper-based media; physical, digital media;

and electronic, digital data. Provider will securely destroy sensitive information and maintain documentation of such destruction.

m. Virtualization & Cloud Solutions. If Provider utilizes a cloud solution, Provider will adhere to the same security principles required by this Addendum and applicable government regulations, laws, or directives,…