# AEGIS SENTINEL: Incident Post-Mortem Template
**Classification:** Sovereign Evidence Record | **Submit to:** Bank of Uganda (BoU) / NITA-U

---

## Document Purpose

This is not just a "lessons learned" document—it is a formal **Sovereign Evidence Record** for regulatory submission. Following this template demonstrates **Operational Maturity** to Series A investors and national regulators.

---

## Incident Header

| Field | Value |
|-------|-------|
| **Incident ID** | [e.g., AEGIS-2026-01-24-SOC] |
| **Severity** | [ ] L1 - Critical [ ] L2 - High [ ] L3 - Moderate |
| **Status** | [ ] DRAFT [ ] REVIEWED [ ] SUBMITTED TO REGULATOR |
| **Date/Time** | [YYYY-MM-DD HH:MM EAT] |
| **Duration** | [Total incident duration] |
| **Incident Commander** | [Name] |
| **Post-Mortem Author** | [Name] |
| **Review Date** | [Date of review meeting] |

---

## 1. Executive Summary (The "TL;DR")

*Provide a 3-sentence summary of what happened, the impact, and the resolution.*

**Template:**
> On [Date], at [Time], a [Type of Attack/Failure] triggered the [Gulu Protocol/Sovereign Switch/Kill-Switch]. This impacted [X%] of users for [Duration]. Service was fully restored by [Action taken], with no data loss/breach confirmed.

**Example:**
> On January 15, 2026, at 02:34 EAT, a sophisticated DDoS attack targeting our KYC API triggered the Ghost Mesh deception layer. This impacted 3% of users for 47 minutes. Service was fully restored after traffic was absorbed by the Ghost Mesh and malicious IPs were permanently blocked, with no data breach confirmed.

---

## 2. Timeline of Events (The Truth Chain)

*Detailed, time-stamped log of detection, response, and recovery.*

| Time (EAT) | Event Type | Action / Event | Actor |
|------------|------------|----------------|-------|
| 00:00 | DETECTION | Sentinel Brain flagged anomaly in [Region/System] | System |
| 00:05 | TRIAGE | SRE On-call confirmed [Attack Type/Failure Mode] | [Name] |
| 00:07 | ESCALATION | Paged SRE Lead and CISO | System |
| 00:10 | WAR ROOM | Incident War Room opened | IC: [Name] |
| 00:12 | MITIGATION | [First mitigation action taken] | [Team] |
| 00:25 | MITIGATION | [Second mitigation action taken] | [Team] |
| 00:45 | RESOLUTION | Root cause identified and patched | Dev Team |
| 00:47 | VERIFICATION | Smoke tests passed, service stable | SRE Team |
| 01:00 | CLOSURE | Incident declared resolved | IC |

---

## 3. Root Cause Analysis (The "5 Whys")

*Avoid blaming individuals. Focus on system failures and process gaps.*

### Primary Analysis

| Why # | Question | Finding |
|-------|----------|---------|
| 1 | Why did the service fail? | [e.g., The database was overwhelmed] |
| 2 | Why was it overwhelmed? | [e.g., A surge in malicious requests] |
| 3 | Why didn't the filter catch them? | [e.g., A new variant of social engineering] |
| 4 | Why was the variant unknown? | [e.g., Training data lacked this regional dialect] |
| 5 | Why was training data incomplete? | [e.g., No feedback loop from recent incidents] |

### Root Cause Statement

> **Root Cause:** [One-sentence summary of the fundamental cause]
>
> *Example: A gap in the regional NLP training shard for the Sentinel Brain allowed a new Luganda-variant phishing pattern to bypass initial detection.*

### Contributing Factors

| Factor | Category | Severity |
|--------|----------|----------|
| [Factor 1] | Process / Technology / People | High / Medium / Low |
| [Factor 2] | Process / Technology / People | High / Medium / Low |
| [Factor 3] | Process / Technology / People | High / Medium / Low |

---

## 4. Regulatory & Data Impact (BoU/NITA-U Compliance)

*This section is mandatory for the 2026 Sovereign Audit.*

### Data Residency Assessment

| Question | Answer | Evidence |
|----------|--------|----------|
| Did any PII leave Uganda during the incident? | [ ] YES [ ] NO | [Log reference] |
| Was data encrypted in transit at all times? | [ ] YES [ ] NO | [Log reference] |
| Were any customer records exposed? | [ ] YES [ ] NO | [Forensic report] |
| Did the Sovereign Switch function as designed? | [ ] YES [ ] NO [ ] N/A | [Drill log] |

### Regulatory Notification Status

| Requirement | Deadline | Status | Date Completed |
|-------------|----------|--------|----------------|
| Internal Assessment | T+24h | [ ] Complete | [Date] |
| BoU Notification (if required) | T+72h | [ ] Complete [ ] N/A | [Date] |
| NITA-U Notification (if required) | T+72h | [ ] Complete [ ] N/A | [Date] |
| Customer Notification (if required) | T+72h | [ ] Complete [ ] N/A | [Date] |
| FIA SAR Filing (if suspicious activity) | T+24h | [ ] Complete [ ] N/A | [SAR ID] |

### PDPO 2019 Compliance Checklist

- [ ] Breach severity assessed per Section 23
- [ ] Data Protection Officer notified
- [ ] Affected data subjects identified (if applicable)
- [ ] Notification decision documented
- [ ] Remediation measures implemented

---

## 5. Impact Assessment

### Customer Impact

| Metric | Value |
|--------|-------|
| Total users affected | [Number] |
| Percentage of user base | [X%] |
| Transactions delayed | [Number] |
| Transactions failed | [Number] |
| Failed KYC verifications | [Number] |
| Customer complaints received | [Number] |

### Financial Impact

| Category | Amount (UGX) | Notes |
|----------|--------------|-------|
| Lost revenue | [Amount] | [Calculation basis] |
| Remediation costs | [Amount] | [Engineering hours, etc.] |
| Customer compensation | [Amount] | [If applicable] |
| Regulatory fines | [Amount] | [If applicable] |
| **Total** | [Amount] | |

### Reputation Impact

| Channel | Mentions | Sentiment |
|---------|----------|-----------|
| Social Media | [Count] | Positive / Neutral / Negative |
| News Coverage | [Count] | Positive / Neutral / Negative |
| Customer Support | [Tickets] | [Summary] |

---

## 6. Detection & Response Evaluation

### Detection Performance

| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Time to Detect (TTD) | < 5 min | [Actual] | [ ] Met [ ] Missed |
| Time to Escalate (TTE) | < 10 min | [Actual] | [ ] Met [ ] Missed |
| Time to Mitigate (TTM) | < 30 min | [Actual] | [ ] Met [ ] Missed |
| Time to Resolve (TTR) | < 2 hours | [Actual] | [ ] Met [ ] Missed |

### What Went Well

| # | Observation |
|---|-------------|
| 1 | [e.g., Sentinel Brain detected anomaly within 30 seconds] |
| 2 | [e.g., Ghost Mesh successfully absorbed 99% of attack traffic] |
| 3 | [e.g., War Room mobilized in under 5 minutes] |

### What Could Be Improved

| # | Observation | Owner |
|---|-------------|-------|
| 1 | [e.g., NLP training data needs regional expansion] | ML Team |
| 2 | [e.g., Runbook for this scenario was outdated] | SRE Team |
| 3 | [e.g., Customer communication was delayed] | Comms Team |

---

## 7. Corrective Actions

### Immediate Actions (Completed)

| Action | Owner | Completed Date |
|--------|-------|----------------|
| [e.g., Blocked malicious IP range] | SRE | [Date] |
| [e.g., Deployed emergency patch] | Dev | [Date] |
| [e.g., Increased monitoring thresholds] | SRE | [Date] |

### Short-Term Actions (30 Days)

| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [e.g., Update NLP training with new patterns] | ML Team | [Date] | [ ] Open |
| [e.g., Update operational playbook] | SRE | [Date] | [ ] Open |
| [e.g., Customer outreach for affected users] | Comms | [Date] | [ ] Open |

### Long-Term Actions (90 Days)

| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [e.g., Implement automated pattern feedback loop] | Engineering | [Date] | [ ] Open |
| [e.g., Regional NLP model retraining] | ML Team | [Date] | [ ] Open |
| [e.g., Quarterly drill for this scenario] | SRE | [Date] | [ ] Open |

---

## 8. Lessons Learned

### Technical Lessons

| Lesson | Recommendation |
|--------|----------------|
| [e.g., Regional attack patterns differ from global] | Maintain separate NLP shards per dialect |
| [e.g., Ghost Mesh absorption capacity was tested] | Current capacity is sufficient; document baseline |

### Process Lessons

| Lesson | Recommendation |
|--------|----------------|
| [e.g., Escalation was smooth but comms delayed] | Add automated customer status page updates |
| [e.g., Post-mortem delayed due to incomplete logs] | Implement centralized log aggregation |

### People Lessons

| Lesson | Recommendation |
|--------|----------------|
| [e.g., Night shift SRE handled well under pressure] | Recognize performance in team meeting |
| [e.g., Cross-team coordination took time] | Schedule quarterly cross-team drills |

---

## 9. Sovereign Resilience Validation

*Evidence that AEGIS sovereign features performed as designed.*

### Gulu Protocol Status

| Node | Status During Incident | Sync Lag | Notes |
|------|------------------------|----------|-------|
| GULU-001 (Kampala) | ACTIVE | 0ms | Primary hub |
| GULU-002 (Jinja) | ACTIVE | 12ms | Normal |
| GULU-003 (Mbarara) | ACTIVE | 18ms | Normal |
| GULU-004 (Gulu) | ACTIVE | 45ms | Satellite latency |
| GULU-005 (Mbale) | ACTIVE | 22ms | Normal |
| GULU-006 (Fort Portal) | ACTIVE | 31ms | Normal |

### Sovereign Switch Readiness

| Check | Status |
|-------|--------|
| Local DC replication current | [ ] YES [ ] NO |
| DNS failover tested recently | [ ] YES [ ] NO |
| Exit drill within last quarter | [ ] YES [ ] NO |

### Kill-Switch Status

| Check | Status |
|-------|--------|
| Kill-switch tested during incident | [ ] YES [ ] NO [ ] N/A |
| Safety rails functioned correctly | [ ] YES [ ] NO [ ] N/A |
| Manual override available | [ ] YES [ ] NO |

---

## 10. Attachments & Evidence

### Required Attachments

| Document | Attached | Reference |
|----------|----------|-----------|
| Sentinel Brain alert logs | [ ] YES | [Filename/Link] |
| War Room transcript | [ ] YES | [Filename/Link] |
| Customer communication | [ ] YES | [Filename/Link] |
| Forensic analysis report | [ ] YES | [Filename/Link] |
| Regulatory notification (if applicable) | [ ] YES [ ] N/A | [Filename/Link] |

### Log References

| System | Time Range | Log Location |
|--------|------------|--------------|
| Sentinel Brain | [Start - End] | [Path/Link] |
| Ghost Mesh | [Start - End] | [Path/Link] |
| API Gateway | [Start - End] | [Path/Link] |
| Database | [Start - End] | [Path/Link] |

---

## 11. Approval & Sign-Off

### Review Meeting

| Field | Value |
|-------|-------|
| Date | [Review meeting date] |
| Attendees | [List of attendees] |
| Duration | [Meeting length] |
| Action Items Assigned | [Number] |

### Sign-Off

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Incident Commander | [Name] | __________ | [Date] |
| SRE Lead | [Name] | __________ | [Date] |
| CISO | [Name] | __________ | [Date] |
| CTO | [Name] | __________ | [Date] |
| Data Protection Officer | [Name] | __________ | [Date] |

### Regulatory Submission

| Submission | Date | Reference Number |
|------------|------|------------------|
| Bank of Uganda | [Date] | [Ref #] |
| NITA-U | [Date] | [Ref #] |
| Data Protection Authority | [Date] | [Ref #] |

---

## Document History

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Date] | [Name] | Initial draft |
| 1.1 | [Date] | [Name] | Review comments incorporated |
| 2.0 | [Date] | [Name] | Approved for submission |

---

**END OF POST-MORTEM TEMPLATE**

*This template is a Sovereign Evidence Record. Completed post-mortems must be retained for 7 years per BoU requirements.*