Security & Trust

1. Our Approach

The James Stanfield Company has served special-education classrooms since 1978. Our K–12 platform handles teacher accounts, school rosters, and limited student progress data, and we take the trust placed in us by educators and IT administrators seriously.

This page describes our current security posture in plain language. It is intended for school and district IT staff, administrators evaluating Stanfield, and anyone reviewing our practices on behalf of an institution. For binding legal terms, please refer to our Privacy Policy, Data Retention Policy, and Terms of Service.

2. Security Framework

Stanfield's security program is aligned to the Center for Internet Security Critical Security Controls, Version 8, Implementation Group 1 (CIS Controls v8 IG1) — the prescriptive baseline of essential cyber-hygiene safeguards recommended for all enterprises regardless of size or risk profile.

We chose CIS IG1 because it is concrete, free, and maps cleanly to other frameworks (ISO 27001, NIST CSF, SOC 2, the Student Data Privacy Consortium NDPA), so evidence collected here is reusable for any institutional review.

3. Data Classification

We classify the data we handle into the following categories, each governed by separate retention and access rules:

Educator account data — names, school-issued email addresses, role, school affiliation.
Student progress data — first names or non-identifying labels, activity completion, assessment scores, video watch history. We do not require or collect student last names, dates of birth, addresses, or government identifiers.
Billing data — billing contact, purchase order, invoice history. Card details are entered directly into Stripe and never touch Stanfield servers.
Operational data — server logs, audit trails, deliverability metrics, error reports.

4. Encryption

In transit: TLS 1.2 or higher on every connection. HSTS is enforced site-wide (max-age 1 year, includeSubDomains, preload-eligible).
At rest: Database, object storage, and backup volumes are encrypted at rest by our cloud provider using AES-256.
Application-layer: Sensitive credentials and third-party API tokens are encrypted at the application layer in addition to at-rest encryption.

5. Authentication & Access Control

MFA enforced on every administrative system (cloud console, source control, payment processor, email infrastructure, DNS).
Role-based access control at the application layer through four separate authentication guards (teacher, school, admin, parent). Student progress data is visible only to the student's teacher and the school administrators of that teacher's school.
Bot protection on signup endpoints (Cloudflare Turnstile).
Rate limiting on authentication and password-reset endpoints to mitigate brute-force and credential-stuffing attacks.
Inactive-account handling: Teacher accounts marked inactive are denied access at every request boundary by middleware, and their data is excluded from rosters and reports.

6. Network & Application Hardening

HTTP security headers in production: Strict-Transport-Security, Referrer-Policy, Permissions-Policy, X-Content-Type-Options.
Secrets and API keys are managed through environment-scoped configuration; production credentials are not shared with development environments.
Cross-site request forgery (CSRF) tokens on all state-changing requests.
Modern Laravel framework with security advisories monitored.

7. Monitoring, Logging & Audit Trails

Application errors, queue health, and email-delivery anomalies are continuously monitored; alerts are routed to the on-call engineer with cool-down to prevent alert fatigue.
Server access logs (including request metadata such as IP and user agent) are retained for 90 days for security investigation and debugging, then deleted.
Significant state changes initiated by staff (account creation, license issuance, content edits, refunds, role changes) are persisted in the application database and attributable to the actor.
A dedicated, query-friendly audit log of every authentication event and administrative action is on our roadmap (see Section 13).

8. Backups & Disaster Recovery

Automated daily backups of the production database, encrypted at rest and access-controlled.
When data is deleted from production it is purged from backups as older backups rotate out of the active retention window.
Recovery time objective (RTO): less than 8 hours for the production application.
Recovery point objective (RPO): less than 24 hours for the production database.
An isolated copy of the most recent backup, held in a separate cloud account, with documented integrity-verification cadence is a tracked item in our IG1 implementation roadmap (see Section 13).

9. Vulnerability Management

Application and operating-system dependencies are tracked and reviewed on a regular cadence; security patches are applied promptly.
We monitor public security advisories for the frameworks and libraries we depend on.
Third-party libraries are reviewed before adoption and replaced if they become unmaintained.

10. Incident Response

Designated handler: A primary and backup incident handler are designated within Stanfield.
Detection: Anomaly alerts (auth failures, unusual data export, error spikes, queue stalls) feed into our monitoring stack.
Notification: In the event of a confirmed security incident affecting customer data, we will notify affected institutional customers without undue delay and in accordance with applicable state breach-notification laws.
Post-incident: Every confirmed incident is followed by a written post-mortem and corrective actions.

To report a suspected security incident or vulnerability, email hello@stanfield.com. We acknowledge reports within 3 business days and treat all reports confidentially.

11. Vendor & Subprocessor Management

We maintain an inventory of every third-party service that processes Stanfield data, the purpose of each, and the categories of data it receives. New vendors are reviewed before onboarding for security posture, contractual data-protection terms, and necessity.

The current list of subprocessors is published in Section 6 of our Privacy Policy. We will provide notice on this page before engaging a new subprocessor that processes student data.

12. Student Data, FERPA & COPPA

Stanfield acts as a "school official" under FERPA when processing student data on behalf of educational institutions. Our platform is designed to minimize the student data we collect:

Student access is PIN-based and anonymous — no email, date of birth, or government identifier is required.
Student progress records are owned by the teacher and school; teachers and administrators may delete student records at any time.
Student data is never sold, never used for advertising, and never used to build marketing profiles.
We support institutional Data Privacy Agreements, including the Student Data Privacy Consortium (SDPC) National Data Privacy Agreement. Districts may request a signed DPA by contacting us.

For the full FERPA and COPPA narrative, see Sections 4 and 5 of our Privacy Policy.

13. Compliance Posture & Honest Limits

We believe in being transparent about what we have, what we are working toward, and what we do not yet have:

What we have: CIS Controls v8 IG1 alignment, FERPA/COPPA-aligned design, willingness to sign the SDPC NDPA, the technical controls described above.
What we are working toward: A formal written security policy set; annual workforce security-awareness training; formal third-party risk reviews on a defined cadence; a query-friendly audit log of every authentication event and administrative action; multi-factor authentication on staff and administrator logins to the Stanfield application itself; an isolated cross-account backup copy with documented integrity-verification cadence.
What we do not yet hold: SOC 2 Type II report, ISO 27001 certification. These are evaluated against customer demand and are on our roadmap.

14. Hosting & Data Residency

Stanfield's production infrastructure is hosted in the United States. Data does not leave the United States in the course of normal operations. International users should be aware their data will be transferred to and processed in the U.S.

15. Reporting a Vulnerability

If you believe you have discovered a security vulnerability in any Stanfield service, please report it confidentially to hello@stanfield.com. Please include:

A clear description of the vulnerability.
Steps to reproduce, including any URLs, parameters, or proof-of-concept code.
The potential impact as you understand it.
Your contact information for follow-up.

We commit to:

Acknowledge your report within 3 business days.
Provide a triage assessment within 10 business days.
Keep you informed of remediation progress.
Credit reporters who wish to be acknowledged, after a fix is in place.

We ask that researchers act in good faith — avoid privacy violations, service disruption, and data destruction; do not access or modify accounts belonging to others; and give us reasonable time to remediate before any public disclosure.

16. Contact

For security questions, DPA requests, or vendor due-diligence inquiries:

James Stanfield Company
hello@stanfield.com
805-897-1185