◇ OpenCyber Academy
Bachelor's · Chapter 13 · English

Chapter 13 — Identity and access

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 13 — Identity and access

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Roles"]
  N2["13.2 Joiners, movers and leavers"]
  N3["13.3 Access reviews"]
  N4["13.4 Authentication"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Roles"]
  N2["13.2 Joiners, movers and leavers"]
  N3["13.3 Access reviews"]
  N4["13.4 Authentication"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Roles]
    |
    v
[13.2 Joiners, movers and leavers]
    |
    v
[13.3 Access reviews]
    |
    v
[13.4 Authentication]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) design role-based access for school systems; (2) manage joiners, movers and leavers; (3) review access regularly.

13.1 Roles

Elena designs roles for the trust's management information system: class teacher, head of year, special needs coordinator, office administrator, safeguarding lead and head teacher. Each role has defined access. She documents the purpose of each permission. For example, office administrators need contact details to send letters but not assessment results. Role design turns the principle of least privilege into something staff and auditors can understand and check. The office role, for example, can update contact details but cannot see reading levels.

13.2 Joiners, movers and leavers

Staff change roles often. Elena finds that a former special needs coordinator, now a class teacher, still has access to all support plans. Another teacher who left the trust six months ago still has an active account. She proposes a process linked to the human resources system: when someone joins, moves or leaves, their access changes automatically, with a manager confirming the new role. She notes that stale access is one of the most common access control failures in organisations of every size.

13.3 Access reviews

Elena sets up termly access reviews. Each head teacher receives a list of staff and their roles and confirms or corrects them. In the first review, eleven of 340 accounts need changes. She records the results and repeats the review the next term, when only three changes are needed. Regular reviews, she explains, catch errors that automated processes miss and provide evidence of accountability under Article 5(2) of the GDPR. Each head teacher confirms their school's list every term. Corrections are logged with dates and reasons.

13.4 Authentication

Elena recommends multi-factor authentication for staff accessing pupil records from outside school. She also recommends that pupils use simple but individual logins appropriate to their age. Very young pupils may use picture passwords on classroom devices, while older pupils use passwords. She explains that authentication must suit the people using it, and that security that young children cannot manage will be bypassed by well-meaning teachers sharing logins. Younger pupils use picture passwords on shared tablets, and teachers no longer need to share their own logins.

Worked example

Elena defines six roles with documented purposes, links access changes to HR, runs termly reviews (eleven changes falling to three) and adapts authentication to staff and pupils' ages.

Synthetic case. Accounts and roles are synthetic; GDPR Article 5(2) is real.

Errors and limits

HR integration fails if HR records are late; reviews remain necessary.

Exercises

Synthesis

Chapter 13 manages access. Chapter 14 lays privacy foundations.

Continue studying — chapter 13 of 40

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →