Chapter 8 — Operational workflow and change
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Request flows"]
N2["8.2 Reviewing changes"]
N3["8.3 Audit trail"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX036"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Request flows"]
N2["8.2 Reviewing changes"]
N3["8.3 Audit trail"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 Request flows]
|
v
[8.2 Reviewing changes]
|
v
[8.3 Audit trail]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) design request and approval flows; (2) review identity changes; (3) keep an audit trail.
8.1 Request flows
Access requests at Ashby and Lane used to arrive by email or in conversation. Daniel sets up a simple request form: who, what access, why, for how long, and approval by the resource owner. Requests for partner-level or payroll access also need the managing partner. Approved requests are fulfilled through role groups wherever possible. A consistent flow means every grant has an approver and a reason, which reviews and auditors can check later without relying on anyone's memory. The form is short so staff use it.
8.2 Reviewing changes
Identity changes such as new admin roles, policy edits or new guest domains are reviewed before they happen. Daniel writes a short change template: what, why, risk, test, rollback and approver. Helen reviews his first few. One proposed change, allowing guests from any external domain, is narrowed to the domains of named auditors and clients after review. Reviewing changes catches broad settings before they quietly widen access across the whole firm. Approved changes are recorded with their template, and the record is linked from the monthly audit check so reviewers can follow each change.
8.3 Audit trail
Daniel matches the directory's audit log to approved requests and changes each month. He finds two group additions without a request, both by the office manager covering a busy week. Neither is harmful, but he agrees with the managing partner that urgent grants are allowed if a request is logged the same day. An audit trail that matches activity to approvals shows the firm's controls are real, and gaps reveal where the process needs to fit work better. The rule is added to the runbook.
Worked example
A request form and change template are adopted; a guest-domain change is narrowed; two unrequested additions lead to a same-day logging rule.
Synthetic case. Requests, changes and findings are synthetic.
Errors and limits
Granting access from verbal requests leaves no approver or reason to review.
Exercises
- EX036 — Request fields. Name two request form fields. Rubric: 3 = who and why;; 2 = duration, approval;; 1 = colour;; 0 = none.
- EX037 — Extra approval. Which requests need the managing partner? Rubric: 3 = partner-level or payroll access;; 2 = payroll;; 1 = all;; 0 = none.
- EX038 — Narrowed change. What change was narrowed? Rubric: 3 = guests from any domain to named domains;; 2 = guest domains;; 1 = vague;; 0 = none.
- EX039 — Audit finding. What did audit matching find? Rubric: 3 = two group additions without request;; 2 = two;; 1 = vague;; 0 = none.
- EX040 — Urgent rule. What rule covers urgent grants? Rubric: 3 = log a request the same day;; 2 = same day;; 1 = forbidden;; 0 = none.
Synthesis
Request flows, change review and audit matching make every access change accountable.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →