Vetting Criteria

Artificial Intelligence (AI)

Prince George's County Public Schools (PGCPS) is committed to the responsible and ethical use of Artificial Intelligence to support instructional and operational goals. To ensure the protection of student and employee privacy, all AI-enabled tools must undergo a rigorous vetting process in accordance with PGCPS Board Policy 0123 and the Maryland Student Data Privacy Act (MSDPA), Maryland Code, Education § 4-131.

1. Mandatory AI Declaration & Vetting

All vendors are required to complete the Artificial Intelligence Declaration Addendum (AIDA).

• • Full Disclosure: Vendors must explicitly state if their platform incorporates AI, machine learning, or automated decision-making. This includes identifying the underlying models used, the primary user audience (students vs. staff), and the specific data points captured for AI functionality.
• Prohibition of "Silent" Updates: AI features may not be added to previously approved products without an updated AIDA filing.
• Testing Logon: Vendors will be required to provide a logon or sandbox to test AI features in the platform.

2. Protection of Covered Information (MSDPA § 4-131)

In alignment with Maryland law, student "Covered Information" may only be used for a "PreK-12 School Purpose."

• Training Data Restrictions: Vendors are strictly prohibited from using PII or any data acquired through the use of the service to train, improve, or refine Large Language Models (LLMs) or other AI systems for non-PGCPS purposes.
• No Commercial Profiling: AI systems must not be used to create profiles of students for targeted advertising or any secondary commercial gain.

3. FERPA and "Direct Control"

To qualify as a "School Official" under FERPA, vendors must ensure that PGCPS maintains direct control over the data processed by AI systems.

• Data Portability & Deletion: AI-generated content including derived and inferential data (e.g., student outputs, adaptive learning logs, risk scores, student learning profiles, etc.) is considered an "Education Record" and must be exportable or deletable upon PGCPS request.
• Security Standards: AI processing must meet the same encryption and access control standards required for all other Institution Data, as outlined in the DPSA and Information Security sections.

4. Performance and Audit Rights

PGCPS reserves the right to audit the Vendor's AI algorithms and data practices at any time to ensure compliance with district privacy standards. Vendors must maintain documentation regarding how data flows through their AI systems and must remediate any identified privacy risks within 60 days.

Data Privacy

In alignment with Maryland Online Data Privacy Act (MODPA) and the Maryland Student Data Privacy Act (MSDPA), Maryland Code, Education § 4-131, Prince George's County Public Schools (PGCPS) is working toward a zero-trust posture regarding student and employee data. A signed Data Privacy and Security Agreement (DPSA) is required for any third party that stores, processes, or accesses "Institution Data."

1. Strict Data Minimization

PGCPS enforces a "Strict Necessity" standard. Vendors must limit the collection of personal data to what is reasonably necessary and proportionate to provide the specific educational service requested.

• Vendors must provide a granular justification for every data field requested. This applies to staff, student, or institutional data.
• Under MODPA, consent does not override the requirement for data minimization; PGCPS will reject any data collection deemed excessive or non-essential to the product's primary instructional function.

2. Prohibition on Targeted Advertising and Profiling

PGCPS strictly prohibits vendors from:

• Engaging in Targeted Advertising based on any information (including persistent unique identifiers) acquired through the use of the service.
• Using student data to create a "Profile" of a student for any purpose other than the authorized K-12 school purpose.
• Selling Student Data: The sale of student data or the personal data of any consumer known to be under the age of 18 is an absolute statutory prohibition under both MSDPA and MODPA.

3. Sensitive or “Covered” Data

Maryland law imposes a "Strictly Necessary" processing standard for Sensitive or “Covered” Data. In Maryland, covered data includes, but is not limited to:

• Biometric and health data, including voice and video.
• Precise geolocation (within 1,750 feet).
• Data revealing race, ethnic origin, religious beliefs, or health status.
• Persistent Identifiers (customer numbers, cookie IDs, and hashed unique identifiers) used for tracking.

Vendors must indicate in Exhibit A if any sensitive data is processed and certify that such data is never sold or used for secondary purposes.

4. Direct Control

Through the DPSA, vendors are contractually designated as "School Officials" under the Family Educational Rights and Privacy Act (FERPA). As such, vendors operate under the "direct control" of PGCPS and are prohibited from re-disclosing PII to any third party or subprocessor without explicit written authorization and a documented Exhibit B (Subprocessor List).

5.  Data Processing/Storage limited to United States

Student data or other sensitive institutional data may only be stored/processed in the United States.

6. Data Retention and Deletion

Vendors are required to return and/or confirm the deletion of data, adhering to the data retention and deletion requirements specified within the Data Privacy and Security Agreement (DPSA).

Information Security

Third-Party Security Verification & Compliance Prince George's County Public Schools (PGCPS) requires all vendors to provide verifiable evidence of a robust security program. Under Maryland Education Code § 4-131 (MSDPA), any "operator" (vendor) must implement and maintain reasonable security procedures and practices to protect Covered Information from unauthorized access, destruction, use, modification, or disclosure.

1. Mandatory Audit Documentation

To satisfy the "reasonable security" standard, PGCPS requires an independent third-party audit for any platform that stores, processes, or accesses sensitive data fields.

• Required Evidence: A recent SOC 2 Type 2 Audit Report (covering Security and Confidentiality) or an ISO 27001 Certificate with a Statement of Applicability (SoA) is required.
• Recency Standard: All reports and certificates must be dated within the last 18 months.
• Alternative Review: If an independent audit is not available, vendors must complete the Exhibit A - Part 2 (Vendor Security Practices) spreadsheet in its entirety. Note: PGCPS reserves the right to reject products that do not provide adequate security assurances for sensitive student data.

2. Security Standards for Covered Information

Per MSDPA requirements and PGCPS expectations, vendors must demonstrate specific technical and administrative safeguards for all "Covered Information":

• Multi-Factor Authentication (MFA): MFA must be required for all vendor administrative and privileged access, and extended to all user roles for tools handling sensitive data.
• Encryption Mandate: All Institution Data must be encrypted at rest and in transit using industry-standard protocols (e.g., AES-256, TLS 1.2+).
• Identity Management: Vendors are prohibited from requiring staff or students to manually create accounts. All access must be via the PGCPS-approved SSO methods outlined in the Interoperability Addendum.
• Vulnerability Management: Critical and High-severity vulnerabilities must be remediated within 30 days of discovery to maintain compliance.
• Breach Notification (The 72-Hour Rule): In accordance with DPSA Section 4.6, vendors must notify PGCPS of a Data Breach within 72 hours of discovery.
• Cyber liability insurance: Vendors that store, process, or access Covered Information must maintain a commercially reasonable cyber liability insurance policy for the duration of the contract and twelve (12) months following termination. Coverage must include data breach response, regulatory defense, third-party liability from unauthorized disclosure of PII, and network security failures including ransomware. Vendors must provide a certificate of insurance upon registration, annually thereafter, and notify PGCPS within thirty (30) days of any material change, cancellation, or non-renewal of coverage.

3. Exhibit A - Part 2: Detailed Security Responses

If an independent review is not provided, vendors must provide detailed responses regarding their organization’s practices in the following areas:

• Data Security & Integrity: Measures to ensure data is not improperly altered or destroyed.
• Authentication & Access Controls: Ensuring only authorized personnel have access strictly for "PreK-12 School Purposes."
• Incident Response: Documented plans for containment, investigation, and recovery.
• Employee Awareness: Verification that all staff with access to Institution Data undergo annual privacy and security training.
• Subprocessor Security: Evidence that all 3rd party integrations (listed in Exhibit B) are held to the same security standards as the primary vendor.

Interoperability

PGCPS prioritizes seamless and secure access to digital resources. In compliance with Maryland Education Code § 4-131, all automated data exchanges of covered information must utilize secure, encrypted protocols that protect the confidentiality and integrity of such data.

1. Authentication & Single Sign-On (SSO)

To maintain "direct control" over student records as required by FERPA and Maryland law, and to maintain security over access to organizational data, PGCPS requires all products to support District-managed SSO.

• Approved Methods for Instructional products:
  • Clever SSO (preferred method for instructional products)
  • Canvas LTI 1.3 or 1.3A (limited to district-level instructional products)
  • ADFS/SAML 2.0/EntraID
  • Google SSO
• Approved Methods for Operational/Non-instructional products:
  • ADFS/SAML 2.0/EntraID
  • Google SSO
• Unapproved Methods
  • Manually created student accounts:  Vendors are strictly prohibited from allowing students or staff to manually create accounts using PGCPS email addresses. This is a critical security control to prevent unauthorized data profiling.
• In rare cases, the district may provide written permission for manual accounts to access higher ed content or certification exam platforms.
  • Manually created staff accounts will be evaluated on a case-by-cases basis and will take into account the nature of the data being processed. Where accounts provide access to sensitive data (personal or institutional), SSO must be an option.

2. Automated Roster Management 

To eliminate the security risks associated with manual file uploads and ensure that data syncs are limited to the minimum fields required for instruction, PGCPS requires vendors to implement automated rostering/data transfers.

• Approved Methods for School-Based Purchases:
  • Clever Secure Sync
  • Class Codes/Join Links - when SSO is in place and/or no additional PII is needed
• Approved Methods for District-Level/Enterprise Purchases:
  • Clever Secure Sync (Preferred)
  • Class Codes/Join Links - when SSO is in place and/or no additional PII is needed
  • Canvas LTI 1.3
  • OneRoster SFTP or API (requires additional vetting)
  • Proprietary API or formatted CSV via SFTP (requires additional vetting)
• Unapproved Methods
  • Google Classroom
  • Manually created student rosters: Vendors are strictly prohibited from requiring or allowing staff to manually create or upload student rosters.
• Data Scoping
  • Vendors must only request the specific data elements (e.g., Name, Grade, Course Enrollment) justified in Exhibit A - Part 1.

Accessibility

Annually, vendors must email the following to PGCPS at pgcps.digitaltoolrev@pgcps.org . Filename conventions must be followed. 

1. 1. National Instructional Materials Access Center (NIMAC):

      Proof that NIMAS-Formatted Files have been uploaded to the NIMAC: For digital instructional materials that include structured documents or publications that can be printed, proof that required files have been uploaded to the National Instructional Materials Access Center (NIMAC) for conversion to accessible formats, must be provided.

      • If the product contains structured documents or publications that can be printed, the vendor must provide the following information for each product in an accessible PDF document that uses the following filename convention: yyyy-VendorName-Product-NIMACID.
        • The document must contain the NIMAC identifier number.
        • A PDF/UA report must be provided, demonstrating that the NIMACID PDF is an accessible PDF.
      • If the product DOES NOT contain structured documents or publications that can be printed, the vendor must provide PGCPS with an Exemption Statement on Company Letterhead in the form of an accessible PDF document, using the following filename convention: yyyy-VendorName-Product-NIMASExempt. The statement should read as follows: [Name of Company] is exempt from the NIMAS/NIMAC requirement because there are no structured documents or publications that can be printed within [Name of Product].
        
        • More than one product can be listed within the same Exemption Statement as long as each product name is provided as shown above.
        • A PDF/UA report, demonstrating that the PDF Exemption Statement is an accessible PDF must also be provided.

2.  Accessibility Conformance Report (ACR):

Provide an Accessibility Conformance Report (ACR), which is a completed Voluntary Product Accessibility Template (VPAT). A current, complete, and accurate ACR must meet the following requirements: 

• • • • Developed using the latest International (INT) VPAT® from the Information Technology Industry Council (ITI).
      • Provided in the form of a document. If the ACR is in an HTML format, please provide a link to the ACR in a document.
      • Uses the following filename convention for the ACR document: yyyy-VendorName-Product-ACR. 
      • Updated annually.
        • If there is a major release (e.g., version 1.1 to version 2.0) within the contract period, the ACR must be updated again within sixty (60) days of the release.
      • Reflects the version of the product being purchased as part of the contract.
      • Explains how the product was tested for accessibility, including testing with assistive technologies.
      • Represents all types of pages, sections, media, features, and functionality, including the digital accessibility of 3rd-party tools embedded in or used with the product.
      • If the ACR is being updated from a previously submitted version, it should demonstrate the elimination of digital accessibility barriers from the previous ACR.

3.  Letter of Commitment (LOC):

Letter of Commitment (LOC) to Accessibility Compliance contains accessibility requirements from local, state, and federal statutes and regulations. Vendors must sign the LOC and they are not allowed to redline, delete, or modify it in any way.
The LOC includes:

• • • • An acknowledgment that digital accessibility testing may require the inspection of code and that the vendor will not initiate any repercussions or loss of licenses for code inspection conducted during the course of an accessibility evaluation by PGCPS employees or contractors.
      • A guarantee that if the product interferes with code inspection or prohibits the use of automated accessibility testing tools, the vendor will timely and accurately provide PGCPS with the information needed to disable or circumvent features that prohibit the organization from completing their required duty to conduct accessibility evaluations of digital tools they purchase.

4.  Digital Accessibility Agreement (DAA):
     The DAA is a contract addendum for digital tool contracts that outlines the digital accessibility expectations of the organization, including an indemnification clause. Vendors who            enter into contracts must acknowledge and sign the DAA without edits, deletions, or redlines. 

5. Annual Digital Accessibility Roadmap (DAR):
    Provide a Digital Accessibility Roadmap (DAR) that outlines the accessibility improvements that will be made. It must be updated every 12 months and meet the following                requirements:

• • • Filename convention: yyyy-VendorName-Product-DAR
    • The date the DAR was created.
    • A description of the accessibility issue(s) being addressed, including: 
      • The associated WCAG success criteria 
      • Location(s) within the product where the issue(s) exists 
      • Current resolution status. Please choose one of the following: 
        • Remediation of the issue is already in progress. 
        • Research is being conducted to find a solution. 
        • Other (please explain) 
      • Remediation timeline that:
        • Defines quantifiable milestones for remediating the targeted digital accessibility issue within the product.
        • Provides the anticipated date(s) when each milestone will be achieved.

6. One-Page, Digital Accessibility Summary (DAS): 

Annually provide a one-page Digital Accessibility Summary (DAS) of the product’s level of compliance with digital accessibility requirements. This summary will be made available to employees and members of the community upon request.  The DAS must meet the following requirements:

• • • Filename convention: yyyy-VendorName-Product-DAS
    • The summary must include:
      • The name of the company.
      • The name of the product.
      • Contact information for a person who is knowledgeable about the accessibility of the product.
      • A brief description of the product.
      • Information about the product’s level of conformance to digital accessibility requirements outlined in Section 508 of the Rehabilitation Act of 1973, as revised and the Web Content digital accessibility Guidelines (WCAG), version 2.1, levels A and AA.
    • The summary must be provided in one of the following formats:
      • An accessible PDF document that meets the requirements of the latest version of the Web Content Accessibility Guidelines (WCAG) and passes all PDF/UA checkpoints.
        • Along with the one-page summary, the vendor must provide a copy of the PDF/UA report showing that the PDF passes all PDF/UA checkpoints and meets the requirements of the latest version of WCAG.
          • The PDF/UA report must use this filename convention: yyyy-VendorName-Product-DAS-PDFUA
      • A link to an accessible HTML page.

7. Test Login Credentials: 

It is a nonnegotiable requirement that vendors provide functional test login credentials and other required details (e.g. URLs) for ongoing internal compliance testing. If login credentials are not provided and as a consequence, legislatively required accessibility testing is unable to be completed, the purchasing process will be stalled or stopped and may result in a different product being purchased as a replacement. Login credentials and details must meet the following requirements:

• • • Be provided in a document that allows employees or contractors to copy URLs, usernames, and passwords as text that can be pasted into required fields within the product. Do not provide login credentials and details as an image or a screenshot.
    • The document must use the following filename convention: yyyy-VendorName-Product-LoginCredentials
    • The login credentials must provide access to all product functionality available to a licensed user across all user journeys. These credentials will be utilized by employees and/or contractors to test the accessibility of interfaces and content for students, parents, system admins, or other community members.
    • It is the responsibility of the vendor to preset access and content for all types of users and to not require PGCPS to log into an admin account to set up access and content for other users.
    • If access to features for each user journey can only be obtained through the use of a single-use login, a bank of 10 single-use logins must annually be provided for each type of user journey. 
    • Credentials must remain active for the duration of the evaluation period. If PGCPS purchases the product, login credentials must remain active for the duration of the contract.
    • If a vendor’s systems have time limits for test credentials, it is the vendor’s responsibility to update and refresh the credentials without any reminders from [Name of Organization].