Compliance Controls - Philadelphia RFP

1. 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, pagerduty in place and can be used more on alerting side
2. Browser Support - The system has been tested to work with the latest versions of popular web browsers, including mobile device browsers. - done
3. 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. -done (needs to be reviewed for - documentations)
4. The system must have a dedicated test environment where all testing occurs. done
5. 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. done
6. APIs- APIs should be versioned, and as new versions are released adequate time must be given for conversion before older versions are retired. ?
7. 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 - (This means we should atleast have controls mapped with NIST req - like scrut said regrading this)
8. AUTH - 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. TBD
9. The system provides Multi-factor authentication as per the City MFA Policy. (in product mfa, if mentioned by city norms) TBD
10. 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) done
11. DR - The system can be recovered within the Recovery Time Objective and to a Recovery Point defined by the business stakeholders. (this doesnt state how, it depends how you define the rto) TBD
12. User interfaces meet WCAG AA 2.1 Standards. https://www.w3.org/TR/WCAG21/ (need to read this) TBD
13. Software should have localization features for the following recommended languages: Spanish, Simplified Chinese, Vietnamese, Portuguese, Russian, French, Arabic, Haitian Creole, Swahili. ?
14. 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 ?
15. 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. ?
16. 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. -posthog analytics (done)
17. 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. (done) - regarding the 99.9% uptime need to work around that as we hold only 30d data and a small 5 min downtime hits the numbers to 98%
18. 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. RDS done, need to activate wherever necessary
19. 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. (done)

All sites produced by vendors for the City, regardless of the hosting environment, shall conform to the WCAG 2.1 AA Accessibility Guidelines. https://www.w3.org/TR/WCAG21/

What the above includes: (These are mainly the UI - basic frontend requirements)

Level AA (what you need to meet) includes all Level A requirements plus specific AA requirements. Here are the key compliance areas:

• All non-text content must have text alternatives that serve the equivalent purpose
• Captions for all prerecorded audio content in synchronized media
• Captions for all live audio content in synchronized media
• Audio description for all prerecorded video content
• Content must not restrict view to single display orientation unless essential
• Input field purposes must be programmatically determinable for user information
• Text and background must have contrast ratio of at least 4.5:1 (3:1 for large text)
• Text can be resized up to 200% without loss of content or functionality
• Content can be presented without horizontal scrolling at 320 CSS pixels width
• Visual presentation of user interface components must have 3:1 contrast ratio
• Text spacing can be adjusted without loss of content
• Additional content triggered by hover/focus must be dismissible, hoverable, and persistent
• Keyboard Accessibility (Level A) : All functionality must be operable through keyboard interface
• No keyboard traps - focus can always move away from components
• Character key shortcuts must be able to be turned off, remapped, or only active when focused
• Users can turn off, adjust, or extend time limits
• Moving, blinking, or auto-updating content can be paused, stopped, or hidden
• No content flashes more than three times per second
• No change of context when components receive focus
• No automatic context changes when settings change
• Components with same functionality must be identified consistently
• Input errors must be automatically detected and described
• Labels or instructions provided when content requires user input
• Error correction suggestions provided when known
• Legal/financial transactions must be reversible, checked, or confirmed
• Markup must have complete start/end tags, proper nesting, unique IDs
• Name and role must be programmatically determinable for all UI components
• Status messages must be programmatically determinable through role or properties

For WCAG 2.1 AA conformance, all Level A and Level AA success criteria must be satisfied for the entire web page Web Content Accessibility Guidelines (WCAG) 2.1. The page must also use only accessibility-supported technologies and ensure non-interference with assistive technologies.

Following are the additional requirements only for custom - on prem services (NOT FOR our cloud based saas SMART360) -

If we get an on premise setup for SMART360 will require the following