Chapter 3 — Authorized practice and evidence handling
Lesson map
Lesson 03 published. Map, example, EX011.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Authority"]
N2["3.3 Evidence"]
N3["3.4 Integrity"]
N4["3.5 Privacy"]
N5["3.6 Professional duty"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX011"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Authority"]
N2["3.3 Evidence"]
N3["3.4 Integrity"]
N4["3.5 Privacy"]
N5["3.6 Professional duty"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX011"]
[Learning outcomes]
|
v
[3.1 Authority]
|
v
[3.3 Evidence]
|
v
[3.4 Integrity]
|
v
[3.5 Privacy]
|
v
[3.6 Professional duty]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX011]
Learning outcomes
You will (1) work within written authority; (2) handle evidence with care; (3) respect resident data.
3.1 Authority
Dev and the council's information security officer sign a brief giving Hannah read access to identity and registry settings, read access to cluster configuration, and the right to propose changes through the normal change process. The brief protects both Hannah and the council: she cannot be accused of acting beyond her role, and the council knows exactly what access she holds. Read access is enough to collect evidence, while every change goes through the same approval as any other production change. The brief has a start and end date, and Hannah's access is removed when it ends.
3.2 Limits
Hannah does not access resident data, does not test the service for weaknesses, and does not change production without approval. These limits keep the project to configuration review. Testing the service for weaknesses would need a separate authorisation and a different kind of plan, and resident data is not needed to analyse roles or images. The limits are written in the brief, so if anyone asks Hannah to go further, she can point to them and ask Dev for a decision.
3.3 Evidence
She exports role definitions, 90 days of permission usage from the provider's access logs, and image scan results. Each export is saved with time, source and her name. Ninety days covers most routine tasks the workloads perform, but may miss rare ones, so unused permissions are only candidates for removal until owners confirm them. If a finding is challenged, Hannah can show where the evidence came from and when. Scan results are exported weekly in the same way, so the permits-web, permits-worker and reporting findings can be compared from one week to the next.
3.4 Integrity
Exports are stored in a restricted folder with read-only copies; a short register lists each item. Keeping read-only copies means the original exports cannot be altered, even accidentally, while Hannah works on her own copies. The register records each export's name, date, source, size and where it is stored, so auditors can check that the evidence behind a finding is the evidence collected. Access to the folder is limited to Hannah and Dev. The register itself is part of her portfolio for Kingsbridge. Evidence is kept for the audit period and then deleted according to the council's retention schedule.
3.5 Privacy
Access logs contain staff names and resident-facing service activity but not resident records. Hannah removes staff names from shared summaries. Staff names are not needed to show that a permission was unused, so they appear only in the original exports, which stay in the restricted folder. Summaries for stakeholders refer to roles and workloads instead. Hannah checks with the data protection officer that this handling is acceptable, and records the answer. The approach also supports the later decision to report findings about systems and processes, not individuals.
3.6 Professional duty
If she sees something outside scope that worries her, she reports it to Dev rather than investigating alone. Investigating alone could take her outside her authority and might disturb evidence that someone else needs. Reporting to Dev means the issue is handled by people with the right access and responsibility. She records what she found and when she reported it, without investigating further herself.
Written authority protects Hannah, the council and residents. If something breaks or an auditor asks why she viewed certain logs, the brief shows she acted within agreed limits. It also forces a conversation about scope at the start, so nobody is surprised later. The Kingsbridge course treats this as a core professional practice: competence includes knowing what one is allowed to do and keeping records that show it.
Worked example
While exporting logs, Hannah notices a role belonging to a former contractor. It is outside her brief to remove it, so she reports it to Dev, who has it removed the same day through the normal process.
Synthetic case. Synthetic.
Errors and limits
Acting outside authority, even helpfully, can undermine evidence and trust.
Exercises
- EX011 — Granted access. What access does the brief grant? Rubric: 3 = read identity, registry, cluster; propose changes; 2 = three; 1 = two; 0 = none.
- EX012 — Prohibited actions. Name the three limits. Rubric: 3 = no resident data, no testing, no unapproved production change; 2 = two; 1 = one; 0 = none.
- EX013 — Evidence set. What evidence did Hannah export? Rubric: 3 = roles, 90 days usage, scan results; 2 = two; 1 = one; 0 = none.
- EX014 — Privacy step. How is staff privacy protected in summaries? Rubric: 3 = names removed; 2 = partial; 1 = vague; 0 = none.
- EX015 — Contractor role. How was the contractor role handled? Rubric: 3 = reported to Dev, removed via process; 2 = partial; 1 = vague; 0 = none.
Synthesis
Work within written authority and handle evidence carefully.
Continue studying — chapter 03 of 12
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →