Risk Register — Worked Example
This document shows what a fully populated risk register looks like after a Brownhat Diagnostic. It is a teaching example, not a real client record. Use it to calibrate the level of specificity expected in each field and to understand how the antifragile dimensions are applied in practice.
Fictional scenario: Meridian Logistics GmbH — 280 employees, hybrid AD + M365 E3, one warehouse with OT/IT overlap, outsourced MSSP with no custom detection. Brownhat Diagnostic completed 14 March 2025.
Risk Entries
AF-2025-001 · Domain Admin accounts used for daily work
| Field |
Value |
| Risk name |
Domain Admin accounts used for daily computing |
| Description |
All four Domain Admin accounts are also the accounts these admins use for email, browsing, and daily work. A phishing email to any one of them, or a drive-by browser exploit, directly yields Domain Admin credentials. No additional lateral movement required. |
| Tier |
T0 |
| Kill chain |
Phishing email → credential harvest → immediate DA access → Golden Ticket or DCSync → all AD-joined systems compromised → ransomware or data exfiltration within 2 hours |
| Shortest path to failure |
2 steps |
| Probability |
4 — High. Admin accounts are the most-targeted accounts in any environment; phishing success rates on unprotected accounts exceed 20%. |
| Impact |
5 — Existential. Full domain compromise. |
| Traditional risk score |
20 — P0 |
| Optionality impact |
Extreme. Once the domain is compromised, the organisation cannot safely use any AD-joined system. Cloud migration becomes impossible until full recovery. |
| Convexity |
Extreme. Creating separate admin accounts and deploying PAWs costs 2 consultant days. Domain recovery from a Golden Ticket attack takes 2–6 weeks and costs €200K–€800K. |
| Current control |
Password policy (12 characters minimum). No MFA on admin accounts. No PAWs. No PIM. |
| Antifragile move |
1. Create separate, non-mail-enabled admin accounts for all four admins. 2. Disable mail access on admin accounts via Conditional Access or AD attribute. 3. Procure or designate PAWs (locked-down workstations used only for admin tasks). 4. Enforce MFA on all admin accounts via Conditional Access. 5. Begin PIM rollout (Module 2). |
| Owner |
IT Manager |
| Target date |
28 March 2025 (14 days) |
| Status |
Open |
| Stress-to-signal mandate |
If this risk materialises: all admin activity permanently migrated to PAWs; quarterly access review for all privileged accounts institutionalised; admin account count reduced to minimum viable and documented. |
| Verification method |
Conditional Access sign-in logs show zero interactive logins from admin accounts to email or general applications. BloodHound re-run confirms no DA accounts have interactive sessions on non-PAW workstations. |
AF-2025-002 · Compromised password hashes in AD
| Field |
Value |
| Risk name |
Domain accounts with known-compromised or dictionary passwords |
| Description |
Elysium password audit (run 14 March 2025) identified 34 domain accounts whose password hashes match the known-compromised hash database. Of these, 3 are service accounts with elevated permissions, and 1 is a member of the IT Managers group. Password spray tools would crack these accounts in minutes without triggering lockout policies on the first attempt. |
| Tier |
T0 |
| Kill chain |
Password spray (external or internal) → service account compromise → lateral movement via permissions → domain escalation |
| Shortest path to failure |
3 steps (via the IT Managers account) |
| Probability |
5 — Very High. Password spray attacks are fully automated and run continuously against externally-visible authentication endpoints. |
| Impact |
5 — Existential via the privileged account paths |
| Traditional risk score |
25 — P0 |
| Optionality impact |
High. Compromised service accounts may have embedded credentials in scripts, pipelines, and third-party integrations — full remediation requires inventory of all places these accounts are referenced. |
| Convexity |
Extreme. Forcing password resets costs 0 budget. A service account used to pivot to domain takes weeks to eradicate. |
| Current control |
Password policy (12 chars minimum). No check against known-compromised hashes at set time. No monitoring of service account logins. |
| Antifragile move |
1. Immediate: force password reset on all 34 identified accounts. 2. For the 3 privileged service accounts: rotate and vault in PAM (or temporary password manager). 3. Audit all scripts and pipelines referencing these accounts before rotation to prevent service disruption. 4. Deploy Elysium on quarterly cadence as part of retained capability. 5. Implement EntraID Password Protection (ban known-weak passwords at set time). |
| Owner |
IT Manager |
| Target date |
21 March 2025 (7 days — immediate) |
| Status |
Open |
| Stress-to-signal mandate |
If any of these accounts are confirmed compromised: mandatory incident response; all service account credentials reviewed and rotated; password hygiene tool (Elysium or equivalent) deployed permanently on quarterly cadence. |
| Verification method |
Elysium re-run shows 0 accounts matching compromised hash database. Service account credential inventory documented and stored in PAM or password manager. |
AF-2025-003 · Backups never restored — recoverability unknown
| Field |
Value |
| Risk name |
Backup existence confirmed; restorability unverified |
| Description |
Veeam is deployed and running nightly jobs. The last documented restore test was performed during initial deployment 3 years ago. No restore has been attempted since. File server backups are confirmed; AD backup and Exchange/M365 data backup are unverified. RPO and RTO have never been formally defined. |
| Tier |
T0 |
| Kill chain |
Ransomware encrypts primary systems → recovery required from backup → backup restore fails or takes 3× expected time → extended downtime → operational failure |
| Shortest path to failure |
1 step (backup failure in a ransomware scenario) |
| Probability |
3 — Moderate. Backup corruption or misconfiguration is common; ransomware targeting the backup server is increasingly common. |
| Impact |
5 — Existential. If backups fail during a ransomware recovery, the organisation faces permanent data loss or payment of ransom with no guarantee of decryption. |
| Traditional risk score |
15 — P1 |
| Optionality impact |
Extreme. Without verified backups, the organisation has no option during a ransomware incident except payment or loss. Verified backups create the option to refuse payment. |
| Convexity |
Extreme. Scheduling one recovery drill costs 4 hours of IT time. A ransomware incident without working backups costs €500K–€2M+ and may not be survivable. |
| Current control |
Veeam running nightly backups. No restore tests. No immutable or offline copy confirmed. No defined RPO/RTO. |
| Antifragile move |
1. Immediate: schedule a restore test for one critical system (file server or AD) within 7 days. Document the result. 2. Define RPO/RTO for top 3 critical systems. 3. Confirm whether backups are air-gapped or immutable (ransomware-resistant). If not, configure Veeam immutable backup or add an offline copy. 4. Test AD backup specifically — AD restore is distinct from file restore and frequently untested. 5. Schedule quarterly restore drills as a standing calendar item. |
| Owner |
IT Manager |
| Target date |
28 March 2025 (P1 — within 30 days; first restore test within 7 days) |
| Status |
Open |
| Stress-to-signal mandate |
If a ransomware incident occurs before this is resolved: mandatory post-incident review of backup architecture; immutable copy deployed before resuming operations; quarterly restore drills mandated as board-visible KPI. |
| Verification method |
Documented restore test with timestamped results showing successful restore within defined RTO. Immutable backup copy confirmed in Veeam console. RPO/RTO defined and signed off by executive sponsor. |
AF-2025-004 · KRBTGT password not rotated in 843 days
| Field |
Value |
| Risk name |
Stale KRBTGT password — Golden Ticket persistence window |
| Description |
The KRBTGT account password has not been rotated in 843 days. Any attacker who has previously compromised the domain and extracted the KRBTGT hash holds a Golden Ticket valid until the password is rotated — twice, 10 hours apart. This means a past compromise may still be actively exploitable. |
| Tier |
T1 |
| Kill chain |
Previous domain compromise (unknown) → persistent Golden Ticket → reactivated domain access → any impact |
| Shortest path to failure |
1 step (if previous compromise occurred) |
| Probability |
2 — Unknown but non-trivial. Cannot rule out a previous compromise that was not detected. |
| Impact |
5 — Existential if previous compromise occurred |
| Traditional risk score |
10 — P2 (elevated to P1 due to optionality impact) |
| Optionality impact |
High. Until rotated, a potential past attacker retains the option to re-enter the domain at will. Rotation removes that option permanently. |
| Convexity |
High. KRBTGT rotation is a 30-minute procedure. The cost of a persistent Golden Ticket being exploited is existential. |
| Current control |
None. No rotation policy or cadence. |
| Antifragile move |
1. Rotate KRBTGT password twice (10 hours apart) during a scheduled maintenance window. 2. Establish a 180-day rotation cadence, calendar-blocked and IT-manager-owned. 3. After rotation, run a BloodHound collection to confirm no anomalous Kerberos ticket activity. |
| Owner |
IT Manager |
| Target date |
11 April 2025 (P1 — within 30 days; maintenance window to be scheduled) |
| Status |
Open |
| Stress-to-signal mandate |
If Golden Ticket evidence is discovered: mandatory full incident response; KRBTGT rotation immediately; assume full domain compromise until proven otherwise. |
| Verification method |
KRBTGT password last-set date in AD is < 30 days post-engagement. Rotation event in AD audit log. Next rotation date calendar-blocked. |
AF-2025-005 · No out-of-band communication channel
| Field |
Value |
| Risk name |
Incident response communication depends on corporate infrastructure |
| Description |
The organisation's incident response relies on Teams and corporate email. Both depend on Microsoft 365, Active Directory, and internet connectivity. In a ransomware scenario where AD is compromised or M365 is unavailable, the incident response team has no pre-established way to communicate securely. There is no out-of-band channel, no enrolled participants on alternative infrastructure, and no documented alternative. |
| Tier |
T1 |
| Kill chain |
Ransomware or credential compromise → Teams/email unavailable → IR team cannot coordinate → recovery time extends → operational damage increases |
| Shortest path to failure |
2 steps |
| Probability |
3 — Moderate. Ransomware attacks that target AD (the most common variant) will likely impact Teams and email. |
| Impact |
3 — Significant. Does not cause failure directly but extends recovery time and increases costs materially. |
| Traditional risk score |
9 — P3 (elevated to P1 due to convexity and the active risk from AF-2025-001) |
| Optionality impact |
Moderate. Without out-of-band comms, the organisation has no options for coordinated response when primary channels fail. |
| Convexity |
Extreme. Deploying a Delta Chat chatmail relay costs €7/month and 30 minutes of setup. Lack of communication during an active incident is immeasurable in cost. |
| Current control |
Personal mobile numbers exist for key staff. No structured channel, no encryption, no pre-enrolled participants. |
| Antifragile move |
1. Deploy a Delta Chat chatmail relay on an independent VPS (outside corporate network, outside M365). 2. Enrol: IT Manager, CISO/executive sponsor, all admins, CQRE consultant lead. 3. Document the channel in the incident response runbook as the primary IR communication method. 4. Test the channel monthly with a brief message — confirm all participants can receive. |
| Owner |
IT Manager |
| Target date |
21 March 2025 (very low effort — do this in the first week) |
| Status |
Open |
| Stress-to-signal mandate |
If an incident occurs without out-of-band comms: the channel is deployed as the first post-incident action before anything else. |
| Verification method |
Delta Chat relay deployed. All named participants enrolled and confirmed reachable. Channel documented in IR runbook. Monthly test message logged. |
AF-2025-006 · M365 audit log retention at 90 days
| Field |
Value |
| Risk name |
Unified Audit Log retention insufficient for investigation and compliance |
| Description |
The M365 Unified Audit Log is retained for 90 days (E3 default). Security investigations frequently require logs older than 90 days — breach discovery typically occurs 197 days after initial access (IBM Cost of Data Breach average). An incident discovered today may require logs from 6 months ago for attribution and scope assessment. Regulatory requirements (DORA, NIS2) expect logs sufficient to reconstruct incidents. |
| Tier |
T1 |
| Kill chain |
Breach occurs → discovered 197 days later → investigation requires logs → logs deleted at 90 days → incident scope and attribution impossible → regulatory non-compliance |
| Shortest path to failure |
1 step (breach + 90-day gap = irretrievable evidence) |
| Probability |
3 — Moderate. Breaches occurring in the 90-day window where logs would be needed are not unlikely given the average discovery gap. |
| Impact |
3 — Significant. Primarily a compliance and investigation impact rather than operational failure. |
| Traditional risk score |
9 — P3 (elevated to P2 due to regulatory exposure) |
| Optionality impact |
Moderate. Once logs are deleted, the option to investigate and prove scope is permanently lost. |
| Convexity |
High. Extending retention to 180 days requires E3 Compliance Add-on (≈€8/user/month) or ingestion into a long-term log store (PULSAR + blob storage). Cost vs. cost of regulatory non-compliance is asymmetric. |
| Current control |
M365 Unified Audit Log at 90-day default. No secondary storage. PULSAR not yet deployed. |
| Antifragile move |
1. Deploy PULSAR to ingest and persist audit logs beyond the 90-day window into the organisation's own infrastructure (MongoDB + blob storage). 2. Alternatively, evaluate E3 Compliance Add-on for extended Microsoft-native retention. 3. Document retention policy and verify it meets applicable regulatory requirements (NIS2 Article 21 recommends 12+ months). |
| Owner |
CISO / IT Manager |
| Target date |
30 April 2025 (P2 — within 90 days) |
| Status |
Open |
| Stress-to-signal mandate |
If an incident reveals log gaps: PULSAR deployed immediately post-incident; retention policy reviewed and extended to regulatory minimum; board notified of compliance gap. |
| Verification method |
PULSAR deployed with log ingestion confirmed. Oldest ingested log age exceeds 180 days within 6 months of deployment. Retention policy documented and signed off. |
AF-2025-007 · MSSP running generic rules — no custom detection
| Field |
Value |
| Risk name |
Outsourced SOC with no environment-specific detection |
| Description |
The organisation pays a managed SOC provider €8,500/month. The MSSP deploys its standard detection ruleset — tuned for its entire client base, not for Meridian's specific environment, architecture, or threat model. No custom rules have been written for Meridian-specific risks: the OT/IT boundary, service account behaviour baselines, or logistics-industry TTPs. An assessment of 5 common TTPs showed the MSSP would detect 2 of 5. |
| Tier |
T2 |
| Kill chain |
Targeted attacker uses logistics-industry TTP → MSSP generic rules do not fire → attacker operates undetected for days/weeks → damage occurs |
| Shortest path to failure |
3–5 steps (attacker must complete multiple phases undetected) |
| Probability |
3 — Moderate. Generic rules are well-documented to miss targeted attacks; logistics is an increasingly targeted sector. |
| Impact |
4 — Major. Extended dwell time dramatically increases breach cost and scope. |
| Traditional risk score |
12 — P2 |
| Optionality impact |
Moderate. Without detection, the organisation cannot exercise the option to contain and eject an attacker early. |
| Convexity |
High. Building a detection engineering cell (1 FTE equivalent) costs ≈€150K/year and makes the €102K/year MSSP investment 3× more effective. |
| Current control |
MSSP with generic ruleset. PULSAR not deployed. No custom detection rules. MSSP SLA measures ticket response time, not detection coverage. |
| Antifragile move |
1. Conduct a purple team TTP coverage test against the MSSP (5 TTPs, as described in the Retained Capability document). 2. Deploy PULSAR to add M365-specific detection on top of the MSSP. 3. Write 3–5 custom detection rules for the highest-priority Meridian-specific TTPs (OT/IT boundary crossing, service account anomalies, large SharePoint exports). 4. Add detection coverage rate to the MSSP SLA. 5. Consider a retained capability arrangement to maintain and extend the custom ruleset. |
| Owner |
IT Manager / outsourced CISO |
| Target date |
30 June 2025 (P2 — within 90 days to start; sustained programme) |
| Status |
Open |
| Stress-to-signal mandate |
If an attacker achieves extended dwell time undetected: MSSP relationship reviewed and re-contracted with detection coverage metrics; retained detection engineering capability established immediately. |
| Verification method |
Purple team test result: MSSP detects ≥4 of 5 tested TTPs with custom rules deployed. Detection coverage rate added to monthly MSSP reporting. |
AF-2025-008 · Service account passwords not rotated
| Field |
Value |
| Risk name |
Service accounts with non-expiring passwords and no rotation policy |
| Description |
18 service accounts have password-never-expires set. 11 of these have not had passwords changed in over 2 years; 3 have not been changed since account creation (the oldest is 6 years old). Service account credentials are stored in a shared Excel spreadsheet accessible to 4 IT staff. Any of the 4 staff members (including 2 who have since left) could have exfiltrated these credentials. |
| Tier |
T2 |
| Kill chain |
Former employee with exfiltrated service account credentials → authentication from external location → exploitation of account permissions → persistence |
| Shortest path to failure |
2 steps |
| Probability |
2 — Low-moderate. No evidence of compromise, but credential exposure via the spreadsheet means the attack surface is wider than known. |
| Impact |
3 — Significant. Depends on the permissions of the specific service accounts accessed. |
| Traditional risk score |
6 — P3 (elevated to P2 due to optionality and the spreadsheet exposure) |
| Optionality impact |
Moderate. Exposed credentials that cannot be tracked mean the organisation cannot confidently assert that no compromise has occurred or will occur. |
| Convexity |
High. Rotating 18 passwords and vaulting them costs 1 day of IT work. A service account used to establish persistence is weeks of incident response. |
| Current control |
Password-never-expires set. Credentials in Excel spreadsheet. No PAM solution. No audit trail for service account access. |
| Antifragile move |
1. Immediate: identify the 3 accounts used by departed staff and rotate passwords. 2. Within 30 days: rotate all 18 service account passwords. Vault new passwords in a password manager (minimum) or PAM solution (preferred). 3. Remove the Excel spreadsheet. 4. Enable service account login auditing in AD. 5. For Module 13 (Privileged Access), migrate service accounts into Teleport or equivalent for session recording. |
| Owner |
IT Manager |
| Target date |
Immediate rotation of departed-staff accounts: 17 March 2025. All accounts: 11 April 2025. |
| Status |
Open |
| Stress-to-signal mandate |
If a service account is confirmed compromised: all service account credentials rotated immediately; PAM solution deployed before credentials are restored to operation; Excel credential store permanently prohibited. |
| Verification method |
All service account passwords rotated (AD last-password-set date confirms). Excel file deleted and confirmed removed from all backup copies. Credentials in password manager or PAM. Audit logging enabled and confirmed on all service accounts. |
Summary Dashboard
| Risk ID |
Name |
Tier |
P |
I |
Score |
Priority |
Owner |
Due |
Status |
| AF-2025-001 |
DA accounts used daily |
T0 |
4 |
5 |
20 |
P0 |
IT Mgr |
28 Mar |
Open |
| AF-2025-002 |
Compromised password hashes |
T0 |
5 |
5 |
25 |
P0 |
IT Mgr |
21 Mar |
Open |
| AF-2025-003 |
Backups unverified |
T0 |
3 |
5 |
15 |
P1 |
IT Mgr |
28 Mar |
Open |
| AF-2025-004 |
KRBTGT 843 days stale |
T1 |
2 |
5 |
10 |
P1* |
IT Mgr |
11 Apr |
Open |
| AF-2025-005 |
No out-of-band channel |
T1 |
3 |
3 |
9 |
P1* |
IT Mgr |
21 Mar |
Open |
| AF-2025-006 |
Audit log 90-day retention |
T1 |
3 |
3 |
9 |
P2 |
CISO |
30 Apr |
Open |
| AF-2025-007 |
MSSP generic rules only |
T2 |
3 |
4 |
12 |
P2 |
IT Mgr |
30 Jun |
Open |
| AF-2025-008 |
Service account passwords |
T2 |
2 |
3 |
6 |
P2 |
IT Mgr |
11 Apr |
Open |
* Elevated from traditional score based on convexity and optionality impact.
Kill chain summary: The shortest path to organisational failure runs through AF-2025-001 (DA account compromise) and AF-2025-002 (compromised hashes). These two risks, combined, mean an attacker with a phishing kit and a password spray tool can achieve full domain compromise in under an hour. They must be closed before anything else.
Integration With Existing Frameworks
For the risk register template and scoring methodology, see Antifragile Risk Register.
For the module completion report that generates risk register updates, see Module Completion Report.