Security & compliance.
Releasing a child is the most consequential transaction a school makes each day. This page describes our current compliance status, the controls in place today, and how to reach us about a security concern.
SOC 2: committed for launch.
We have not yet engaged a CPA firm. SOC 2 Type I is a launch requirement; we will retain an auditor as we approach general availability, obtain Type I immediately, and pursue Type II as soon as the observation window completes. The controls below describe the security posture in production today. They are the foundation an auditor will examine when observation begins.
- Framework
- SOC 2 (AICPA TSC: Security, Availability, Confidentiality)
- Auditor
- Not yet engaged
- Observation start
- Planned at general availability
- Type I report
- Planned at general availability
- Type II report
- Planned after Type I observation completes
What an auditor will examine.
These controls exist in production today. Where a control is partial, planned, or inherited from our infrastructure provider, we say so.
Identity & access
- Federated sign-in via Google or Microsoft for staff; password-based sign-in is also supported.
- Districts can enforce their own multi-factor authentication policies through per-domain SAML single sign-on.
- Role-based access is scoped per school within a district and revokes immediately when an account is deactivated.
- Per-tenant isolation is enforced at the database layer; permissions ride on the user's authenticated session.
Encryption & key management
- All data in transit is encrypted with TLS 1.2+ to an HTTPS endpoint.
- All data is encrypted at rest on Google Cloud Platform.
- Sensitive personal data — student, guardian, and district records — is additionally encrypted at the field level, with keys stored and managed in Google Cloud’s Key Management Service (KMS).
Data protection
- No image of any kind is captured at the curb. Pickup begins when a guardian scans a printed sign from their own phone, so there is no photograph, no video, and no vehicle record to retain.
- Pickup events are retained for the district’s contract term — configurable per district to meet state record-retention requirements (up to seven years) — then deleted.
- Tenant data is segregated by district / school identifier on every query.
- Customer roster data is never sold, shared with third parties, or used to train models.
Auditability
- Every pickup release is recorded with the acting staff member, vehicle, and timestamp.
- Authentication events (sign-in, session start) are recorded in the audit log.
- Roster, permission, and configuration changes are captured in the audit log.
- Audit log retention defaults to 365 days, configurable per district, and is exportable for review.
Infrastructure & network security
- Hosted on Google Cloud Platform in US regions, so customer data stays resident in the United States.
- We inherit Google's data-center physical security — biometric access, 24/7 monitoring, and redundant power and networking. Dismissal staff have no physical access to servers.
- Google Cloud Platform maintains its own SOC 2 and ISO 27001 certifications for the infrastructure we build on — separate from Dismissal's own SOC 2, tracked above.
- Only designated operators can change production infrastructure, over multi-factor-authenticated Google Cloud access, on a least-privilege, as-needed basis.
- Vehicle recognition runs on-device, with no cloud round-trip in the recognition path.
Resilience & secure delivery
- Data lives on Google Cloud's managed storage with automatic multi-zone replication, so it survives hardware and single-zone failures.
- Every change is version-controlled, goes through code review and continuous integration, and deploys are versioned and reversible.
- Dependencies are updated automatically and scanned for known vulnerabilities.
- An automated test and accessibility regression suite gates every code change at merge time.
WCAG 2.2 AA today; ACR document in progress.
The portal conforms to WCAG 2.2 Level AA across every public and authenticated route. Per-deficiency colorblind presets (red-green and blue-yellow), a session-timeout warning, full keyboard navigation, screen-reader landmarks, and reduced-motion support ship today. The full control list and known limitations are on the accessibility statement; the formal ACR / VPAT 2.5 document is in progress.
- Standard
- WCAG 2.2 Level AA (with AAA on the colorblind axis)
- Conformance evidence
- Automated accessibility regression suite gates every code change; per-deficiency colorblind presets, reduced-motion support, semantic landmarks, focus management, ARIA live regions
- ACR / VPAT 2.5
- In progress. Request via accessibility@
- Accessibility contact
- accessibility@dismissal.ai
How we support FERPA & COPPA.
FERPA and COPPA bind the school district, not the vendor. Our role is to provide districts the contractual terms, data handling, and parental-consent framework they need to comply.
Education record handling
We process student data only as a school official under FERPA's exception, on the district's behalf, for the legitimate educational interest of student dismissal.
Parental consent (COPPA)
Districts collect and document parental consent for under-13 students. We support consent records and revocation through the guardian roster.
Retention & deletion
Nothing at the curb captures an image, so there is none to retain. Pickup events are retained for the term of the district’s contract — configurable per district to meet state record-retention requirements, up to seven years — then deleted. Audit log retention defaults to 365 days and is configurable per district.
Data Processing Addendum
We sign DPAs with district customers. Sample DPA available on request.
Reporting a security issue.
Security mail is answered by a person, not a form. If you've found a vulnerability or suspect misuse of the service, write directly. We acknowledge within one business day.