Security & Privacy FAQ

Security and privacy are core commitments at Playground IEP.

This FAQ distills the answers district technology teams ask most often — hosting, encryption, compliance, incident response, and more — so you can gauge our security posture at a glance. For every snapshot fact you see here, the full Security & Privacy FAQ below offers deeper narrative answers, and our Privacy Policy and Terms of Service remain the definitive source of truth. We refresh this document whenever practices or regulations change, and we welcome follow-up questions at any time at privacy@playgroundiep.com.

Quick access to primary documents

• Privacy Policy
• Terms of Service
• Standard NDPA Template — available on request at privacy@playgroundiep.com

Living Document Notice. Playground IEP's Security & Privacy FAQ is a supplement to our official Privacy Policy and Terms of Service. We update it regularly as our platform, practices, or regulations evolve, but those updates may lag behind real-time changes. If any statement here conflicts with the Privacy Policy or Terms of Service, the policy documents always prevail and are the definitive source of truth. We make every reasonable effort to refresh this FAQ promptly so it remains a helpful at-a-glance guide for district technology teams.

1. What is Playground IEP?

Playground IEP is a web-based special education caseload management platform. It helps schools manage special education processes more efficiently by supporting IEP scheduling, IEP drafting (with optional AI assistance), progress monitoring, and personalized caseload dashboards for authorized teachers and staff. No data provided by Playground IEP or its users is used to train AI models or retained long-term by our AI providers.

The personally identifiable information (PII) required to provide this service typically includes:

• Student name
• Student ID number
• Grade level
• School enrollment
• Parent name and email (where entered)
• Teacher and staff names and email addresses
• Student disability and IEP information
• Specialized education services (IEP, 504)
• Case manager name and email address
• Related service provider names and email addresses

Playground IEP is not a replacement for existing student information systems or district IEP systems of record. It is a complementary caseload-management tool designed to streamline day-to-day special education work and eliminate fragile spreadsheets.

At Playground IEP, safeguarding the privacy and security of the data we process is not just a priority but a core commitment.

2. Who is responsible for security and privacy oversight?

Security and privacy sit at the highest level of the organization: the CEO is the designated owner of all information-security and privacy programs, including policy creation, risk assessments, incident response, and annual reviews.

3. How is governance structured and how often are policies reviewed?

Playground IEP maintains a suite of written policies (Data Protection, Access Control, Incident Response, Network Security, Employee Security Training, etc.). Each policy is reviewed at least once every 12 months — or sooner if legal or operational changes require it — by the policy owner (the CEO) and communicated to all personnel.

4. What is your overarching security mission?

At Playground IEP, safeguarding the privacy and security of the data we process is a core commitment. This principle drives every architectural and operational decision we make — from the database isolation model through the sub-processors we allow into our stack.

1. Which security certifications or attestations does Playground IEP hold today?

Every layer of our hosting stack inherits SOC 2 Type II (and, in most cases, ISO 27001) controls from our underlying providers — Vercel (application hosting), Supabase (managed PostgreSQL and authentication), AWS (underlying infrastructure), and Google Workspace (internal collaboration).

2. Which privacy laws and education-sector regulations do you comply with today?

Law / Framework	Our stance
FERPA	Full compliance; student records used only for "legitimate educational interests."
COPPA	Platform is staff-only; we do not knowingly collect data directly from children under 13.
NY Ed Law 2-d	Operational safeguards align with 2-d encryption and breach-notice rules.
1EdTech Trusted Apps	Endorsed; demonstrates K-12 best-practice alignment.

3. Do you sign Data Processing or Privacy Agreements with districts?

Yes. We sign Data Privacy Agreements with all district clients.

4. How do you ensure sub-processor compliance?

We require every sub-processor to maintain equivalent or stronger attestations (SOC 2 Type II and/or ISO 27001) and review those attestations annually. Current sub-processors are listed in Sub-processors & DPAs.

5. Do you process or store credit-card data?

No. Playground IEP does not currently process credit-card payments through the platform. Should consumer-level payments be introduced in the future, they would be handled entirely by a PCI-DSS-compliant payment provider; Playground IEP systems would not see or store card numbers.

6. How does Playground IEP approach AI-specific compliance?

Our generative-AI features call the Anthropic Claude API (narrative drafting) and, for illustrations, the Google Gemini API. Both providers' published commercial API terms commit that customer inputs and outputs are not used to train their models and that API payloads are retained only for short, bounded abuse-monitoring windows (typically 30 days) before deletion. For voice transcription, we operate under an enterprise data processing agreement with AssemblyAI that defines strict requirements for data handling, security, and confidentiality. We map our AI implementation to the NIST AI Risk-Management Framework (AI RMF 1.0) and run bias, privacy, and security checks as part of release QA.

7. Will you cooperate with mandated disclosures such as FOIA?

Yes. When legally compelled, we comply with court orders or government requests while limiting disclosure to the narrowest scope required.

1. Where is Playground IEP physically hosted?

The production application runs on Vercel (a managed Next.js hosting platform) and our PostgreSQL database and authentication run on Supabase — both configured to U.S. regions and underpinned by AWS U.S. infrastructure. All customer data therefore remains on U.S.-based facilities.

2. Which cloud services and sub-processors support the platform?

Playground IEP uses a deliberately small, vetted stack:

• Vercel — application hosting, edge delivery, and DDoS / WAF protections for the web app
• Supabase — managed PostgreSQL database, authentication, and encrypted file storage
• Amazon Web Services (AWS) — the underlying infrastructure for Vercel and Supabase
• Google Workspace — internal email and document collaboration (no student data)
• Anthropic (Claude) API — AI narrative suggestions inside the IEP editor
• Google Gemini API — illustrations for social stories (narrow, opt-in feature)
• AssemblyAI — secure voice-note transcription
• SendGrid — transactional email (OTP codes, notifications, staff invites)
• Upstash (Redis) — rate-limiting and abuse prevention; no PII
• Customer.io — product analytics and marketing email (enabled only in production; no student data)

Every sub-processor maintains SOC 2 Type II — and, in most cases, ISO 27001 — certifications, which we re-verify annually.

3. Is student data ever copied to test or staging environments?

No. Student data is kept out of non-production environments. Staging and development systems run on a separate Supabase project with no production data, and are locked to the same security baseline as production.

4. How is data encrypted in transit and at rest?

• In transit: All traffic between clients, edge, application servers, databases, and sub-processor APIs is forced over HTTPS/TLS 1.2 or later.
• At rest: Every record — including file uploads and automated backups — is protected with AES-256 encryption on AWS storage volumes managed by Vercel and Supabase.

5. What backup and disaster-recovery capabilities are in place?

Supabase provides continuous transaction-level point-in-time recovery and daily encrypted backups retained for 7 days. Backups inherit the same AES-256 at-rest and TLS in-transit protections as production and can be restored by Playground IEP operations staff to recover from a disaster or accidental deletion.

6. How is the network and infrastructure secured?

• Physical & environmental controls: AWS data centers enforce multi-layer guards, biometrics, fire suppression, redundant power, and strict visitor bans.
• Logical controls: Vercel and Supabase isolate customers at the application layer, encrypt all inter-service traffic, and continuously patch underlying hosts.
• Edge protection: The web application is fronted by Vercel's managed edge network, which provides global HTTPS termination, DDoS mitigation, and web-application-firewall protections against common attack classes (OWASP Top 10).
• Hardening headers: Standard hardening HTTP headers are applied to every response, including HSTS (production), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, strict Referrer-Policy, and a Permissions-Policy that disables camera, microphone, geolocation, and cross-site browsing-topics by default.

7. How long are logs retained and how are they monitored?

Vercel and Supabase provide built-in request, authentication, and database telemetry. Administrator impersonation actions — the highest-privilege activity inside the platform — are written to a dedicated audit table retained alongside the production database.

1. What specific information does Playground IEP collect?

We gather only the data required to make the platform useful for educators:

• Student name
• Student ID number
• Grade level
• School enrollment
• Parent name and email (where entered)
• Teacher and staff names and email addresses
• Student disability and IEP information
• Specialized education services (IEP, 504)
• Case manager name and email address
• Related service provider names and email addresses
• IEP narrative content authored or imported by the user (present levels, goals, accommodations, progress notes)
• Voice recordings (where a staff member chooses to use the voice-notes feature) — transcribed and retained as text alongside the student's record

2. Do you take data directly from students or children under 13?

No. The platform is accessible only to school staff; students never log in. Because we do not operate consumer-facing student accounts, we remain fully COPPA-compliant.

3. What is your retention schedule and deletion workflow?

• Student data – kept only while the student is enrolled or the district subscription remains active.
• Teacher / staff data – retained for the life of the subscription.
• Parent data – retained only as long as needed for educational purposes.

When a retention period ends — or upon a verified district request — records are securely and irreversibly deleted following industry methods (e.g., cryptographic wipe / NIST 800-88 for any media). Users may also request deletion at any time, subject to legal holds.

4. Is data ever re-used, sold, or shared for advertising?

Absolutely not. We do not sell or re-disclose student or user data, and we forbid any advertising or behavioral targeting on the basis of that data. De-identified, aggregated metrics may be used to improve product performance, but they contain no personally identifiable information.

1. What encryption protocols protect data in transit?

All traffic between end-users, the Vercel edge network, the application, and our data services is forced over HTTPS/TLS 1.2 or later. Older protocols and cipher suites are disabled, and the production site is pinned to browsers via HSTS with a long max-age to prevent downgrade attacks.

2. How is data secured at rest?

Every record — primary database tables, file uploads, and automated backups — is encrypted with AES-256 on AWS storage volumes managed by Supabase.

3. How are encryption keys generated, stored, and rotated?

Supabase and AWS Key Management Service (KMS) handle key creation and storage inside certified hardware-security modules. Internal policies require that private keys remain confidential, follow a documented lifecycle (creation → rotation → retirement), and are selected randomly across the entire key space.

4. Are backups also encrypted?

Yes. Automated database backups and point-in-time recovery snapshots inherit the same AES-256 at-rest and TLS in-transit protection as live data. Access to backups is limited to authorized ops personnel, and expired backups are wiped using industry sanitization practices.

5. How are user passwords and credentials stored?

Playground IEP does not store user passwords at all. Sign-in is handled via:

1. A one-time numeric code emailed to the user, or
2. Google Single Sign-On or Microsoft Single Sign-On.

Because the platform never receives a password, the most common credential-theft attack paths do not apply. Any authentication secrets held by Supabase Auth (for example, MFA factors) are stored as hashed, salted values — never in plaintext.

6. Do you support additional secure-transfer channels?

For districts that need to exchange bulk data outside of the application, we support encrypted SFTP / HTTPS transfers under a written agreement. All file transfers travel over encrypted channels end-to-end.

1. How are user accounts provisioned and scoped?

Playground IEP issues role-based accounts so that each staff member, contractor, or support engineer can see only the data required for their duties. Roles are created and granted according to the principle of least privilege. Within a district, common roles include District Admin, School Admin, and Teacher — each with progressively narrower access.

2. Does every user have a unique login?

Yes. Unique user IDs (keyed to the user's email address) are required for all system access; no shared credentials are permitted.

3. How is multi-tenant data isolated?

District and school boundaries are enforced at two independent layers:

1. PostgreSQL Row-Level Security (RLS) — every student-data table carries explicit RLS policies that restrict read and write access to users inside the same district (and, where appropriate, the same school). These policies execute inside the database, so a failure or bug in the application layer still cannot leak rows across districts.
2. Application-layer authorization — on top of RLS, every request re-verifies the user's effective context (district, school, role) before returning data. This defense-in-depth model ensures that even if either layer were compromised, the other continues to enforce isolation.

4. Is multi-factor authentication available?

Yes. MFA is required for all platform administrators (Playground IEP employees with elevated access), enforced via Supabase Auth. MFA is available to district users and can be required by district policy.

5. How is contractor access handled?

External developers do not receive routine access to production data. In rare cases — such as diagnosing a critical bug — temporary, supervised access may be granted under a signed confidentiality agreement and is revoked immediately after the issue is resolved.

6. How are service-role credentials handled inside the codebase?

Database service-role credentials — which can bypass RLS — are treated as highly sensitive. Their use is gated by:

• Automated linting that blocks service-role use in ordinary dashboard code paths;
• A documented allow-list (administrative tooling, impersonation, and specific storage helpers); and
• Explicit, auditable exceptions with written justification for any additional use.

The vast majority of application code reaches the database through the authenticated client, where RLS is the authoritative access boundary.

7. How is administrator impersonation handled?

In rare cases — for instance, helping a district resolve a data issue — a platform administrator may impersonate a district context to reproduce a user-facing problem. When this happens:

• The administrator's identity is verified first;
• A short-lived, secure, HTTP-only impersonation cookie is issued;
• The effective district context is explicitly scoped server-side on every request; and
• Every mutation taken under impersonation is written to a dedicated impersonation_log table that records who acted, on behalf of which district, and what was changed.

8. Are user and administrator actions logged?

Yes. Authentication events are captured by Supabase Auth; request-level telemetry is captured by Vercel; and administrator impersonation actions are captured in the dedicated audit log described above. A broader, user-level audit log for in-app actions is on our near-term roadmap.

9. How are user sessions and cookies handled?

Playground IEP uses Supabase Auth for session management. When a user signs in, a short-lived access token is issued and delivered to the browser via a secure, HTTP-only cookie (marked SameSite=Lax, restricted to our domain, and — in production — Secure-only over HTTPS). Access tokens expire and are silently refreshed in the background as the user remains active; when a user is idle long enough for their refresh token to expire, they are required to re-authenticate. Signing out immediately invalidates the session. The platform does not use advertising cookies, cross-site tracking pixels, or third-party session trackers.

1. What activity logs do you keep, where are they stored, and how long are they retained?

Playground IEP relies on the telemetry provided by Vercel (request / function logs) and Supabase (authentication and database logs), supplemented by our own impersonation audit trail. Supabase logs are retained for 7 days for forensic triage; Vercel's standard request logs are available for real-time review and investigation. Administrator impersonation records are retained in the production database alongside the data they describe.

2. How do you detect security vulnerabilities and missing patches?

• Infrastructure & platform scans: Vercel, Supabase, and AWS run continuous automated scanning and security audits; they apply patches through structured processes as soon as vendor fixes are released.
• Application dependencies: We track security advisories for the open-source libraries we depend on (Next.js, React, Supabase SDKs, UI libraries, etc.) and apply fixes on a prioritized schedule.
• Rate limiting & abuse controls: Sensitive endpoints (sign-in OTPs, AI generation routes, high-volume list queries) are rate-limited per user / per email to blunt enumeration, brute-force, and denial-of-wallet attacks.

3. What is your patch-management timeline?

Our policy — mirroring NYC DOE requirements — is to apply all relevant security patches to cloud infrastructure and application dependencies within 30 days of vendor release, with critical vulnerabilities expedited.

4. Do you carry out vulnerability assessments or penetration testing?

We perform periodic internal vulnerability assessments and application-level security testing as part of our release process. Engagement of an external penetration-testing firm is planned and tracked on our security roadmap.

1. Does Playground IEP maintain a formal Incident Response Plan?

Yes. A written Incident Response Policy governs every security event that could affect the confidentiality, integrity, or availability of our systems and data. The policy:

• Owner: CEO is the primary lead and designated security officer for all incidents.
• Scope: Application-level events are handled by Playground IEP; infrastructure-level events are handled by our providers (Vercel, Supabase, AWS) and reported to us.
• Lifecycle: Identify → Assess → Contain → Eradicate → Recover → Post-Incident Review.
• Training: Staff are taught how to detect and escalate incidents through established channels.

2. Who is notified inside Playground IEP when an incident occurs?

All personnel must report potential incidents immediately to the CEO, the designated security officer. The CEO coordinates any additional internal or third-party resources needed for containment and investigation.

3. How quickly will you notify a school or district of a confirmed breach?

• Standard contract (NDPA): Within 72 hours of confirming an unauthorized release, disclosure, or acquisition of student data.
• NYC Public Schools contracts: Within 24 hours for any unauthorized release of confidential information, and within 72 hours for any other contractual breach.

4. What details are included in a breach notification?

Notifications contain — at a minimum — (1) description of the incident, (2) categories of data affected, (3) date or date-range of the breach, (4) corrective actions taken, and (5) contact information for follow-up.

5. What containment and investigation steps are taken?

Upon detection, access is revoked and affected systems isolated to prevent further exposure. A thorough investigation establishes root cause and scope, drawing on Vercel and Supabase logs and internal telemetry. Remediation actions (patches, key rotation, permission reviews) are completed before normal operations resume.

1. Do you have a documented Business Continuity and Disaster Recovery (BCP/DR) Plan?

Yes. Playground IEP maintains a formally approved BCP/DR Plan signed by the CEO that guides how we keep services running during any disruption.

2. What does the plan cover?

The plan addresses all critical business functions — chiefly the Playground IEP application and customer-support operations — and explicitly accounts for risks tied to third-party providers such as Vercel, Supabase, AWS, Anthropic, and Google.

3. How often is the plan tested and reviewed?

The BCP/DR Plan is tested at least annually and reviewed after any material change to ensure it reflects the latest risk assessment.

4. How is data backed up?

Supabase provides continuous, transaction-level point-in-time recovery and daily encrypted backups. Backups are retained for 7 days on a rolling basis; transaction logs supporting point-in-time recovery are retained for 7 days. We may take additional snapshots before major platform updates. All backups are encrypted with AES-256 and stored on AWS U.S. infrastructure.

5. How long are backups retained and how are they disposed of?

Backups are retained for 7 days on a rolling basis. When backups expire, they are securely wiped by our managed database provider using industry-standard sanitization methods.

6. What is the recovery process if a disaster occurs?

Operations staff can restore the entire database — or selected data types — using Supabase's point-in-time recovery interface, typically to within seconds of an incident.

7. Who coordinates recovery and communication?

The CEO leads all recovery efforts and external communications, following the communication protocols defined in the BCP/DR.

8. Do you have service-availability targets?

Our architecture — built on Vercel and Supabase — is engineered to meet 99.9% uptime, aligning with common district and NYC Public Schools requirements.

9. Is there insurance coverage for business interruptions?

Yes. Playground IEP carries general liability, professional liability, and cyber-liability insurance policies that include business-interruption coverage.

1. Who owns the information stored in Playground IEP?

All Student Data transmitted to Playground IEP "is and will continue to be the property of and under the control of the LEA." The company acts as a School Official under FERPA, operating only under the district's direction.

2. How long is data retained?

Data category	Retention period
Student records (IEPs, progress notes)	For the student's enrollment at the school and/or the life of the district's active subscription
Teacher & staff accounts	For as long as the district keeps an active subscription
Parent / guardian contact info	Only as long as needed to fulfill educational purposes or service requirements

Retention periods are aligned with FERPA, COPPA, and — where applicable — New York Ed Law 2-d.

3. What happens when the retention period ends or a contract terminates?

When data is no longer required — or upon contract expiration — Playground IEP securely and permanently deletes the information in accordance with industry-standard practices.

4. Can a district request earlier deletion or a copy of its data?

Yes. Under the statewide NDPA, a district may send a Directive for Disposition of Data; Playground IEP must dispose of — or enable secure transfer of — Student Data within 60 days of the written request.

5. How is data destroyed?

Digital information is wiped using methods that meet or exceed NIST 800-88 sanitization guidelines, and physical media (if ever used) is shredded, burned, or otherwise rendered unrecoverable.

6. Do you ever sell, re-use, or disclose data for advertising or analytics?

No. Playground IEP does not sell Student Data, use it for marketing, or allow third-party advertising. Only de-identified, aggregated metrics may be used internally to improve the product, and any transfer of de-identified data requires the district's prior written consent.

7. What rights do parents or eligible students have to inspect or delete records?

Districts remain the primary contact for parental FERPA requests. Upon a verified district request, Playground IEP will supply or delete the relevant records within 45 days (or the shorter timeline mandated by state law).

1. Which third-party service providers ("sub-processors") does Playground IEP use, and what do they do?

We keep the list intentionally short and transparent:

Provider	Function	Certifications / Safeguards
Vercel	Application hosting, edge delivery, DDoS / WAF	SOC 2 Type II; ISO 27001
Supabase	Managed PostgreSQL database, authentication, file storage	SOC 2 Type II; encrypted at rest on AWS
Amazon Web Services (AWS)	U.S. infrastructure that underlies Vercel and Supabase	SOC 2 Type II; ISO 27001
Google Workspace	Internal corporate email and document storage (no student data)	SOC 2 Type II
Anthropic (Claude API)	Generates narrative suggestions inside the IEP editor	SOC 2 Type II; governed by Anthropic's published commercial API terms (no training on customer data; API inputs/outputs retained for a short abuse-monitoring window, typically 30 days, then deleted)
Google Gemini API	Optional illustrations for social-story features	SOC 2 Type II; governed by Google's paid-tier Gemini API terms (paid-tier prompts and responses are not used to train or improve Google's models)
AssemblyAI	Transcribes staff voice notes into text	SOC 2 Type II; signed enterprise data processing agreement — customer audio is not used to train models
SendGrid	Transactional email delivery (sign-in codes, notifications, staff invites)	SOC 2 Type II; ISO 27001
Upstash	Redis-based rate limiting and abuse prevention; does not store student PII	SOC 2 Type II
Customer.io	Product analytics and marketing email for paying and prospective staff users; enabled only in production. Receives staff-level contact attributes (name, email, role, district, school). Never receives student records or IEP content.	SOC 2 Type II

All customer data remains inside U.S.-based facilities operated by these providers.

2. Do districts sign a Data-Processing Agreement with Playground IEP?

Yes. We sign a DPA for all district clients.

3. Are separate DPAs in place with your sub-processors?

Our contractual posture varies by provider but is transparent in every case:

• AssemblyAI — signed enterprise data processing agreement that defines strict requirements for data handling, security, and confidentiality.
• Anthropic (Claude API) — we rely on Anthropic's published commercial API terms, which prohibit training on customer data and retain API payloads only for a short abuse-monitoring window (typically 30 days) before deletion.
• Google (Gemini API) — we use Google's paid-tier API, under which Google's published terms commit that customer prompts and responses are not used to train or improve Google's models or services.
• Vercel, Supabase, AWS, Google Workspace, SendGrid, Upstash, Customer.io — governed by each provider's commercial terms, which include strong data-protection clauses; we review their SOC reports annually to confirm ongoing compliance.

4. How are new sub-processors vetted and communicated to districts?

• Vetting: Security, privacy, and legal teams evaluate certifications, breach history, and contract language before onboarding any vendor.
• Notice: Under our NDPA commitments, we will provide written notice to the district (typically 30 days in advance) before enabling a new sub-processor that will touch Student Data.

5. Do external contractors ever access production data?

Only in rare, critical circumstances (e.g., diagnosing a production bug). Access is (a) time-boxed, (b) supervised, and (c) covered by a signed confidentiality agreement. Routine vendor operations do not expose raw Student Data.

6. Is Student Data ever sold or shared for marketing or advertising?

No. Our contracts prohibit any sale, commercial re-use, or advertising-related disclosure of Student or Teacher Data. Only fully de-identified, aggregated metrics may be used internally to improve the product.

7. Can users connect their own Google accounts for Drive or Calendar access?

Yes. Playground IEP offers two optional, user-initiated Google Workspace integrations, entirely separate from sign-in:

• Google Drive (per-file import). A user may grant Playground IEP permission to read files they explicitly select from their own Drive — typically to import a prior evaluation, report, or planning document into the IEP editor. We request only the drive.file scope, which grants per-file access: Playground IEP can only read the specific files the user picks through Google's file picker, and has no ability to list, browse, or access any other file in the user's Drive. We never write to, modify, or delete files outside of those the user explicitly chooses.
• Google Calendar (event creation). Users of the Meeting Scheduler feature may connect their Google Calendar so Playground IEP can create and manage IEP meeting events on their behalf — for example, inviting a parent and attaching a Google Meet link. We request only the calendar.events scope (manage events), not broad calendar-read access to all calendars.

Both integrations are strictly opt-in. Neither is required to use Playground IEP's core caseload-management functionality, and a user may disconnect either integration from within the product at any time, which immediately revokes Playground IEP's access.

8. How are the OAuth tokens from those integrations stored and protected?

When a user connects Google Drive or Calendar, Google issues a refresh token that allows Playground IEP to request short-lived access tokens on the user's behalf. Those tokens are:

• Stored encrypted at rest in our Supabase-managed PostgreSQL database, subject to the same AES-256 at-rest and TLS in-transit controls as all other customer data;
• Scoped to the individual user — one user's token cannot be used to access another user's Drive or Calendar, and isolation is enforced at the database layer via Row-Level Security;
• Used only for the specific workflows the user initiated (importing a selected file; creating the meeting they scheduled);
• Covered by the minimum scopes required (per-file access for Drive; event-management for Calendar); and
• Revocable at any time, either by disconnecting the integration in-product or by revoking Playground IEP's access from the user's Google account security settings.

Playground IEP does not use these tokens to scan, index, or bulk-download a user's Drive or Calendar. The user's Google credentials themselves never touch our servers — the OAuth handshake is handled directly between the user's browser and Google.

9. How can district IT administrators authorize Playground IEP for their staff?

Most school-district tenants allow staff to sign in to Playground IEP without IT involvement. In stricter tenants — where end users are not permitted to consent to third-party applications — an IT administrator can grant tenant-wide consent once, after which staff in the district sign in seamlessly.

Microsoft 365 / Microsoft Entra ID tenants. Staff in tenants that block end-user consent will see "Need admin approval" when attempting to sign in. An IT administrator can pre-authorize Playground IEP for the entire tenant by opening the following URL while signed in with administrator credentials:

https://login.microsoftonline.com/common/adminconsent?client_id=57a2e311-6273-4fc2-a6b0-2b7809cdba84

Microsoft's consent screen will show the permissions being requested — all of which are non-sensitive sign-in scopes: an opaque user identifier (openid), the user's basic profile (profile), and the user's email address (email). Playground IEP requests no access to mailboxes, files, calendars, Teams, or other Microsoft 365 resources via sign-in. The grant is revocable at any time from the Enterprise applications blade of the Microsoft Entra admin center.

Google Workspace tenants. Most Workspace tenants permit users to self-consent to applications requesting only non-sensitive scopes — which is the case for Playground IEP's sign-in flow (openid, profile, email). In stricter tenants that require explicit allowlisting, an IT administrator can authorize Playground IEP via Google Admin Console → Security → API controls → Manage third-party app access, configuring trusted access for Playground IEP's OAuth client. As with Microsoft, this authorization is scoped to sign-in only — separate user-initiated OAuth flows govern any Google Drive or Calendar integrations a staff member chooses to connect.

1. Which artificial-intelligence technologies does Playground IEP use?

Playground IEP integrates external AI providers to assist educators with three narrow tasks:

1. Narrative drafting and review (e.g., present levels, goals, rewrites) — powered by Anthropic's Claude API.
2. Social-story illustrations — powered by Google's Gemini API when an educator opts into that feature.
3. Voice-note transcription — powered by AssemblyAI when a staff member chooses to dictate a note.

2. Are the models proprietary or hosted in-house?

No. We do not host or fine-tune any private LLMs; all AI capability is provided by the external providers listed above.

3. What contractual and technical controls govern these integrations?

• Contractual safeguards.
  • AssemblyAI — we operate under a signed enterprise data processing agreement that defines strict requirements for data handling, security, and confidentiality, and expressly forbids the use of customer audio to train AssemblyAI's models.
  • Anthropic (Claude API) — governed by Anthropic's published commercial API terms. Anthropic does not use API inputs or outputs to train its models, and retains API payloads only for a short abuse-monitoring window (typically 30 days) before deletion.
  • Google (Gemini API) — used via Google's paid tier, whose published terms commit that customer prompts and responses are not used to train or improve Google's models or services.
• No model training of any kind. None of these providers train models on Playground IEP data, and Playground IEP itself does no internal model training on customer data.
• Retention caps. API payloads are automatically purged by the providers after their published retention windows complete.
• TLS-encrypted transport. All prompt and response traffic travels over HTTPS/TLS.

4. Does Playground IEP train any AI models on district or student data?

No. Our contracts — and, where applicable, the NYC DOE NDA — prohibit using Confidential Information to create, improve, or train AI systems, and we perform no internal model-training of any kind.

5. Which risk-management framework guides your AI implementation?

Our governance aligns with NIST AI RMF 1.0, covering governance, risk assessment, bias testing, human oversight, privacy safeguards, and performance audits.

6. How is sensitive data protected when routed to an AI provider?

• Data minimization. Only the minimum context needed for a prompt is transmitted.
• Role-based gating. Prompts are generated by authenticated staff; students never input data directly.
• Encryption in transit and at rest. TLS for transport, and AES-256 on our side before any hand-off.
• Output sanitization. Model-generated content returned to educators is sanitized to prevent rendering of untrusted HTML or scripts.

7. Do you keep user prompts and AI outputs?

Prompts and generated text are stored in the same encrypted database as the rest of the IEP document so educators can edit and delete them later. Users may delete any prompt or output at any time.

8. Are educators warned about possible AI inaccuracies?

Yes. Our Terms of Service and in-product copy remind users that AI outputs "may not always be accurate, unique, or reliable," and staff must review and verify all generated text before adoption.

9. Is AI usage automatic, or does a user choose when to use it?

AI assistance is always user-initiated — it never runs on its own. An educator must take a deliberate action (for example, clicking to draft or rewrite a narrative section) for any AI feature to generate content, and the educator reviews and verifies the result before it is used. The platform's core caseload-management functions — caseload dashboards, IEP scheduling, and progress monitoring — operate without invoking AI at all.

1. Which laws protect student information and define parent rights?

Playground IEP complies with the Family Educational Rights and Privacy Act (FERPA), the Children's Online Privacy Protection Act (COPPA), New York Education Law 2-d, and the NYC DOE Parents' Bill of Rights for Data Privacy and Security.

2. Who owns the Student Data stored in Playground IEP?

All Student Data "is and will continue to be the property of and under the control of the LEA." Playground IEP acts only as a School Official under the district's direct control.

3. How can parents or eligible students inspect and review education records?

Parents (or eligible students) request access through their district; the district forwards the request to Playground IEP. We must provide the records no later than 45 days after the request — or the shorter state timeline, if one applies.

4. How can a record be amended if it is inaccurate or misleading?

Parents / eligible students have the right to request corrections. Districts relay those requests to Playground IEP, and we cooperate with the institution's amendment process as required by FERPA.

5. Can parents request deletion or transfer of their child's data?

Yes. Under the NDPA, a district may issue a Directive for Disposition of Data at any time; Playground IEP will securely delete — or, if severable, transfer — student-generated content within the agreed timeline.

6. Will parents be notified if their child's data is breached?

Absolutely. Contracts require notification to the district (and, where applicable, direct parent notice) within 72 hours (24 hours for NYC DOE) of confirming any unauthorized disclosure.

7. Is Student Data ever sold or used for advertising?

No. Student PII "cannot be sold or released for any marketing or other commercial purpose," and Playground IEP's contracts expressly prohibit such practices.

8. Do you support state-specific student-privacy addenda?

Yes. In addition to the statewide NDPAs many districts use, Playground IEP will execute state-specific student-data-privacy addenda on request — including, for example, those required by New York Education Law 2-d, California (SOPIPA / AB 1584), Illinois (SOPPA), Colorado (HB 16-1423), Connecticut (§10-234aa et seq.), and Texas (SB 820). Districts should send their preferred addendum to privacy@playgroundiep.com.

1. What insurance policies does Playground IEP carry?

Playground IEP maintains the three core lines that K-12 districts typically request: general liability, professional liability (errors & omissions), and a dedicated cyber-liability policy.

2. Does the program include business-interruption coverage?

Yes. The cyber-liability form includes business-interruption and extra-expense coverage that responds to service-outage or breach events.

3. What are the coverage limits?

Coverage limits meet or exceed common district bid thresholds; a current Certificate of Insurance (COI) with exact limits can be provided under NDA and will list the requesting district as an additional insured.

4. How are defense costs and breach-response expenses handled?

The cyber-liability policy is "duty to defend" and covers legal defense, forensic investigation, regulatory fines where insurable, credit-monitoring, and required notifications stemming from a data-breach incident.

5. Do contracts include indemnification and limitation-of-liability clauses?

Yes. Playground IEP's Terms of Service and district agreements include (a) mutual indemnity for third-party claims and (b) a commercially reasonable cap on indirect damages, aligning with standard EdTech contractual norms.

6. How can districts verify coverage each year?

A refreshed COI is issued annually at policy renewal and on request at any time; districts may also ask to be notified of any material change or cancellation with 30 days' advance written notice.

1. How often are security and privacy policies reviewed?

Every written policy — Data Protection, Access Control, Incident Response, etc. — is reviewed at least once every 12 months, or sooner if legal or operational changes require it. The CEO owns the review cycle and communicates updates to all personnel.

2. How does Playground IEP stay ahead of new threats and regulations?

• Risk-assessment program. Management conducts a formal risk assessment at least annually, with additional reviews whenever there is a significant operational change. Findings feed directly into updated controls and training.
• Regulatory watch. Leadership tracks FERPA, COPPA, NY Ed Law 2-d, and NYC DOE requirements, adjusting practices and documentation as new guidance appears.
• Client feedback loop. District technology directors can raise concerns at any time; those inputs are logged, triaged, and, where appropriate, incorporated into the next policy revision.

3. How are third-party providers re-evaluated over time?

Sub-processors must maintain SOC 2 Type II (and, where applicable, ISO 27001) certification. Playground IEP reviews and documents each provider's attestations annually and conducts additional checks if a provider makes material changes.

4. What post-incident learning and control validation occur?

After any security event or scheduled drill, the CEO leads a post-mortem to identify root cause, control gaps, and improvement actions. Lessons learned are folded into the next risk assessment and policy update cycle.

5. How often is this FAQ refreshed?

The FAQ is treated as living documentation. It is re-issued each quarter — or immediately after any material change — to ensure districts always have the latest, consistent answers. When updated, districts receive a change log along with a revised "Last Updated" date, mirroring the notification practices already embedded in our Terms of Service.

6. Does Playground IEP follow a culture of continuous improvement?

Yes. Continuous improvement is an explicit commitment in our data-privacy plans and subcontractor-management practices; we monitor evolving best practices and integrate stronger safeguards as they mature, while keeping districts informed of any change that could affect their data.