Chapter 12 — Roles and accountability
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Key roles"]
N2["12.2 Accountability"]
N3["12.3 Separation of duties"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Key roles"]
N2["12.2 Accountability"]
N3["12.3 Separation of duties"]
N0 --> N1 --> N2 --> N3 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Key roles]
|
v
[12.2 Accountability]
|
v
[12.3 Separation of duties]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) define key security roles; (2) assign accountability for information and controls; (3) separate duties to reduce fraud and error.
12.1 Key roles
Aisha lists security roles at Ashfield. The board holds ultimate accountability. The chief executive ensures resources. The IT manager leads security operations, as Ashfield is too small for a dedicated security officer. Information owners, such as the head of lending, decide how their information is protected. All staff follow policies and report incidents. Dr. Carrow notes that small organisations often combine roles, which is acceptable if responsibilities are written down and conflicts are managed openly. Aisha writes each role's main duties in a single sentence for the staff handbook.
12.2 Accountability
Accountability means a named person answers for an outcome. Aisha finds that several controls at Ashfield have no named owner: the firewall review, supplier security checks and backup testing. Each was assumed to be someone else's job. She drafts a responsibility table listing each control, its owner and how often it runs. The chief executive approves it. She learns that unowned controls tend to stop without anyone noticing, which is why naming owners matters. Within a month, all three controls have run at least once under their new owners.
12.3 Separation of duties
Separation of duties splits sensitive tasks so no single person can complete them alone. At Ashfield, one person enters a payment and another approves it. Aisha finds that the IT manager can both create user accounts and approve their access, so an unauthorised account could be created without anyone else knowing. She recommends that access approvals come from information owners. Dr. Carrow links this to Saltzer and Schroeder's principle of separation of privilege. The head of lending and the head of finance agree to approve access for their own teams.
12.4 Small-organisation limits
Strict separation is hard in small teams. Ashfield has only two IT staff, so when one is on holiday, the other must do everything. Aisha suggests compensating controls: logging all administrator actions and having the head of operations review the log weekly. She learns that when separation is impossible, detection and review can partly replace it, and that documenting the compromise shows it was a deliberate decision rather than an oversight. The head of operations performs the first weekly review with Aisha watching, and finds every logged action explained by a ticket.
Worked example
Aisha lists roles, names owners for unowned controls, finds that one person creates and approves accounts and proposes logging and review where separation is impossible.
Synthetic case. Roles are synthetic.
Errors and limits
Controls that nobody owns tend to stop without anyone noticing.
Exercises
- EX034 — Unowned controls. Name one control that had no owner. Rubric: 3 = firewall review;; 2 = one;; 1 = vague;; 0 = none.
- EX035 — Access conflict. What conflict does the IT manager have? Rubric: 3 = creates and approves accounts;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX036 — Compensating control. What compensates for limited separation? Rubric: 3 = logging admin actions with weekly review;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 12 (chapter 12 of 40)
← Chapter 11 · Course chapter index · Chapter 13 →
Continue to the next authored lesson.