Chapter 11 — Reporting and troubleshooting

Chapter 11 — Reporting and troubleshooting

Lesson map

Lesson 11 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Partner reports"]
  N2["11.2 Troubleshooting"]
  N3["11.3 Linking to controls"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Partner reports"]
  N2["11.2 Troubleshooting"]
  N3["11.3 Linking to controls"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX051"]

[Learning outcomes]
    |
    v
[11.1 Partner reports]
    |
    v
[11.2 Troubleshooting]
    |
    v
[11.3 Linking to controls]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes

You will (1) write reports for partners; (2) troubleshoot identity issues; (3) link problems to controls.

11.1 Partner reports

Daniel writes a monthly two-page report for partners: what changed, key measures, open risks and decisions needed. Measures include MFA coverage, phishing-resistant coverage for high-value accounts, leavers removed on time, drift findings and guest problems. He avoids jargon and explains each risk in client terms, such as the chance of a client's tax records being seen by someone outside the engagement. Partners read short reports, so every line must earn its place. Each report ends with the decisions partners are asked to make that month.

11.2 Troubleshooting

After MFA enforcement, a partner cannot reach email on her tablet. Daniel follows his method: confirm the symptom, check the sign-in log reason, form a hypothesis and test. The log shows an old mail app that cannot handle modern authentication. He installs the supported app, she signs in and he records the cause. Two other staff have the same app; he updates them proactively. Logs give the reason for most identity failures directly. The case is recorded with its cause and fix.

11.3 Linking to controls

Daniel records troubleshooting cases by cause. Over two months, most relate to old apps, expired passwords on service accounts and staff changing phones without moving their authenticator. He links each to a control improvement: an approved app list, service account renewal reminders and a phone change guide. Turning support cases into control improvements reduces repeated problems and shows partners that security work also improves everyday reliability. He reports the linked improvements to partners in the monthly report, and tracks whether each cause falls in the following months. Two of the three causes fall noticeably.

Worked example

Monthly partner reports track five measures; an old mail app causes a partner's failure and two proactive fixes; three control improvements follow.

Synthetic case. Reports and cases are synthetic.

Errors and limits

Fixing repeated support cases one by one without changing controls keeps them recurring.

Exercises

• EX051 — Report length. How long is the partner report? Rubric: 3 = two pages;; 2 = short;; 1 = twenty pages;; 0 = none.
• EX052 — Partner tablet cause. Why could the partner not reach email? Rubric: 3 = old app without modern authentication;; 2 = old app;; 1 = password;; 0 = none.
• EX053 — Proactive fix. What proactive step was taken? Rubric: 3 = updated the app for two other staff;; 2 = updated;; 1 = vague;; 0 = none.
• EX054 — Common cause. Name one common troubleshooting cause. Rubric: 3 = old apps;; 2 = phone changes;; 1 = weather;; 0 = none.
• EX055 — Control link. Which improvement addresses phone changes? Rubric: 3 = a phone change guide;; 2 = guide;; 1 = vague;; 0 = none.

Synthesis

Short partner reports and cause-linked troubleshooting turn identity work into visible improvement.

Continue studying — chapter 11 of 12

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