Initial commit: antifragile cybersecurity consulting blueprint
Complete repository of frameworks, playbooks, and assessment resources for cybersecurity consultations focused on antifragile enterprise design. Includes: - Core philosophy and manifest (5 pillars) - 12 modular engagement packages - AI sovereignty and operations frameworks - Zero-budget vulnerability discovery and hardening playbooks - M365 E3 hardening and antifragile project plans - Osquery sovereign discovery platform blueprint - Perimeter scanning capability guide - AI-assisted TVM blueprint for AI-powered adversaries - Vertical specializations: banking, telco, power/utilities - CIS Controls v8 and NIST CSF 2.0 mappings - Risk registers and assessment templates - C-suite conversation guide and business case templates
This commit is contained in:
77
antifragile-consulting/assessment-templates/README.md
Normal file
77
antifragile-consulting/assessment-templates/README.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# Assessment Templates
|
||||
|
||||
> *"What gets measured gets managed. What gets managed honestly becomes antifragile."*
|
||||
|
||||
This directory contains diagnostic tools, maturity models, and assessment resources for evaluating organizational antifragility. Two production-ready tools are available now; additional assessments are in active development.
|
||||
|
||||
## Planned Assessments
|
||||
|
||||
### 1. Antifragile Maturity Model (AF-MM)
|
||||
|
||||
A five-level maturity model covering:
|
||||
|
||||
- **Level 1: Fragile** — Reactive, undocumented, dependent on single vendors
|
||||
- **Level 2: Robust** — Documented, monitored, but static
|
||||
- **Level 3: Resilient** — Automated recovery, tested backups, incident response operational
|
||||
- **Level 4: Adaptive** — Chaos engineering, continuous learning, structural improvement from failure
|
||||
- **Level 5: Antifragile** — Volatility is exploited for gain, optionality is strategic, intelligence is sovereign
|
||||
|
||||
### 2. AI Sovereignty Readiness Assessment
|
||||
|
||||
Evaluates:
|
||||
|
||||
- Current AI usage inventory completeness
|
||||
- Data classification and leakage risk
|
||||
- Local infrastructure readiness
|
||||
- Vendor dependency and exit feasibility
|
||||
- Regulatory compliance posture
|
||||
|
||||
### 3. T0 Asset Discovery Scanner
|
||||
|
||||
Planned scripted assessment to:
|
||||
|
||||
- Enumerate critical assets across on-premises and cloud environments
|
||||
- Classify assets by tier based on dependency mapping
|
||||
- Identify gaps in protection, monitoring, and recovery
|
||||
- Generate prioritized remediation roadmap
|
||||
|
||||
### 4. Dependency Risk Mapper
|
||||
|
||||
Planned tool to:
|
||||
|
||||
- Map vendor and technology dependencies
|
||||
- Calculate coupling depth and exit difficulty
|
||||
- Identify hidden single points of failure
|
||||
- Simulate failure cascades
|
||||
|
||||
### 5. Incident Learning Index
|
||||
|
||||
Measures the organization's ability to convert incidents into structural improvements:
|
||||
|
||||
- Mean time to structural fix
|
||||
- Post-mortem completion rate
|
||||
- Structural changes implemented per incident
|
||||
- Repeat incident rate
|
||||
|
||||
## Development Roadmap
|
||||
|
||||
| Quarter | Deliverable | Format |
|
||||
|---------|-------------|--------|
|
||||
| Q1 | AF-MM v1.0 questionnaire and scoring guide | Markdown + spreadsheet |
|
||||
| Q2 | AI Sovereignty Readiness Assessment v1.0 | Interactive web form or CLI tool |
|
||||
| Q3 | T0 Asset Discovery Scanner v0.1 | Python script (cloud APIs + on-premises) |
|
||||
| Q4 | Dependency Risk Mapper v0.1 | Python + network analysis libraries |
|
||||
|
||||
## Contributing
|
||||
|
||||
When adding new assessments:
|
||||
|
||||
1. Document the purpose, methodology, and limitations
|
||||
2. Include scoring rubrics with clear criteria
|
||||
3. Provide sample outputs and interpretation guidance
|
||||
4. Version assessments and maintain changelogs
|
||||
5. Test on at least two different organizational profiles before release
|
||||
|
||||
---
|
||||
|
||||
*Return to [Repository Index](../README.md)*
|
||||
@@ -0,0 +1,204 @@
|
||||
# Antifragile Risk Register Template
|
||||
|
||||
> *"Traditional risk registers count vulnerabilities. Antifragile risk registers map the kill chain, preserve optionality, and engineer convexity."*
|
||||
|
||||
This template replaces conventional risk management with an antifragile approach. It is designed to identify not just what can go wrong, but **how the organization benefits from addressing it**—and what structural improvement emerges from each risk realization.
|
||||
|
||||
---
|
||||
|
||||
## The Antifragile Risk Dimensions
|
||||
|
||||
Traditional risk registers track Probability and Impact. We add five antifragile dimensions:
|
||||
|
||||
| Dimension | Traditional Equivalent | Antifragile Question |
|
||||
|-----------|----------------------|---------------------|
|
||||
| **Kill Chain Position** | Asset location | "If this risk materializes, what is the shortest path to organizational failure?" |
|
||||
| **Optionality Impact** | N/A | "Does this risk, if unaddressed, remove our ability to change direction?" |
|
||||
| **Convexity** | Risk score | "Is the payoff asymmetric—small investment to prevent, catastrophic cost if realized?" |
|
||||
| **Stress-to-Signal** | Lessons learned | "If this risk materializes, what structural improvement must result?" |
|
||||
| **T0 Classification** | Criticality | "Is this existential (T0), major (T1), significant (T2), or standard (T3)?" |
|
||||
|
||||
---
|
||||
|
||||
## Risk Register Template
|
||||
|
||||
### Metadata
|
||||
|
||||
```
|
||||
Organization: ________________________________
|
||||
Assessment Date: ________________________________
|
||||
Assessor: ________________________________
|
||||
Review Cadence: Monthly / Quarterly
|
||||
Next Review Date: ________________________________
|
||||
```
|
||||
|
||||
### Risk Entries
|
||||
|
||||
| Field | Description | Example |
|
||||
|-------|-------------|---------|
|
||||
| **Risk ID** | Unique identifier (e.g., AF-2024-001) | AF-2024-001 |
|
||||
| **Risk Name** | Short, specific description | Domain Admin Account Compromise |
|
||||
| **Description** | Detailed scenario | A standing Domain Admin account is compromised via phishing, allowing adversary to create persistent access and exfiltrate data |
|
||||
| **T0 / T1 / T2 / T3** | Tier classification | T0 |
|
||||
| **Kill Chain Position** | Shortest path to failure | Direct: compromised admin → full domain takeover → all systems compromised |
|
||||
| **Probability** | Likelihood (1-5) | 4 (High: admin accounts are high-value phishing targets) |
|
||||
| **Impact** | Consequence (1-5) | 5 (Existential: total organizational compromise) |
|
||||
| **Traditional Risk Score** | P × I | 20 (Critical) |
|
||||
| **Optionality Impact** | Does this remove strategic options? | High: if AD is compromised, migration to cloud-native identity becomes impossible until recovery |
|
||||
| **Convexity** | Asymmetric payoff? | Extreme: MFA deployment costs €0 (E3); domain compromise costs €500K+ |
|
||||
| **Current Control** | What exists today? | Password policy; no MFA on admin accounts; no PIM |
|
||||
| **Antifragile Move** | What structural change is required? | 1. Remove standing Domain Admin assignments 2. Deploy PIM (or manual JIT process) 3. Enforce MFA with hardware tokens 4. Deploy PAWs for all admin activity |
|
||||
| **Owner** | Who is accountable? | CISO |
|
||||
| **Target Date** | When must this be addressed? | 14 days |
|
||||
| **Status** | Open / In Progress / Closed / Accepted / Transferred | Open |
|
||||
| **Stress-to-Signal Mandate** | If this risk materializes, what must change? | Post-incident: all admin activity permanently moved to PAWs; quarterly access reviews institutionalized; admin accounts reduced to minimum viable count |
|
||||
| **Verification Method** | How do we prove the fix works? | Monthly PIM audit; quarterly red team targeting admin credentials; Secure Score admin control metric |
|
||||
|
||||
---
|
||||
|
||||
## Risk Categories (Antifragile Taxonomy)
|
||||
|
||||
### Category 1: Sovereignty Risks
|
||||
|
||||
Risks related to loss of control over data, intelligence, or infrastructure.
|
||||
|
||||
| Risk | Kill Chain | T0? | Antifragile Move |
|
||||
|------|-----------|-----|-----------------|
|
||||
| Proprietary data trains competitor AI models | Data → cloud AI → model improvement → competitive erosion | Yes | Deploy local or Azure OpenAI with data protection guarantees; classify AI data flows |
|
||||
| Cloud vendor changes terms or pricing | Terms change → operational disruption → forced migration under duress | Yes | Document exit architecture; maintain data portability; dual-vendor readiness |
|
||||
| Vendor discontinues critical service | Service ends → workflow collapse → emergency procurement | T1 | Maintain abstraction layers; escrow agreements; 90-day exit plans |
|
||||
|
||||
### Category 2: Identity Risks
|
||||
|
||||
Risks related to authentication, authorization, and account lifecycle.
|
||||
|
||||
| Risk | Kill Chain | T0? | Antifragile Move |
|
||||
|------|-----------|-----|-----------------|
|
||||
| Standing privileged account compromise | Phish → admin account → lateral movement → domain takeover | Yes | Eliminate standing privileges; deploy PIM or manual JIT; PAWs |
|
||||
| Orphaned account resurrection | Former employee account not disabled → credential sale → unauthorized access | T1 | Automated orphan detection; quarterly access reviews; offboarding workflow tied to HR |
|
||||
| MFA bypass via legacy authentication | Legacy protocol → password spray → account access without MFA | T1 | Block legacy auth tenant-wide; monitor for legacy auth attempts |
|
||||
|
||||
### Category 3: Resilience Risks
|
||||
|
||||
Risks related to the organization's ability to survive and recover from failure.
|
||||
|
||||
| Risk | Kill Chain | T0? | Antifragile Move |
|
||||
|------|-----------|-----|-----------------|
|
||||
| Backups unrecoverable | Ransomware → backup failure → data loss → business termination | Yes | Quarterly recovery drills; immutable backups; tested runbooks |
|
||||
| Single point of failure in critical system | Component failure → cascade → service outage | T1 | Chaos engineering; redundancy; graceful degradation design |
|
||||
| Untested disaster recovery plan | Incident → DR plan fails → extended outage → regulatory fine | T1 | Quarterly DR drills; documented and practiced runbooks; automated failover where possible |
|
||||
|
||||
### Category 4: Organizational Risks
|
||||
|
||||
Risks related to structure, culture, and process.
|
||||
|
||||
| Risk | Kill Chain | T0? | Antifragile Move |
|
||||
|------|-----------|-----|-----------------|
|
||||
| Security team as gatekeeper, not enabler | Security blocks releases → development bypasses controls → shadow IT proliferation | T1 | Embed security in teams; shared metrics; automated security gates in CI/CD |
|
||||
| Knowledge concentrated in single individual | Key person departure → operational paralysis → recovery delay | T1 | Cross-training; runbook documentation; bus factor > 1 for all critical functions |
|
||||
| Incident findings not converted to structure | Incident occurs → post-mortem written → no changes made → repeat incident | T1 | Blameless post-mortems with structural mandates; mean-time-to-structural-fix metric |
|
||||
|
||||
### Category 5: AI-Specific Risks
|
||||
|
||||
Risks introduced by artificial intelligence adoption.
|
||||
|
||||
| Risk | Kill Chain | T0? | Antifragile Move |
|
||||
|------|-----------|-----|-----------------|
|
||||
| Prompt injection on business-critical AI workflow | Malicious input → AI generates harmful output → business decision based on bad data | T1 | Input validation; output filtering; human-in-the-loop for critical decisions |
|
||||
| AI model poisoning via training data | Adversarial training data → model behaviour change → security control failure | Yes | Data provenance tracking; training data validation; model integrity monitoring |
|
||||
| Shadow AI usage leaks crown jewels | Employee uses public AI → proprietary data exfiltrated → competitive disadvantage | Yes | Sanctioned AI alternative (Azure OpenAI bridge); DLP monitoring; user education |
|
||||
|
||||
---
|
||||
|
||||
## The Kill Chain Risk Register
|
||||
|
||||
For the highest-priority risks, map the full kill chain:
|
||||
|
||||
```
|
||||
RISK ID: ________________
|
||||
RISK NAME: ________________
|
||||
|
||||
KILL CHAIN ANALYSIS:
|
||||
Step 1 (Initial Access): ________________________________________________
|
||||
Step 2 (Persistence): ________________________________________________
|
||||
Step 3 (Privilege Escalation): ________________________________________________
|
||||
Step 4 (Lateral Movement): ________________________________________________
|
||||
Step 5 (Impact): ________________________________________________
|
||||
|
||||
SHORTEST PATH TO FAILURE: _____ steps
|
||||
CRITICAL NODE (break the chain here): ___________________________________
|
||||
|
||||
ANTIFRAGILE MOVE AT CRITICAL NODE: _____________________________________
|
||||
VERIFICATION: __________________________________________________________
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Scoring and Prioritization
|
||||
|
||||
### Traditional Score
|
||||
|
||||
```
|
||||
Risk Score = Probability (1-5) × Impact (1-5)
|
||||
```
|
||||
|
||||
| Score | Priority |
|
||||
|-------|----------|
|
||||
| 20-25 | P0 — Address within 14 days |
|
||||
| 15-19 | P1 — Address within 30 days |
|
||||
| 10-14 | P2 — Address within 90 days |
|
||||
| 5-9 | P3 — Address within 180 days |
|
||||
| 1-4 | P4 — Monitor and schedule |
|
||||
|
||||
### Antifragile Score (Supplemental)
|
||||
|
||||
```
|
||||
Antifragile Priority = Traditional Score + Optionality Impact (0-5) + Convexity (0-5)
|
||||
```
|
||||
|
||||
Risks that remove optionality or have extreme convexity receive elevated priority even if traditional probability is moderate.
|
||||
|
||||
| Antifragile Score | Interpretation |
|
||||
|-------------------|----------------|
|
||||
| 30+ | Existential + optionality-destroying. Address immediately. |
|
||||
| 25-29 | High risk with structural implications. Address within 30 days. |
|
||||
| 20-24 | Significant risk. Address within standard timeline. |
|
||||
| < 20 | Manage through existing controls. |
|
||||
|
||||
---
|
||||
|
||||
## Review and Governance
|
||||
|
||||
### Monthly Tactical Review
|
||||
|
||||
- Open risks: status, blockers, escalation needs
|
||||
- Closed risks: verification that controls are working
|
||||
- New risks: emerging from incidents, changes, or threat intelligence
|
||||
|
||||
### Quarterly Strategic Review
|
||||
|
||||
- Risk trend: Are we reducing existential risks faster than new ones emerge?
|
||||
- Kill chain coverage: Are there unprotected paths we have not mapped?
|
||||
- Optionality audit: Have any changes reduced our strategic flexibility?
|
||||
- Stress-to-signal conversion: How many incidents produced structural improvements?
|
||||
|
||||
### Annual Board Review
|
||||
|
||||
- Risk register summary: T0 risks, open vs. closed, trend
|
||||
- Kill chain assurance: Independent validation of critical node protection
|
||||
- Antifragile maturity: Mean time to structural fix, chaos experiment results, recovery drill outcomes
|
||||
|
||||
---
|
||||
|
||||
## Integration With Other Documents
|
||||
|
||||
| Document | Integration |
|
||||
|----------|-------------|
|
||||
| [T0 Asset Framework](../core/t0-asset-framework.md) | T0 classification determines which risks are existential |
|
||||
| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Phase priorities map directly to P0/P1/P2 risk closure |
|
||||
| [C-Suite Conversation Guide](../core/c-suite-conversation-guide.md) | Risk register produces the "cost of inaction" narrative |
|
||||
| [Business Case Template](../playbooks/business-case-template.md) | Risk scores convert to expected financial loss |
|
||||
|
||||
---
|
||||
|
||||
*For the M365-specific risk register, see [M365 Project Risk Register](m365-project-risk-register.md).*
|
||||
@@ -0,0 +1,170 @@
|
||||
# M365 Project Risk Register
|
||||
|
||||
> *"Most M365 projects fail not because Teams does not work, but because governance was an afterthought and the tenant became an ungovernable monoculture."*
|
||||
|
||||
This risk register applies the antifragile risk methodology specifically to Microsoft 365 projects—greenfield deployments, tenant modernisations, migrations, and consolidations. It is designed for M365/Azure consultancies to identify, classify, and mitigate project-specific risks before they become tenant-wide liabilities.
|
||||
|
||||
---
|
||||
|
||||
## M365-Specific Risk Taxonomy
|
||||
|
||||
### Category 1: Identity and Access Risks
|
||||
|
||||
| Risk ID | Risk Name | Description | T0/T1/T2 | Kill Chain | Antifragile Move | Owner |
|
||||
|---------|-----------|-------------|----------|-----------|-----------------|-------|
|
||||
| M365-001 | Excessive Global Admins | More than 3-5 Global Admins with standing access | T0 | Compromise any admin → full tenant control → data exfiltration / deletion | Reduce to minimum; deploy PIM; use delegated roles | Identity Team |
|
||||
| M365-002 | No MFA on Admin Accounts | Admin accounts lack multi-factor authentication | T0 | Phish password → direct tenant access → no second factor to stop | Enforce MFA for all admins; hardware tokens for break-glass | Security |
|
||||
| M365-003 | Legacy Authentication Enabled | Legacy auth protocols allow MFA bypass | T1 | Password spray via IMAP/POP3/SMTP → account access without MFA | Block legacy auth tenant-wide; monitor for attempts | Security |
|
||||
| M365-004 | Stale Guest Accounts | Former partners/vendors retain guest access indefinitely | T1 | Stale guest → credential compromise → Teams/SharePoint access | Quarterly guest access review; time-bounded invitations | Collaboration Team |
|
||||
| M365-005 | Unmanaged OAuth Consents | Users granted permissions to unauthorized applications | T1 | Malicious app → mailbox access / data exfiltration / phishing | Disable user consent; admin consent workflow; quarterly audit | Security |
|
||||
| M365-006 | Shared Mailboxes with Login | Shared mailboxes configured with user passwords and sign-in enabled | T2 | Shared credential compromise → email access → BEC / data theft | Disable sign-in on shared mailboxes; convert to proper delegation | Exchange Team |
|
||||
| M365-007 | No Conditional Access (E5/P1) | Missing location, device, or risk-based access controls | T1 | Compromised credentials usable from any device, any location | Deploy conditional access: MFA, device compliance, location, risk | Identity Team |
|
||||
| M365-008 | Hybrid Identity Stuck | AAD Connect configured with no plan to migrate to cloud-native | T1 | AAD Connect compromise → cloud identity manipulation → tenant takeover | Document cloud-native migration path; secure AAD Connect server | Identity Team |
|
||||
|
||||
### Category 2: Data Governance Risks
|
||||
|
||||
| Risk ID | Risk Name | Description | T0/T1/T2 | Kill Chain | Antifragile Move | Owner |
|
||||
|---------|-----------|-------------|----------|-----------|-----------------|-------|
|
||||
| M365-009 | No Data Classification | Documents and emails stored without sensitivity labels | T1 | Proprietary/confidential data mixed with public data → uncontrolled sharing → leakage | Deploy sensitivity labels (Purview) or manual classification guidance | Compliance |
|
||||
| M365-010 | Open External Sharing | SharePoint/OneDrive default allows anyone-links or external sharing | T1 | Accidental or malicious public link → data exposure → regulatory fine / reputational damage | Default sharing: internal only; anyone-links disabled; per-site justification | SharePoint Team |
|
||||
| M365-011 | No Retention Policy | No defined retention for email, Teams, or files; data accumulates indefinitely | T2 | Excessive data → discovery cost → compliance failure → inability to respond to legal hold | Deploy retention policies for all workloads; legal hold procedures | Compliance |
|
||||
| M365-012 | Teams Channel Sprawl | Uncontrolled team creation; stale teams with sensitive data | T2 | Stale team with external access → forgotten but accessible → data leakage | Governed team creation; expiration policies; access reviews | Collaboration Team |
|
||||
| M365-013 | OneDrive as Shadow IT | Users store business-critical data in personal OneDrive without backup | T1 | User departure / account deletion → data loss; no organizational recovery | Migrate business data to SharePoint; backup strategy; user education | SharePoint Team |
|
||||
| M365-014 | Copilot Without Governance | Microsoft 365 Copilot deployed without data governance baseline | T0 | Copilot surfaces sensitive data to unauthorized users → internal data breach | Deploy sensitivity labels BEFORE Copilot; conditional access; user training | Security / Compliance |
|
||||
| M365-015 | eDiscovery Unprepared | No eDiscovery processes, legal hold capability, or retention for litigation | T2 | Litigation → inability to produce documents → adverse inference / sanctions | eDiscovery training; retention hold procedures; Purview eDiscovery licensing | Legal / Compliance |
|
||||
|
||||
### Category 3: Security and Threat Risks
|
||||
|
||||
| Risk ID | Risk Name | Description | T0/T1/T2 | Kill Chain | Antifragile Move | Owner |
|
||||
|---------|-----------|-------------|----------|-----------|-----------------|-------|
|
||||
| M365-016 | Business Email Compromise (BEC) | Executive mailbox compromised; fraudulent payment instructions sent | T1 | Phish executive → mailbox control → invoice fraud / wire transfer | Impersonation protection; mailbox auditing; MFA; financial process verification | Security |
|
||||
| M365-017 | EOP Misconfiguration | Basic Exchange Online Protection not tuned for client's threat profile | T1 | Phishing email reaches inbox → user compromise → lateral movement | Tune anti-phishing, anti-malware, anti-spam; impersonation protection | Security |
|
||||
| M365-018 | No Audit Logging | Unified Audit Log disabled or unmonitored | T1 | Incident occurs → no forensic evidence → cannot determine scope or contain | Enable UAL immediately; forward to SIEM; 90-day minimum retention | Security |
|
||||
| M365-019 | Device Unmanaged | Corporate devices accessing M365 without MDM or compliance policy | T1 | Compromised personal device → M365 access → data exfiltration | Intune enrollment; conditional access requiring compliance | Endpoint Team |
|
||||
| M365-020 | No Backup Beyond Native | Reliance on recycle bin and soft delete as "backup" | T1 | Ransomware / malicious admin / sync error → data loss → no recovery | Third-party immutable backup; quarterly recovery testing | Backup Team |
|
||||
|
||||
### Category 4: AI and Emerging Technology Risks
|
||||
|
||||
| Risk ID | Risk Name | Description | T0/T1/T2 | Kill Chain | Antifragile Move | Owner |
|
||||
|---------|-----------|-------------|----------|-----------|-----------------|-------|
|
||||
| M365-021 | Shadow AI via M365 Apps | Employees paste proprietary data into Copilot, Bing, or third-party AI through browser | T0 | Proprietary data → public AI model → competitive intelligence loss | Deploy Azure OpenAI bridge; DLP policies blocking AI uploads; user education | Security |
|
||||
| M365-022 | Copilot Data Overexposure | Copilot synthesizes and surfaces data the user should not have access to | T1 | Overpermissioned user → Copilot reveals sensitive synthesis → internal breach | Zero-trust permissions review; sensitivity labels; just-in-time access | Security |
|
||||
| M365-023 | AI-Generated Misinformation | Users make business decisions based on unverified AI-generated content | T2 | AI hallucination → bad decision → financial loss / compliance failure | Human-in-the-loop for critical decisions; source attribution requirements; user training | Compliance |
|
||||
| M365-024 | No AI Governance Policy | Organization has no policy for approved AI tools, data handling, or vendor evaluation | T1 | Uncontrolled AI adoption → data leakage → regulatory / legal exposure | AI governance framework; approved tool list; data classification for AI inputs | Security / Legal |
|
||||
|
||||
### Category 5: Project and Organizational Risks
|
||||
|
||||
| Risk ID | Risk Name | Description | T0/T1/T2 | Kill Chain | Antifragile Move | Owner |
|
||||
|---------|-----------|-------------|----------|-----------|-----------------|-------|
|
||||
| M365-025 | Tenant as Monoculture | All data, identity, and collaboration in one tenant with no exit architecture | T0 | Tenant compromise / lockout / vendor change → total organizational paralysis | Domain ownership by client; data portability architecture; documented tenant exit | Architecture |
|
||||
| M365-026 | Scope Creep Without Governance | Workloads deployed incrementally without security review | T2 | New app/service → unmapped risk → incident | Governance gate before new workload; security review checklist | Project Manager |
|
||||
| M365-027 | Insufficient Admin Training | Client team lacks skills to operate and secure the tenant post-handover | T2 | Misconfiguration → vulnerability → incident | Structured training program; runbook documentation; knowledge transfer sessions | Training |
|
||||
| M365-028 | Power Platform Shadow IT | Citizen developers create apps and flows with ungoverned data access | T1 | Unmanaged flow → external data sharing / credential exposure → breach | DLP policies; environment governance; citizen developer training | Power Platform Team |
|
||||
| M365-029 | Migration Data Loss | Legacy data lost or corrupted during migration to M365 | T1 | Corrupted migration → missing records → compliance / operational failure | Pre-migration backup; validation sampling; rollback plan | Migration Team |
|
||||
| M365-030 | Vendor Lock-in via Add-ons | Heavy reliance on third-party M365 add-ins that create dependency | T2 | Add-on vendor discontinues / changes terms → workflow collapse | Evaluate add-ons for portability; maintain native fallback; contractual exit clauses | Procurement |
|
||||
|
||||
---
|
||||
|
||||
## Risk Scoring for M365 Projects
|
||||
|
||||
### Probability Scale
|
||||
|
||||
| Score | Definition | M365 Example |
|
||||
|-------|-----------|--------------|
|
||||
| 1 | Rare (< 1% annually) | Total Azure region failure |
|
||||
| 2 | Unlikely (1-10%) | Major zero-day in Exchange Online |
|
||||
| 3 | Possible (10-50%) | Successful phishing campaign against users |
|
||||
| 4 | Likely (50-90%) | Stale guest account remains accessible |
|
||||
| 5 | Almost certain (> 90%) | Shadow AI usage if no sanctioned alternative |
|
||||
|
||||
### Impact Scale
|
||||
|
||||
| Score | Definition | M365 Example |
|
||||
|-------|-----------|--------------|
|
||||
| 1 | Negligible | Minor inconvenience; no data loss |
|
||||
| 2 | Minor | Single user/service affected; recoverable in hours |
|
||||
| 3 | Moderate | Departmental impact; recoverable in days; potential compliance notice |
|
||||
| 4 | Major | Organizational impact; recoverable in weeks; regulatory fine likely |
|
||||
| 5 | Catastrophic | Existential threat; business termination possible; criminal liability |
|
||||
|
||||
### M365-Specific Convexity Assessment
|
||||
|
||||
| Convexity | Definition | M365 Example |
|
||||
|-----------|-----------|--------------|
|
||||
| **Extreme** | €0 control prevents €500K+ loss | Enabling MFA (free in E3) prevents total tenant compromise |
|
||||
| **High** | Small labor investment prevents major incident | Quarterly guest access review prevents data breach via stale account |
|
||||
| **Moderate** | Moderate investment prevents significant loss | Third-party backup prevents data loss from ransomware |
|
||||
| **Low** | Investment comparable to potential loss | Advanced threat protection add-on vs. basic EOP |
|
||||
|
||||
---
|
||||
|
||||
## Project Phase Risk Gates
|
||||
|
||||
### Greenfield Deployment Gates
|
||||
|
||||
| Phase | Gate | Risk Closure Requirement |
|
||||
|-------|------|-------------------------|
|
||||
| **Architecture** | Go/No-Go before provisioning | M365-025 (tenant monoculture) assessed and mitigated; M365-030 (add-on lock-in) evaluated |
|
||||
| **Foundation** | Go/No-Go before user onboarding | M365-001 (excessive admins), M365-002 (no MFA), M365-018 (no audit) closed |
|
||||
| **Workload Rollout** | Go/No-Go per workload | M365-009 (no classification), M365-010 (open sharing), M365-028 (Power Platform) addressed |
|
||||
| **Go-Live** | Go/No-Go before production | M365-016 (BEC), M365-017 (EOP), M365-020 (no backup) mitigated; M365-027 (training) completed |
|
||||
| **30-Day Post** | Review | M365-021 (shadow AI) inventoried; M365-024 (AI governance) drafted |
|
||||
|
||||
### Modernisation Gates
|
||||
|
||||
| Phase | Gate | Risk Closure Requirement |
|
||||
|-------|------|-------------------------|
|
||||
| **Audit** | Complete before changes | All 30 risks assessed; T0 and T1 risks prioritized |
|
||||
| **Kill Chain Closure** | Day 30 checkpoint | All T0 risks closed or accepted with board sign-off |
|
||||
| **Governance Deployment** | Day 60 checkpoint | All T1 identity and data risks closed |
|
||||
| **Sovereignty** | Day 90 checkpoint | M365-021 (shadow AI) mitigated via sanctioned alternative; M365-020 (backup) tested |
|
||||
| **Antifragility** | Day 180 checkpoint | Automated monitoring for M365-003, M365-005, M365-010; quarterly review cadence established |
|
||||
|
||||
---
|
||||
|
||||
## The M365 Risk Dashboard (For Steering Committee)
|
||||
|
||||
```
|
||||
M365 PROJECT RISK DASHBOARD — [Client] — [Date]
|
||||
|
||||
T0 RISKS (Existential)
|
||||
├─ Open: [X] ├─ In Progress: [X] └─ Closed: [X]
|
||||
├─ [Risk ID] [Name] — Owner: [Name] — Target: [Date]
|
||||
└─ [Risk ID] [Name] — Owner: [Name] — Target: [Date]
|
||||
|
||||
T1 RISKS (Major)
|
||||
├─ Open: [X] ├─ In Progress: [X] └─ Closed: [X]
|
||||
├─ [Risk ID] [Name] — Owner: [Name] — Target: [Date]
|
||||
└─ [Risk ID] [Name] — Owner: [Name] — Target: [Date]
|
||||
|
||||
IDENTITY & ACCESS [████░░░░░░] [X]% mitigated
|
||||
DATA GOVERNANCE [██████░░░░] [X]% mitigated
|
||||
SECURITY & THREATS [█████░░░░░] [X]% mitigated
|
||||
AI & EMERGING TECH [███░░░░░░░] [X]% mitigated
|
||||
PROJECT & ORGANIZATIONAL [███████░░░] [X]% mitigated
|
||||
|
||||
TOP 3 RISKS REQUIRING ESCALATION
|
||||
1. [Risk ID] — [Reason for escalation]
|
||||
2. [Risk ID] — [Reason for escalation]
|
||||
3. [Risk ID] — [Reason for escalation]
|
||||
|
||||
RECOMMENDATION: [Proceed / Pause / Escalate]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration With Project Deliverables
|
||||
|
||||
| Deliverable | Risk Register Integration |
|
||||
|------------|--------------------------|
|
||||
| **Project charter** | Include T0 risk identification as success criterion |
|
||||
| **Architecture document** | Map each design decision to risk mitigation |
|
||||
| **Configuration baselines** | Reference risk IDs in change justification |
|
||||
| **Test plan** | Include recovery drills for M365-020; penetration testing for M365-016 |
|
||||
| **Training plan** | Address M365-027; include AI governance for M365-024 |
|
||||
| **Handover document** | Transfer risk ownership to client team with review cadence |
|
||||
|
||||
---
|
||||
|
||||
*For the general antifragile risk register methodology, see [Antifragile Risk Register](antifragile-risk-register.md).*
|
||||
*For the M365 antifragile project playbook, see [M365 Antifragile Project](../playbooks/m365-antifragile-project.md).*
|
||||
Reference in New Issue
Block a user