Security at Atlara

1. The program behind Atlara

Atlara is operated by CodeHS, Inc., whose security and privacy program includes SOC 2 Type II certification, a published incident response plan, New York Education Law 2-d compliance documentation, membership in the Student Data Privacy Consortium and multiple state privacy alliances, and a decade of operating student-data systems for K-12 districts. Atlara runs on that same operational playbook. District security questionnaires and documentation requests: support@codehs.com.

2. Encryption

• In transit: all traffic to Atlara is encrypted with TLS. There is no unencrypted access to the platform.
• At rest: databases and their backups are stored on encrypted volumes.
• Credentials: passwords are hashed with modern one-way algorithms (never stored or logged in plain text); secrets are managed through the platform's secret store, not in code.

3. Infrastructure

• Atlara runs on access-controlled cloud infrastructure in the United States, in SOC-audited data centers operated by our hosting provider.
• Production systems are isolated; the database is not reachable from the public internet.
• Dependencies are tracked and updated regularly; deploys are automated and repeatable, so patches ship in minutes, not maintenance windows.

4. Access controls

• In the product: role-based access — students see their own record; counselors see their caseload and school; district staff see their district; family members see only their linked students. Organization boundaries are enforced in code and covered by automated tests.
• Internally: production access is limited to the small set of engineers who operate the service, on least-privilege terms, with multi-factor authentication on the accounts that gate infrastructure and code.
• Support access: when our team accesses an account to help a school, it happens through an audited internal tool that displays a visible banner and is restricted to authorized staff.

5. Secure development

• All code is version-controlled and deployed through automated pipelines; nothing is edited by hand on servers.
• An automated test suite — including permission and organization-isolation tests — runs before every deploy.
• Framework-level protections (Django's CSRF, session, SQL-injection, and XSS defenses) are used as designed rather than reimplemented.
• Third-party dependencies are minimal by design and reviewed when added.

6. Backups & resilience

• Databases are backed up automatically every day, with point-in-time recovery available through our managed database provider.
• Backups are encrypted and age out on a fixed schedule — deletion commitments include backups.
• Restores are part of our operational runbook, not a theory.

7. Data handling

• We collect the minimum data the product needs (see the Privacy Policy for exactly what).
• Student data is never sold, never used for advertising, and never used to train AI models.
• Schools can export their data and request deletion at any time; offboarding includes an export followed by deletion from production within the committed window.
• Subprocessors are listed publicly in the Privacy Policy and bound to the same restrictions.

8. Incident response

CodeHS maintains an incident response plan covering identification, containment, remediation, and notification. If an incident affects a school's student personal information, we notify the affected school or district without unreasonable delay after confirming the incident, share what we know (scope, data involved, remediation), and support the school's own notification obligations — including the specific timelines in state laws like New York Education Law 2-d and in district DPAs.

9. Responsible disclosure

If you believe you've found a security vulnerability in Atlara, we want to hear from you. Email support@codehs.com with "Security" in the subject and enough detail to reproduce the issue.

• We'll acknowledge your report promptly, keep you informed as we fix it, and credit you if you'd like.
• Please make a good-faith effort to avoid accessing other people's data, degrading the service, or publicly disclosing before we've had a reasonable chance to fix the issue.
• We will not pursue action against good-faith security research conducted under these guidelines.

10. What schools control

Security is shared. Districts and schools control who has accounts (rostering), staff roles and caseloads, family links, single sign-on policy, and their own data lifecycle. We recommend districts use SSO where available, review staff access each term, and remove departed staff promptly — and Atlara's admin tools are built to make each of those a five-minute job, not a project.