Access Control Policy

• Document owner: Oscar Ramos
• Approved by: Eli Johnson, Product Manager
• Version: 1.0
• Approved date: 9/21/2026
• Next review: 9/21/2027
• Applies to: Founders, Co-Founders, Designers, Head of Education Partnerships, and Software Developers

1. Purpose

To ensure that access to Ladderly Learning systems and data — especially student education records — is granted only to authorized individuals, limited to what their role requires, and removed when no longer needed. This policy supports our FERPA obligation to restrict who can see student data.

2. Principles

• Least privilege. Each person receives the minimum access needed to perform their role — no more.
• Role-based access (RBAC). Access is assigned through defined roles, not case-by-case one-offs, wherever possible.
• Need to know. Access to Restricted data (student records, credentials, secrets) requires a legitimate business need.
• Accountability. Every account maps to a single identifiable person. Shared accounts are prohibited except where technically unavoidable, and then must be documented and tightly controlled.

3. Account and identity management

• Access uses unique, individual accounts. Generic or shared logins are not permitted for systems holding Restricted data.
• Passwords meet Ladderly Learning’s standard: minimum 12 characters, managed via a password manager, never reused across systems, never shared
• Privileged/administrative accounts are limited to the smallest possible number of people, and are reviewed at least once a year to ensure they are still needed.

4. Granting access (onboarding)

1. Access is requested via the Data Privacy Lead and specifies the role and systems needed.
2. The request is approved by the individual’s manager and, for Restricted-data systems, the Data Privacy Lead.
3. Access is provisioned according to the predefined role profile for that job.
4. New personnel complete security and FERPA training before receiving access to student data, and acknowledge this and related policies.

5. Changing access (role changes / transfers)

When someone changes roles, their access is re-evaluated and adjusted to the new role. Access from the previous role that is no longer needed is removed. Role changes trigger the same approval and recording steps as onboarding.

6. Removing access (offboarding)

Prompt removal of access is critical. When someone leaves or a contractor’s engagement ends:

• The user notifies Data Privacy Lead of the departure, ideally in advance for planned exits.
• All access is disabled on the effective date — target within 72 hrs of departure, and immediately for involuntary terminations.
• This includes: SSO/identity provider, email, all SaaS applications, production and cloud infrastructure, code repositories, admin consoles, and any local device accounts.
• Company data on personal devices is removed.
• Shared credentials the person knew are rotated.
• Offboarding completion is recorded with a checklist and date.

7. Periodic access reviews

To catch access that should have been removed and enforce least privilege, Ladderly Learning performs access reviews:

• Frequency: at least twice a year for systems holding student data and privileged access; at least annually for all other systems.
• How: The Security Officer generates a current list of who has access to each in-scope system; each manager reviews it and confirms each person still needs their access.
• Outcome: unnecessary or excessive access is removed promptly; the review (reviewer, date, findings, actions taken) is recorded and retained as evidence.

8. Enforcement & exceptions

Violations may result in disciplinary action up to and including termination. Exceptions require documented approval from the Security Officer with justification, compensating controls, and an expiry date.

9. Review

Reviewed and re-approved at least annually and upon significant change.