2-MWJ2604-Section 7.4.1 - Interrogatories-07162026.xlsx
XLSX spreadsheet 43 KB Posted
- Attached to
- Identity Verification System
- Solicitation number
- MWJ2604
- Issued by
- Cook County, Illinois
About this file
This is a Request for Proposals (RFP) interrogatories document for the City Colleges of Chicago (CCC) seeking an Identity Verification System solution to detect fraudulent student applications. The RFP, numbered MWJ2604, addresses two primary fraud categories: submissions using stolen or synthetic identities to exploit financial aid programs and applicants with no genuine intent to enroll. The solution must provide identity verification, residency document verification, and digital fraud assessment integrated into the student application workflow. Proposals are due August 21, 2026, no later than 12:00 p.m. (CDT). The interrogatories document comprises multiple sections: Requirements (16 business requirements addressing vendor understanding of community college operations, implementation track record, and system configuration), Functional Requirements (18 requirements covering document processing, biometric analysis, risk scoring, and reporting capabilities), Technical Requirements (17 requirements addressing system integration with PeopleSoft and Salesforce, data encryption, compliance, and infrastructure), Information Security Requirements (17 requirements covering access controls, audit trails, data protection, and encryption standards), Technical Interrogatories (detailed questions across application, security, operations, and regulatory categories), and three appendices addressing backup specifications, retention periods, and support service level agreements.
The document does not specify pricing terms, set-asides, incumbent contractor information, or detailed funding sources. Key technical requirements include 24/7 system availability during peak admissions periods, real-time and historical reporting capabilities, WCAG 2.1 Level AA accessibility compliance, integration with PeopleSoft CS and Salesforce CRM, encryption using TLS 1.2 or higher and AES-256 algorithms, and support for SAML-based SSO authentication compatible with Microsoft Entra ID or ADFS. The vendor must demonstrate scalability to handle CCC's peak single-day application volume, provide annual SOC 2 Type 2 security audit reports, maintain data exclusively within the United States, and establish tiered service level agreements addressing high, medium, and low severity issues. Data ownership remains with CCC; vendor may not use CCC data beyond serving CCC operations. Upon contract termination, all CCC data must be purged within 30 days following download and integrity verification by CCC.
View the file
Other files
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
Overview
| CITY COLLEGES OF CHICAGO |
| RFP #MWJ2604 - Identity Verification System |
| Proposals Due: August 21, 2026, no later than 12:00pm (CDT) |
| SECTION 7.4.1 - INTERROGATORIES |
| 1. This document contains the following tabs: |
| Requirements |
| Technical Interrogatories |
| Appendices A, B, C |
| 2. Format Alteration |
| DO NOT alter the layout or format of the spreadsheets in any way. Doing so may result in the loss of your company's data and exclusion from further consideration. You may expand the detailed response cell(s) of the spreadsheets only. |
Requirements
| CITY COLLEGES OF CHICAGO |
| Request For Proposals (RFP) #MWJ2604 - Identity Verification System |
| Proposals due: August 21, 2026 |
| SECTION 7.4.1 - INTERROGATORIES (REQUIREMENTS) |
Proposer's Name
| Business Requirements | ||||
| ID | Requirements | Priority | Solution Meets Requirement (Y/N) | Please provide details as appropriate |
| BR-1 | The Vendor must demonstrate a clear understanding of community college enrollment processes and the open-access mission that defines them. This includes familiarity with the diverse and non-traditional student populations that community colleges serve, the barriers those students may face during the application process, and how those realities should inform the design and configuration of the fraud detection solution. The Vendor must document this understanding in their proposal and explain how it has shaped or will shape their approach to implementing the solution at CCC. | |||
| BR-2 | The Vendor must demonstrate a proven track record of successfully implementing their solution at large, complex higher education institutions. The Vendor must provide verifiable references and supporting data such as implementation timelines, volume of applications processed, and measurable outcomes — from comparable deployments to demonstrate that their solution can perform at the scale and complexity of CCC's environment. | |||
| BR-3 | The Vendor must provide a detailed implementation plan that defines how CCC staff, admissions teams, and applicants will interact with the fraud detection and identity verification system at each stage of the application review process. | |||
| BR-4 | The Solution must automatically screen every incoming application for fraud. This includes checking for signs of stolen or fake identities, unusual application patterns that don't look like genuine enrollment behavior, and inconsistencies in the information provided. | |||
| BR-5 | Based on the risk score, the Solution must be able to automatically send the application for identity verification. CCC must be able to configure the thresholds that drive these decisions, and the Vendor must clearly document how the scoring works. | |||
| BR-6 | The Solution must guide the applicant through a verification process if the application is flagged as suspicious; this includes uploading a government-issued ID and a selfie for biometric comparison. | |||
| BR-7 | The Solution must provide robust fraud indicators capable of accurately distinguishing between fraudulent and legitimate student applications across CCC's full applicant population. | |||
| BR-8 | The Vendor must document all fraud indicators, including the logic and weighting behind each, and must demonstrate that the model reliably differentiates between genuine fraud and the legitimate application behaviors of the populations CCC serves. CCC must retain the ability to review and tune fraud indicator thresholds to reflect its institutional context and student demographics. | |||
| BR-9 | The solution must be fully configurable. CCC is seeking to control the thresholds that drive decisions to auto-approve or flag identity verification. The Vendor must not apply a one-size-fits-all model, as CCC serves populations whose application patterns may differ from conventional norms without indicating fraud. | |||
| BR-10 | The system must automatically check applicants against certain lists (fraud registries, etc.). The Vendor must specify which lists exactly, and these lists should be confirmed with CCC's legal and compliance teams. | |||
| BR-11 | The solution must significantly reduce the manual review workload on CCC admissions staff by automating the interpretation of fraud assessment and verification results, routing only genuinely ambiguous cases to human reviewers. | |||
| BR-12 | The Vendor must demonstrate, with evidence from comparable institutions, that their solution meaningfully reduces manual review workload for admissions staff. | |||
| BR-13 | When an application is flagged for manual review, the system must present the reviewing staff member with all relevant supporting evidence including fraud indicators, verification results, and applicant-submitted documents in a single, consolidated view, so that reviewers can make informed decisions quickly without having to locate or compile information from multiple sources. | |||
| BR-14 | The Vendor must support CCC's readiness for adoption by providing clear and accessible documentation, training materials, and communication resources for all affected staff, including admissions teams, financial aid staff, and any other stakeholders involved in the fraud detection and verification workflow. These resources must be sufficient to ensure that staff understand the system, their role within it, and how to handle the full range of outcomes it may produce. | |||
| BR-15 | The Vendor must demonstrate clear and immediate operational value to CCC's admissions and enrollment teams. This includes showing, early in the implementation process, how the solution reduces manual workload, improves decision consistency, and speeds up application processing, so that staff can see tangible benefits quickly and adoption is not hindered by uncertainty about the system's practical impact on their day-to-day work. | |||
| BR-16 | The Vendor must demonstrate that the solution is scalable and capable of growing to meet CCC's future needs. This includes the ability to handle increased application volumes without degradation in performance, as well as the capacity to extend the solution's verification capabilities beyond the initial scope of student application fraud detection to additional use cases. | |||
| BR-17 | The Solution must be available 24/7, including during peak admissions periods and enrollment windows. | |||
| BR-18 | The Vendor must provide a project manager who supports the full implementation of the chosen solution. | |||
| BR-19 | The Solution should be able to provide real time and historical reports. | |||
| Functional Requirements | ||||
| ID | Requirement | Priority | Solution Meets Requirement (Y/N) | Vendor Details |
| FR-1 | The solution must accept uploaded images or scans of US government-issued photo IDs (e.g., driver's license, passport, state ID, Chicago CityKey, etc.). | |||
| FR-2 | The solution must be capable of scanning and authenticating residency documents, submitted as a part of enrollment process including bank statements, utility bills, leases, and government-issued IDs, to determine whether each document is genuine unaltered, and valid. | |||
| FR-3 | The solution must detect fraud through operational signals that go beyond authenticating individual documents. This includes identifying patterns across multiple applications, such as the same address appearing on submissions from different applicants, as well as detecting reused or recycled documents that may be authentic on their own but indicate coordinated fraud when viewed in context. | |||
| FR-4 | The solution must be capable of identifying applicants who use personal data acquired through identity theft, individuals who may pass standard identity and document checks, through behavioral and contextual signals that indicate the applicant is not the true owner of the identity being used. | |||
| FR-5 | The solution must validate document format, expiration date, and authenticity markers. | |||
| FR-6 | The solution must detect tampered, edited, forged, or counterfeit documents. | |||
| FR-7 | The solution must extract and parse key data fields (name, date of birth, document number) from submitted documents. | |||
| FR-8 | The solution must analyze a selfie or short video of the applicant during the verification process. Scope (all applicants vs. flagged only) to be decided by CCC. | |||
| FR-9 | The solution must perform liveness detection to prevent spoofing via printed photos, masks, or digital replays. | |||
| FR-10 | The solution must perform a biometric match between the applicant's selfie and the photo on the submitted ID document. | |||
| FR-11 | The solution must provide a confidence score for each biometric match result. | |||
| FR-12 | The solution must generate a risk score for each verification attempt, based on document, biometric, and behavioral signals. | |||
| FR-13 | The system must automatically approve applications that score below a configurable low-risk threshold. | |||
| FR-14 | The solution must automatically route applications that score above the low-risk threshold but below the high-risk threshold into a remote identity verification workflow, where the applicant will be prompted to upload a government-issued ID and a selfie for biometric comparison or similar process. | |||
| FR-15 | The system must automatically flag applications that score above a configurable high-risk threshold for in person document review at a CCC admissions office. | |||
| FR-16 | CCC reviewers must be able to view, filter, and act on items in the manual review queue. | |||
| FR-17 | The solution must provide a real-time dashboard showing verification metrics and KPIs, with the ability to generate scheduled compliance reports exportable in PDF and CSV formats. | |||
| FR-18 | The solution must maintain a full, tamper-proof audit log of all verification events, including decisions, overrides, and reviewer actions. | |||
| Technical Requirements | ||||
| ID | Requirement | Priority | Solution Meets Requirement (Y/N) | Vendor Details |
| TR-1 | The solution must integrate with PeopleSoft CS and Salesforce CRM to enable automated routing and workflow triggers based on verification outcomes. | |||
| TR-2 | The solution shall support reliable batch processing of large volumes of student records with confirmed delivery of results for review. | |||
| TR-3 | The solution must scale to handle CCC's peak single-day application volume. CCC to provide historical peak volume figures to vendor during scoping. | |||
| TR-4 | All PII and biometric data must be encrypted at rest and in transit using industry-standard protocols. | |||
| TR-5 | PII and verification data must be retained and automatically purged per regulatory and CCC requirements. Legal review required before finalizing. | |||
| TR-6 | The solution must capture the external IP address of applicants and apply IP validation, geolocation, and VPN/proxy detection services to flag high-risk connections. | |||
| TR-7 | The solution must comply with CCC's cybersecurity requirements and applicable information security controls and data handling standards. | |||
| TR-8 | The solution must include built-in analytics, dashboards, and reporting tools to support ongoing monitoring, peer benchmarking, threshold calibration, and performance review. | |||
| TR-9 | User-facing UI must meet WCAG 2.1 Level AA accessibility standards in accordance with CCC policy. | |||
| TR-10 | The Vendor must confirm whether their solution supports Single Sign-On integration with CCC's existing identity provider. If SSO is supported, the Vendor must document the supported protocols (e.g., SAML, OAuth) and describe the implementation process. If SSO is not natively supported, the Vendor must describe how CCC staff and applicants will authenticate into the system and what controls are in place to manage access securely. | |||
| TR-11 | The Vendor must clearly disclose where the solution is hosted, who is responsible for hosting and infrastructure management, and where applicant data is stored and processed. | |||
| TR-12 | The Vendor must confirm whether data resides within the United States and whether it meets applicable data privacy and security requirements. | |||
| TR-13 | If the implementation involves migrating any existing CCC applicant data into the Vendor's platform, the Vendor must provide a detailed data migration plan that addresses data mapping, validation, security during transfer, and rollback procedures in the event of migration failure. | |||
| TR-14 | The Vendor must define and adhere to a tiered SLA that classifies system issues by severity and specifies response and resolution timeframes for each. At minimum, the SLA must address the high, medium and low severity levels. The Vendor must document escalation contacts, and a post-incident review process for high severity events. | |||
| Information Security Requirements | ||||
| ID | Requirement | Priority | Solution Meets Requirement (Y/N/NA) | Vendor Details |
| IS-1 | The solution must provide capability to provision users and restrict access for various tiers by roles and responsibility (authorization) using Role-Based Access Controls (RBAC). | |||
| IS-2 | The solution must be safe-guarded against hacking attacks. | |||
| IS-3 | The solution must be able to record an audit trail of changes made to the application configurations and to CCC data. The minimum criteria for audit logs should be date, time, user performing the change, and changes made. | |||
| IS-4 | CCC will own all data loaded into the system, including log data relating to use of the system. Vendor may not use CCC data in any way other than to serve CCC. | |||
| IS-5 | Advanced written approval from CCC authorized contact must be obtained for any data usage not outlined in the agreement. | |||
| IS-6 | Data must be kept secure and backed up using contemporary redundancy and backup standards. | |||
| IS-7 | Data must not be stored or processed outside of the USA. | |||
| IS-8 | Disaster recovery solutions must be described, and any future technology or provider changes reported to CCC. | |||
| IS-9 | Externally hosted solutions must provide annual SOC 2 type 2 or similar applicable security audit reports, annually and upon request. | |||
| IS-10 | Each time CCC data is moved to a new production environment, any remaining CCC data on vendor’s decommissioned partitions, snapshots and systems must be destroyed and purged no longer than 30 days after the upgrade. | |||
| IS-11 | Upon the termination or expiration of the Agreement, the Company will make all CCC data (content, logs, etc.) available to CCC for download for up to 3 months. | |||
| IS-12 | Upon the termination or expiration of the Agreement, and no longer than 30 days after the data has been downloaded by CCC and its integrity verified by CCC, any remaining CCC data on Company’s systems must be permanently purged and destroyed by the Company. | |||
| IS-13 | Any and every outsourced functionality or service must be identified and reported to CCC, and the third party named by the primary vendor whenever it is engaged or when its engagement ends or changes. | |||
| IS-14 | CCC must be immediately informed (within 72 hours of discovery), in writing, of the scope and nature of any breaches that endanger functionality or expose any PII or other confidential or sensitive information. | |||
| IS-15 | Encryption Requirements: |
1) The solution must use contemporary, future-proof encryption for data at rest, in transit, and in use.
2) Supported protocols: TLS 1.2, 1.3 or higher; SSL and earlier TLS versions are prohibited.
3) Encryption Algorithms: AES256 or stronger. Hashing algorithms: SHA256 or stronger.
4) Certificate management: Only certificates from trusted authorities; self-signed certificates or broken chain of trust are not permitted for external-facing solutions.
| IS-16 | External systems sending email from a CCC email address must support DMARC-based message authentication. Both DKIM and SPF should be configured. DKIM must be implemented at a minimum. If DKIM keys are published as TXT records (rather than CNAME), they must be 2048-bit in length. |
| IS-17 | Systems must support SAML-based SSO (single sign-on) authentication compatible with EntraID or, less preferred, ADFS |
Technical Interrogatories
| CITY COLLEGES OF CHICAGO |
| Request For Proposals (RFP) #MWJ2604 -Identity Verification System |
| Proposals due: August 21, 2026 |
| Section 7.4.1 - Interrogatories (Technical) |
| Proposer's Name |
| Technical Interrogatories SAAS | ||||
| Please respond to the questions listed here as appropriate | ||||
| Category | Sub-Category | SAAS (Software-as-a-Service) | Yes/No or NA | Please provide details as appropriate |
| Application | Reporting | List and describe all reports included in the base software package. | ||
| Please describe how reports are created and run | ||||
| Please provide a list of major requested custom reports. | ||||
| Application | Data Extract/Import | Do you provide a tool to extract or import information from/to your system? | ||
| If so, what formats are supported (pdf, MS-Word/Excel, XML, etc…) | ||||
| Application | Access to Data Model | Do you provide a data model (diagram) and/or data dictionary for your application? | ||
| What options are available for CCC to access your system data? Do you allow backend database or system updates or is it view-only? | ||||
| Do you provide delivered APIs to access and/or update information? | ||||
| Application | Integration/Interface | List integration and/or interfaces delivered with the standard system. | ||
| What information do you need CCC to provide to your application (required versus optional)? How frequently? What formats are acceptable? | ||||
| Describe any delivered integrations available with 3rd parties (e.g., PeopleSoft)? | ||||
| What forms of secure transmission do you support: sftp? ssl? ftp with pgp? Other? | ||||
| What integration options are available (real-time services, batch, near real-time, etc…)? | ||||
| Application | Configuration/Customization/Branding | For an average client, what is the percentage of customizations versus configuration? | ||
| Give an example of a common customization or a situation where a customization is required (i.e., something that cannot be configured as delivered) | ||||
| What skill sets are required to configure the application (how much training is required and what training/support materials are delivered)? | ||||
| Who performs the customizations (CCC and/or Vendor)? If CCC is allowed to customize, what is allowable to avoid violating the licensing agreement/warranty? | ||||
| What programming expertise is required to customize the application? | ||||
| Describe all the areas that can be “configured” (e.g., setup, transaction processes, security, workflow, online validations, etc…) | ||||
| Application | Workflow/Approvals/Proxy | Does your application allow configurable workflow? | ||
| Does your application allow workflow approvals (multi-levels)? | ||||
| Application | Transaction Audits | What types of transaction audits are available with the standard system? What information is not audited? | ||
| Is the audit data readily available for access? To whom? Can we audit by campus? | ||||
| At what point do you purge the audit information? | ||||
| Application | Data Integrity/Validations | Explain in detail how the application maintains data quality and integrity (address online, batch, etc…) | ||
| For situations where there is not an “edit” to maintain data quality/integrity, what other safeguards are available as delivered (e.g., reports, periodic batch validation programs, etc…) | ||||
| Application | Operations/Scheduling | How are interfaces, reports, and other batch processes scheduled and the results distributed? | ||
| Differentiate between CCC and Vendor responsibilities and access. | ||||
| Application | Communications (Email, Texting, Chat, Other) | Do you have email capabilities (single user, mass email)? Please elaborate | ||
| Network | Redundancy/Failover/Load Balancing | Explain what safeguards are in place to minimize the risks of failure (address appropriate tiers) | ||
| Explain your load balancing capabilities (address appropriate tiers) | ||||
| Servers | VPN | Does your application encrypt the session between the server and the end user? | ||
| Storage/Database | Database requirements | What environments are standard? Can CCC request additional environments as needed for the build-out as well as future needs (e.g., Development, Testing, Production, Training, etc…)? What database platform do you utilize? | ||
| How do you determine the initial database size? How do you adjust for actual and planned growth? | ||||
| How much space is included in the standard offering for each environment? | ||||
| What is the incremental cost for additional environments and/or space requirements? | ||||
| Storage/Database | Data Purge, Retention, Backup, Restore, and Recovery | Discuss your data archive, purge, and retention strategy as it relates to various tiers. | ||
| Discuss your backup, restore, and recovery strategy as it relates to various tiers. Please complete Appendix A and B. | ||||
| Storage/Database | Disaster/Recovery, Business Continuity | Discuss your disaster/recovery capabilities and architecture. | ||
| How often do you test Disaster Recovery with each client? | ||||
| What is the maximum data loss in the event of catastrophic system failure? | ||||
| Security | Various tiers - Access, Roles | Explain how you provision users and restrict access for various tiers by roles and responsibility (authorization)? | ||
| Do you have the capability to import user access roles from other systems? | ||||
| Security | Identity and Access Management (IAM) and Directory Services | Please share details on the Identity and Access Management (IAM) and Directory Services your solution supports, including: |
Authentication protocols (LDAP, Active Directory, SAML, OAuth, OpenID Connect) Federation capabilities (ADFS, Microsoft Entra ID/Azure AD) SSO and MFA options Directory sync or provisioning Hybrid environment support (on-premises and cloud) Any limitations or prerequisites for Entra ID integration?
Our environment is transitioning from ADFS-based SSO to Microsoft Entra ID. Please confirm compatibility with both and outline any migration considerations. Is this delivered or does it have to be built?
| Discuss examples of single sign-on capabilities to provide seamless user access as they transition between multiple systems and/or applications | ||
| Security | Database security | Explain how highly confidential data is maintained and encrypted during storage |
| Security | Data Center/Physical Security | Provide an overview of your data center and its operations and controls |
| Is your data center SAS-70 certified or similar? Discuss how you maintain compliance and insure it quality and reliability. | ||
| Discuss physical security to limit unauthorized access to that data center | ||
| How often is your data center audited? | ||
| When was the most recent 3rd party audit performed and can you provide the results to CCC? | ||
| Security | Intrusion Detection/Virus | What safeguards are in place to prevent malicious 3rd party attacks and intrusion? |
| Do you have automated logging for all application activity? | ||
| How do ensure that your system is current to prevent all malware? | ||
| How does your application prevent threats such as SQL injection? | ||
| How often are 3rd party security audits performed? Provide the most recent report(s). | ||
| Security | General | What security logs does the host provider maintain and which tiers? |
| Upon request, vendor needs to provide CCC access to security logs | ||
| What security standards and methods are utilized (SSL/VPN Tunnel, Antivirus, Encryption, etc…) | ||
| The vendor shall provide applicable Service Organization Reports (SOC II type 1 and 2) or complete the CCC Audit Checklist if it does not perform SOC testing | ||
| The vendor shall address PCI compliance requirements in a manner that minimizes risk to the College, provide certification of compliance with all current Payment Card Industry (PCI) standards (if applicable) | ||
| Ongoing Maintenance | Project/Application Documentation | What documentation do you provide for the project implementation and ongoing use? |
| Ongoing Maintenance | Upgrades, Releases, Patches | What is the most current release? When was it first available? When is the next release scheduled? What is currently included in the next release. |
| Describe the process for customers to provide input into your future releases | ||
| Discuss your patch, upgrade, and release strategy and address the following: Frequency, Time to Apply, Roles and Responsibilities, Dependencies, Testing, Contingency/Rollback, etc… | ||
| Describe your process for providing release notes (timing, formats, content)? | ||
| Discuss how a change (configuration or customization) moves from request, development, testing, and production. | ||
| Describe your change control and version control process. | ||
| Describe what is included in your maintenance agreement as it relates to application/system bug/fixes. | ||
| Ongoing Maintenance | Support/Call Center - Response, Resolution, Escalations, Hand-off (CCC and Vendor) - SLAs | Provide a sample Service Level Agreement document specifying response and resolution times for Production/Non-Production (based on various severities/priorities/tiered support) Please Complete Appendix C |
| How do you adjust your employee resources for peak times? | ||
| Describe your help desk support activities and process. How would you coordinate with CCC’S centralized Service Desk? | ||
| Are there penalties if SLAs are not met, describe? | ||
| Ongoing Maintenance | Warranties | What do you warranty as part of your standard offering? |
| Ongoing Maintenance | Availability: System, Application, Network, Servers, etc… | Discuss your guaranteed application and system availability (percentage) |
| Discuss your planned outages (address all tiers) | ||
| How flexible is your maintenance windows and can it be integrated and/or coordinated with CCC? | ||
| Other | Scalability - Various Tiers | Describe how your architecture (system resources) supports peak times and considers various concurrent activities (online, batch, services, reporting, etc…) |
| Other | Mobile Device Capabilities | Does your application support mobile devices? Can you provide an example? |
| Other | Stress/Performance assurances/peak times | Discuss your strategies for performance/stress testing to ensure maximum system efficiency during normal and peak times |
| How do you ensure adequate network bandwidth? | ||
| Other | Monitoring - Trend analysis, Diagnostics | Discuss what tools and/or applications do you utilize to ensure maximum system availability? What is available for CCC to utilize? When is CCC alerted? |
| How do you proactively identify potential issues? | ||
| Other | Additional software licenses | Is there specific 3rd party software required for your application? |
Which software licenses will you provide free to CCC for the duration of the contract agreement term?
| Other | Client hardware/software/version requirements | Detail specific client workstation and/or software versions and requirements (e.g., web browsers, desktop memory, display resolution, etc…) |
| Can you provide an overall architecture Visio document? | ||
| Government Regulations | HIPPA, SOX, FERPA, Security, Data Retention | With which government requirements/mandates do you comply (HIPPA, ADA Section 508, FERPA, etc…)? |
| Clearly delineate between Vendor and CCC responsibility as it relates compliance with government law, regulations, contracts, etc… | ||
| Legal | Electronic Signatures | If applicable discuss how your application utilizes and facilitates electronic signatures. Provide an example. |
| General | Value-added | Provide a listing of all Vendor value-added offerings |
| Legal | Ownership of CCC information | Discuss what the demarcation between CCC and vendor ownership of information. |
| Legal | Exit agreements (tasks/responsibilities) | Discuss roles/responsibilities, timeframes, obligations of vendor and CCC if the agreement is terminated. |
Appendices A, B, C
| CITY COLLEGES OF CHICAGO |
| Request For Proposals (RFP) #MWJ2604 - Identity Verification System |
| Proposals due: August 21, 2026 |
| Section 7.4.1 - Interrogatories (Appendices A, B, C) |
| Proposer's Name |
Appendices A, B, C
| Appendix A - Backup | ||
| Description | Please provide details (Timing, e.g. Daily, weekly, monthly etc.) | |
| Baseline | Pre-Production Image | |
| Daily Incremental Files | Data changes during the period all tiers all environments | |
| Full Data Files | All resident data files all tiers all environments | |
| Applications | All application files (full data files including cold backups) | |
| Operating System | All O/S configuration files – all tiers all environments | |
| Database | All database – all tiers all environments. | |
| Fall Back Copy | At request of the Board when a change is made to the Board system a copy will be made before the change. |
| Appendix B - Retention | |
| Description | Retention Period |
| Baseline | |
| Daily | |
| Weekly | |
| Monthly | |
| Annual | |
| Key Calendar Dates |
| Appendix C - Support (SLA) | ||||
| Environment | Priority | Response Time | Max Resolution Time | RCA - Root Cause Analysis Max Turnaround Time |
| Production | High | |||
| Production | Medium | |||
| Production | Low | |||
| Development/Test | High | |||
| Development/Test | Medium | |||
| Development/Test | Low |
File details come from the government source that posted it. Updated .