Chapter 3 — Authorized practice and evidence handling

Lesson map

Lesson 03 published. Map, example, EX011.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Authorisation first"]
  N2["3.2 Handling evidence"]
  N3["3.3 Protecting personal data"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX011"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Authorisation first"]
  N2["3.2 Handling evidence"]
  N3["3.3 Protecting personal data"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX011"]

[Learning outcomes]
    |
    v
[3.1 Authorisation first]
    |
    v
[3.2 Handling evidence]
    |
    v
[3.3 Protecting personal data]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

You will (1) obtain authorisation before security work; (2) handle evidence carefully; (3) protect personal data during reviews.

3.1 Authorisation first

Owen wants to review access to the case management system. Ines insists he first gets written authorisation from the system owner and the head of IT, Kwame Asante, stating what he may look at, when and why. Even an internal employee can cause harm or break policy by looking at systems without permission, especially ones holding safeguarding notes. The authorisation also protects Owen if questions are later raised about why he accessed sensitive records. He keeps it with his working papers.

3.2 Handling evidence

During the review Owen exports user and role lists rather than browsing tenant records. He records what he exported, when and from which system, and stores files in a restricted folder. He calculates a checksum of each export so he can show later that it was not altered. If his findings lead to disciplinary action, his evidence must stand up to challenge. Careful handling also means deleting copies when the work ends, as agreed in his authorisation, rather than keeping them indefinitely.

3.3 Protecting personal data

Owen's review needs names of staff with access, but not tenant details. When a role report includes tenant names by mistake, he stops, informs the system owner and deletes the extra data. He writes his findings using role names and counts, mentioning individuals only where necessary. ISO/IEC 27001:2022 expects information handling to follow agreed rules, and data protection law limits use to the purpose agreed. Minimising personal data in a review reduces the harm if the review files are ever exposed.

Worked example

Owen obtains written authorisation, exports and checksums role lists, stores them securely and deletes mistakenly included tenant data.

Synthetic case. Systems and events are synthetic; ISO/IEC 27001:2022 is real.

Errors and limits

Authorisations may be vague. Checksums prove integrity, not completeness.

Exercises

• EX011 — Who authorised. Who authorised Owen's review?
  Show marking criteria

  Rubric: 3 = the system owner and Kwame Asante, head of IT;; 2 = both;; 1 = vague;; 0 = none.
• EX012 — Checksum purpose. Why calculate a checksum of each export?
  Show marking criteria

  Rubric: 3 = to show later it was not altered;; 2 = integrity;; 1 = secrecy;; 0 = none.
• EX013 — Mistaken data. What did Owen do when tenant names appeared?
  Show marking criteria

  Rubric: 3 = stopped, informed the owner and deleted the extra data;; 2 = stop;; 1 = continued;; 0 = none.
• EX014 — Deletion. When are working copies deleted?
  Show marking criteria

  Rubric: 3 = when the work ends, as agreed;; 2 = end of work;; 1 = never;; 0 = none.
• EX015 — Export not browse. Why export role lists instead of browsing records?
  Show marking criteria

  Rubric: 3 = to avoid viewing tenant data not needed for the review;; 2 = minimise;; 1 = speed;; 0 = none.

Synthesis

Authorised work, careful evidence handling and minimal personal data protect both the organisation and the practitioner.

Continue studying — chapter 03 of 12

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →