# AEGIS CYBER - IT Handover Suite
## Technical Documentation for Enterprise Integration

**Classification:** HIGHLY CONFIDENTIAL  
**Version:** 4.2.2  
**Last Updated:** 2026-06-09 (see Amendment Notice below)  
**Document Owner:** AEGIS Cyber Security Division

---

> **AUDIENCE NOTE — 2026-06-09:** This document is oriented toward **bank IT operations teams** (incident response, SLA, key management, API integration, DR protocols). For the **internal AEGIS engineering team**, see `docs/AEGIS_CYBER_ENGINEER_ONBOARDING.md` (2026-06-08). For authoritative architecture claims and capability evidence, see `docs/regulatory/AEGIS_CYBER_SECURITY_DOSSIER_FOR_BOU_2026-05-23.md` (updated 2026-06-08).

> **AMENDMENT NOTICE — 2026-06-09:** Three claims in §1 (System Architecture Blueprint) do not reflect current verified state as of June 2026. Operational sections §2–§7 remain current for their purpose (incident response, SLA, API integration, DR protocols) pending bank-IT engagement refresh. The three §1 corrections are:
>
> **1. §1.2 "Real-time replication" (Primary Database → Nairobi DR):** PostgreSQL streaming replication to a Nairobi/Entebbe standby is **NOT YET CONFIGURED** in any deployment environment. The DR architecture is designed and scaffolded; the failover simulation (`dr-failover.ts`) is in-memory only. A DR exercise runbook exists at `docs/regulatory/AEGIS_CYBER_DR_EXERCISE_RUNBOOK.md`; the exercise cannot run until bank IT configures the standby. Correct status: *backup configured (pg_dump to local storage); offsite transfer not yet implemented; streaming replication not yet set up.*
>
> **2. §1.3 "All branch-to-core communications: mTLS 1.3":** Application-layer mutual TLS is **NOT DEPLOYED**. TLS termination is handled at the hosting layer. The integration endpoints listed in §1.4 (Finacle, T24, FLEXCUBE) accept authenticated API calls; mTLS for branch-to-core communication is a deployment-environment integration item, not a currently operational control. Correct status: *hosting-layer TLS; application-layer mTLS not configured.*
>
> **3. §1.3 "Key storage: HSM (Thales Luna or equivalent)":** The HSM integration is a **SOFTWARE SIMULATION** (`server/lib/hsm-integration.ts`, `server/hsmEnclave.ts`). Production encryption uses environment-variable-derived keys (AES-256-GCM via scrypt KDF), not hardware-backed HSM storage. The HSM substitution boundary is documented at `docs/regulatory/AEGIS_CYBER_HSM_BOUNDARY_SPEC.md`. Correct status: *env-var keys (boot-guarded, fail-closed); HSM hardware hookup is a future integration item.*
>
> All other §1 claims (AES-256-GCM field-level encryption for PII and credentials, SHA-256 hash-chained audit logs, three-layer multi-tenant isolation via PostgreSQL RLS) are now **strengthened** relative to January 2026 — these were aspirational at time of writing and are now prod-verified (RLS: 70 tables, 17/17 diagnostic PASS 2026-06-08; PII encryption: 17 tables, 20/20 probe PASS 2026-06-08).

---

# Table of Contents

1. [System Architecture Blueprint](#1-system-architecture-blueprint)
2. [Incident Response Playbook](#2-incident-response-playbook)
3. [SLA & Maintenance Schedule](#3-sla--maintenance-schedule)
4. [Cryptographic Key Management](#4-cryptographic-key-management)
5. [API Integration Guide](#5-api-integration-guide)
6. [Disaster Recovery Protocols](#6-disaster-recovery-protocols)
7. [Appendix: Quick Reference Cards](#7-appendix-quick-reference-cards)

---

# 1. System Architecture Blueprint

## 1.1 High-Level Architecture

```
                                    ┌─────────────────────────────────────┐
                                    │     AEGIS SOVEREIGN COMMAND CENTER  │
                                    │         (Kampala HQ-01 Node)        │
                                    └─────────────────────────────────────┘
                                                      │
                    ┌─────────────────────────────────┼─────────────────────────────────┐
                    │                                 │                                 │
           ┌────────▼────────┐              ┌────────▼────────┐              ┌────────▼────────┐
           │  SENTINEL AI    │              │  BIO-VAULT      │              │  SUPTECH        │
           │  Threat Engine  │              │  Identity Layer │              │  Gateway        │
           │  (Isolation     │              │  (Interaction   │              │  (Regulatory    │
           │   Forest v4.2)  │              │   DNA Tracker)  │              │   Push API)     │
           └────────┬────────┘              └────────┬────────┘              └────────┬────────┘
                    │                                 │                                 │
           ┌────────▼────────┐              ┌────────▼────────┐              ┌────────▼────────┐
           │ Circuit Breaker │              │ Behavioral      │              │ Bank of Uganda  │
           │ + Static        │              │ Biometrics      │              │ SOC Integration │
           │ Fallback        │              │ Engine          │              │                 │
           └────────┬────────┘              └────────┬────────┘              └────────┬────────┘
                    │                                 │                                 │
                    └─────────────────────────────────┼─────────────────────────────────┘
                                                      │
                                    ┌─────────────────▼─────────────────┐
                                    │     CORE BANKING SYSTEM (CBS)     │
                                    │  ┌─────────┐ ┌─────────┐ ┌───────┐│
                                    │  │ Finacle │ │   T24   │ │FLEXCUBE│
                                    │  └─────────┘ └─────────┘ └───────┘│
                                    └───────────────────────────────────┘
```

## 1.2 Sovereign Node Configuration

| Component | Location | Encryption | Backup / Resilience |
|-----------|----------|------------|---------------------|
| Primary Database | Kampala Data Center (Replit prod) | AES-256-GCM at rest (env-var-derived keys, boot-guarded) | pg_dump local; offsite replication not yet configured; streaming replication not yet set up |
| AI Inference Engine | Anthropic Claude API (external hosted) | In-transit TLS to Anthropic | External provider SLA — not bank-hosted |
| Audit Logs | Kampala (Replit prod DB) | SHA-256 chain-linked, immutable append-only | In-DB hash chain; no DR replica or offsite transfer yet configured |
| Session Data | Local memory (server process) | ChaCha20-Poly1305 (design intent; session data in-process) | None (ephemeral — lost on restart) |

## 1.3 Data Flow & Encryption Points

### In Transit
- All branch-to-core communications: **TLS 1.3** (HTTPS via Replit hosting)
- Application-layer **mTLS is not yet deployed** (see §1 Amendment Notice and §4.3). mTLS configuration is the target when bank-IT integration is set up.
- Certificate Authority: Replit-managed TLS certificate (current); bank internal PKI (future, with mTLS)
- Certificate rotation: Replit-managed (current); 90-day rotation procedure in §4.3 (future, with mTLS)

### At Rest
- Database encryption: **AES-256-GCM** (env-var-derived keys via scrypt KDF; boot-guarded at startup)
- Customer PII columns: AES-256-GCM field-level encryption (`server/lib/pii-encryption.ts`); 20/20 prod-verified (ENC-PROBE-1780939715886 2026-06-08)
- Key storage: Environment secrets (boot-guarded) — hardware HSM **not yet connected** (see §4.2)
- Audit logs: SHA-256 hash chain (tamper-evident)

## 1.4 Integration Points

### Finacle Integration
```
Endpoint: /api/webhooks/finacle
Method: POST (mTLS authenticated)
Payload: ISO 20022 format
Events: TRANSACTION_SCORED, THREAT_DETECTED, SESSION_ISOLATED
```

### T24 Integration
```
Endpoint: /api/webhooks/t24
Method: POST (mTLS authenticated)
Payload: Temenos XML format
Events: TRANSACTION_SCORED, THREAT_DETECTED, SESSION_ISOLATED
```

### FLEXCUBE Integration
```
Endpoint: /api/webhooks/flexcube
Method: POST (mTLS authenticated)
Payload: Oracle JSON format
Events: TRANSACTION_SCORED, THREAT_DETECTED, SESSION_ISOLATED
```

---

# 2. Incident Response Playbook

## 2.1 Threat Classification Matrix

| Level | Classification | AEGIS Response | SOC Action | Escalation |
|-------|---------------|----------------|------------|------------|
| L1 | Anomaly | Log + Monitor | Review in daily standup | None |
| L2 | Active Threat | Session Isolation | Immediate investigation | Shift Lead |
| L3 | Critical | System Lockdown | Emergency response | CISO + Vendor |
| L4 | Catastrophic | Full Failover | DR activation | Executive Team |

## 2.2 Level 1: Anomaly Response

**Trigger:** Model drift PSI 0.1-0.25, low-confidence behavioral deviation

**AEGIS Automated Actions:**
1. Log event to audit trail with SHA-256 hash
2. Increment anomaly counter for user/session
3. Add to daily SOC review queue

**SOC Analyst Actions:**
1. Review anomaly details in Command Center
2. Check user's recent activity patterns
3. Document findings in shift log
4. No immediate action required unless pattern repeats

## 2.3 Level 2: Active Threat Response

**Trigger:** High-risk KYT score (AI threat scoring via `POST /api/kyt/analyze` returns elevated risk level); Circuit Breaker OPEN state (AI path unavailable, Static Fallback active)

**AEGIS Automated Actions:**
1. Isolate affected session immediately
2. Block source IP (add to blocklist)
3. Generate threat record with evidence
4. Alert SOC dashboard with CRITICAL priority

**SOC Analyst Actions:**
```
┌─────────────────────────────────────────────────────────────────┐
│ ACTIVE THREAT RESPONSE CHECKLIST                                │
├─────────────────────────────────────────────────────────────────┤
│ □ Acknowledge alert within 60 seconds                           │
│ □ Verify session isolation completed                            │
│ □ Review threat detail in AEGIS Command Center dashboard        │
│ □ Check for lateral movement indicators                         │
│ □ Document attacker TTPs in incident log                        │
│ □ Notify Shift Lead if attack pattern is novel                  │
│ □ Update threat intelligence feed                               │
└─────────────────────────────────────────────────────────────────┘
```

## 2.4 Level 3: System Failure Response

**Trigger:** Circuit Breaker OPEN (AI inference failures exceed threshold), Database connection failure

**AEGIS Automated Actions:**
1. Trip Circuit Breaker to OPEN state
2. Activate Static Fallback rules (zero-AI mode)
3. Continue processing with rule-based risk thresholds
4. Alert CISO

**Static Fallback Rules (Active When AI Circuit is OPEN) — verified against `server/lib/static-fallback.ts`:**

| Rule ID | Condition | Action |
|---------|-----------|--------|
| RULE_001 | Single transaction > UGX 10,000,000 | BLOCK + manual review flag |
| RULE_002 | User daily total > UGX 50,000,000 | BLOCK + manual review flag |
| RULE_003 | Transfer to sanctioned country (KP, IR, SY, CU, VE, MM, BY, RU, ZW) | BLOCK + manual review flag |
| RULE_004 | Transaction > UGX 5,000,000 during restricted hours (00:00–05:00) | BLOCK + manual review flag |

> **⚠ Operational note:** Daily velocity totals (RULE_002) are tracked in-memory and reset on process restart. For 24/7 guaranteed enforcement across restarts, confirm with AEGIS engineering whether a DB-backed persistence layer is configured for your deployment.

**SOC Analyst Actions:**
```
┌─────────────────────────────────────────────────────────────────┐
│ SYSTEM FAILURE RESPONSE PROTOCOL                                │
├─────────────────────────────────────────────────────────────────┤
│ □ Confirm Static Fallback is ACTIVE (green indicator)           │
│ □ Check Circuit Breaker status for all integrations             │
│ □ Monitor held transactions queue                               │
│ □ Prepare for manual review of high-value transactions          │
│ □ Contact AEGIS Support: support@aegis-cyber.com                │
│ □ Document timeline in Major Incident Report                    │
│ □ Prepare customer communication if downtime > 5 minutes        │
└─────────────────────────────────────────────────────────────────┘
```

## 2.5 Level 4: Catastrophic Event Response

**Trigger:** Complete data center failure, Ransomware detection, Regulatory seizure order

**Immediate Actions:**
1. ⚠ **[NOT YET EXECUTABLE — DR infrastructure not yet configured]** Activate Disaster Recovery site — no standby site or replica is currently configured. See §6 for current DR posture.
2. ⚠ **[NOT YET EXECUTABLE]** Switch DNS to DR endpoints — no DR endpoints configured.
3. Notify all stakeholders via emergency broadcast
4. Engage forensic investigation team
5. Preserve all evidence for legal proceedings

> **⚠ L4 response readiness:** Steps 1–2 depend on infrastructure that is not yet in place (see §6.1). Until DR infrastructure is configured, L4 response is limited to notification, evidence preservation, and forensic engagement. Work with AEGIS engineering to establish DR prerequisites before this level of response is operational.

---

# 3. SLA & Maintenance Schedule

## 3.1 Service Level Agreements

> **Note:** The numeric targets below are design goals, not yet committed SLA figures. No automated external availability probe currently exists to measure uptime, and end-to-end API latency has not been measured against an external client (PTR-002 baseline, 2026-06-09, characterises internal subsystems only). Targets marked `[NEGOTIATE]` require measurement instrumentation before they can be contractually committed. The KYT rule-engine figure is prod-measured; all others are design targets.

| Metric | Design Target | Current Measurement Status | Notes |
|--------|--------------|---------------------------|-------|
| System Uptime | 99.9%–99.99% `[NEGOTIATE]` | Not yet measured — no automated external availability probe | Target to be agreed from measured baseline |
| KYT Rule-Engine Latency | Sub-millisecond | **P95: 0.081 ms prod-measured** (PTR-002, 2026-06-09) | Pure compute path — confirmed with margin |
| End-to-End API Latency | < 200ms `[NEGOTIATE]` | Not yet measured against external client | PTR-002 loopback ≠ external-call benchmark |
| Threat Detection (end-to-end) | < 500ms | Not yet measured | Design target |
| Session Isolation | < 100ms | Not yet measured | Design target |
| Audit Log Integrity | 100% | SHA-256 hash chain validated at every boot and on-demand | `GET /api/resilience/chain/validate` |

## 3.2 Maintenance Windows

| Activity | Frequency | Duration | Notification |
|----------|-----------|----------|--------------|
| Routine Updates | Weekly (Sunday 02:00 EAT) | 30 minutes | 72 hours prior |
| Security Patches | As needed | 15 minutes | 24 hours prior (or immediate if critical) |
| Model Recalibration | Monthly | 2 hours | 7 days prior |
| Certificate Rotation | Quarterly | Zero-downtime | 14 days prior |
| Disaster Recovery Test | Quarterly (pending DR infrastructure setup — see §6.1) | 4 hours | 30 days prior |

## 3.3 Monthly Calibration Sessions

**Mandatory Attendees:**
- AEGIS Engineering Team
- Bank's Risk Analytics Team
- SOC Lead Analyst
- CISO (optional)

**Agenda:**
1. Review AI threat scoring performance (threat scoring via Anthropic Claude API — model drift PSI/K-S metrics are not applicable to the hosted API model; performance review focuses on false positive/negative rates from the platform's rule-engine and scoring thresholds)
2. Analyze false positive/negative rates from KYT scoring
3. Discuss new threat patterns observed in the period
4. Adjust KYT configuration thresholds if drift in effectiveness is observed (`POST /api/kyt/apply-config`)
5. Update behavioral baselines for new employees

---

# 4. Cryptographic Key Management

## 4.1 Key Hierarchy

> **⚠ Current state:** The HSM-rooted key hierarchy below is the **target architecture**. Currently deployed: environment-variable-derived keys (scrypt KDF, boot-guarded). Hardware HSM is not yet connected (see §4.2). The mTLS private key branch is not yet active (see §4.3).

```
                    ┌──────────────────────────────────┐
                    │  Master Key Source                │
                    │  CURRENT: env vars (scrypt KDF)   │
                    │  TARGET:  HSM (never exported)    │
                    └──────────────────┬────────────────┘
                                       │
            ┌──────────────────────────┼──────────────────────┐
            │                          │                      │
    ┌───────▼───────┐      ┌───────────▼──────────┐  ┌───────▼───────┐
    │ Data Encryption│     │ mTLS Private Key      │  │ Signing       │
    │ Key (DEK)      │     │ [NOT YET ACTIVE —     │  │ Key           │
    │ ACTIVE (env)   │     │  mTLS not deployed]   │  │ ACTIVE (env)  │
    └───────┬───────┘      └───────────┬───────────┘  └───────┬───────┘
            │                          │                      │
    ┌───────▼───────┐      ┌───────────▼──────────┐  ┌───────▼───────┐
    │ Session Keys  │      │ Branch Certs          │  │ Audit Chain   │
    │ (Ephemeral)   │      │ (Per-Location)        │  │ Signatures    │
    └───────────────┘      └───────────────────────┘  └───────────────┘
```

## 4.2 HSM Integration

> **⚠ Current state:** HSM integration is a **software simulation** (`server/lib/hsm-integration.ts`). Production encryption uses environment-variable-derived keys (AES-256-GCM via scrypt KDF), boot-guarded at startup. Hardware HSM is not yet connected. See `docs/regulatory/AEGIS_CYBER_HSM_BOUNDARY_SPEC.md` for the substitution boundary spec and integration prerequisites.

**Supported HSMs (future integration — not currently connected):**
- Thales Luna Network HSM 7
- Entrust nShield Connect+
- AWS CloudHSM (for hybrid deployments)

**PKCS#11 Configuration (future — not currently operational):**
```
PKCS11_LIBRARY=/opt/safenet/lunaclient/lib/libCryptoki2_64.so
AEGIS_HSM_SLOT=1
AEGIS_HSM_LABEL=AEGIS_MASTER_KEY
```

## 4.3 Certificate Rotation Procedure

> **⚠ Current state:** Application-layer mTLS is **not yet deployed** (see §1 Amendment Notice). The procedure below is the target operational runbook for when mTLS is configured as part of bank-IT integration. It is **not yet executable** in the current deployment.

**90-Day mTLS Certificate Rotation (Zero-Downtime) — pending mTLS deployment**

```
┌─────────────────────────────────────────────────────────────────┐
│ CERTIFICATE ROTATION RUNBOOK                                    │
├─────────────────────────────────────────────────────────────────┤
│ Day -14: Generate new certificate from Bank CA                  │
│ Day -7:  Deploy new certificate to staging environment          │
│ Day -3:  Run integration tests with new certificate             │
│ Day 0:   Begin rotation                                         │
│                                                                 │
│ ROTATION STEPS:                                                 │
│ 1. Add new certificate to server trust store (dual-cert mode)   │
│ 2. Verify both old and new certs accepted                       │
│ 3. Update client configurations to use new certificate          │
│ 4. Monitor for connection failures (5-minute window)            │
│ 5. Remove old certificate from trust store                      │
│ 6. Revoke old certificate with CA                               │
│ 7. Document completion in key management log                    │
└─────────────────────────────────────────────────────────────────┘
```

## 4.4 Quantum-Ready Crypto Agility

AEGIS is designed with hot-swappable encryption algorithms for quantum preparedness:

| Algorithm | Status | Use Case |
|-----------|--------|----------|
| AES-256-GCM | ACTIVE | Data at rest (prod-deployed, env-var-derived keys) |
| ChaCha20-Poly1305 | STANDBY | High-performance sessions |
| KYBER-1024 | READY (pending HSM hardware) | Post-quantum key exchange |
| DILITHIUM-3 | READY (pending HSM hardware) | Post-quantum signatures |

**Migration Path:**
1. **Current (LEGACY):** RSA-2048 + AES-256
2. **2025 (HYBRID):** RSA-2048 + KYBER-768
3. **2027 (PQC_NATIVE):** KYBER-1024 + DILITHIUM-3

---

# 5. API Integration Guide

## 5.1 Authentication

> **⚠ Current state:** Application-layer mTLS is **not yet deployed** (see §1 Amendment Notice). Current authentication uses session cookies + CSRF token. The mTLS integration described below is the target operational model pending bank-IT integration setup.

**Current authentication model (deployed):** Session-based — log in via `POST /api/auth/login`, receive an HTTP-only session cookie. All subsequent requests must include the `x-csrf-token` header (obtained from `GET /api/csrf-token`).

```http
POST /api/threats/neutralize HTTP/1.1
Host: aegis.bankname.co.ug
Content-Type: application/json
x-csrf-token: <csrf_token_from_GET_api_csrf-token>
X-Idempotency-Key: <unique_request_id>
Cookie: <session_cookie>

{
  "threatId": 123,
  "action": "neutralize"
}
```

## 5.2 Core Endpoints

### Threat Management
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /api/threats | List all threats |
| POST | /api/threats/:id/neutralize | Neutralize threat |

### KYT (Know Your Transaction)
| Method | Endpoint | Description |
|--------|----------|-------------|
| POST | /api/kyt/analyze | Analyze transaction risk |
| GET | /api/kyt/stats | Get KYT statistics |

### Behavioral Biometrics
| Method | Endpoint | Description |
|--------|----------|-------------|
| POST | /api/resilience/biometrics/telemetry | Submit behavioral telemetry |
| GET | /api/resilience/biometrics | Get biometrics status |

### Executive Reporting
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /api/executive/report | Generate JSON report |
| GET | /api/executive/report/text | Generate text report |

## 5.3 Webhook Configuration

Register webhooks for real-time event notifications:

```json
{
  "name": "CBS Transaction Alerts",
  "url": "https://cbs.bank.co.ug/aegis-webhook",
  "events": [
    "threat.detected",
    "threat.neutralized",
    "session.isolated",
    "compliance.breach"
  ],
  "secret": "<hmac_secret>",
  "retryPolicy": {
    "maxAttempts": 5,
    "backoffMs": 1000
  }
}
```

---

# 6. Disaster Recovery Protocols

## 6.1 Recovery Time Objectives

> **⚠ Current DR posture:** PostgreSQL streaming replication to a standby site is **not yet configured** in any deployment environment. There is no Nairobi DR site. The DR failover simulation (`server/lib/dr-failover.ts`) is in-memory only and has not been live-tested. Current backup capability: pg_dump to local storage; offsite transfer not yet implemented. The RTO/RPO targets below are **design objectives** — they cannot be committed until the DR infrastructure is in place. Items marked `[NOT YET EXECUTABLE]` require infrastructure setup before they can be acted upon.

| Scenario | RTO Target | RPO Target | Recovery Path | Readiness |
|----------|-----------|-----------|---------------|-----------|
| Hardware failure | 5 minutes | Near-zero | Hot standby | `[NOT YET EXECUTABLE — no standby configured]` |
| Data center outage | 30 minutes | 1 minute | Standby site | `[NOT YET EXECUTABLE — no standby site]` |
| Ransomware attack | 4 hours | 24 hours | Restore from backup | Partial — local pg_dump backup only; offsite not implemented |
| Regional disaster | 24 hours | 1 hour | Cloud failover | `[NOT YET EXECUTABLE — no cloud failover configured]` |

## 6.2 Failover Procedure

```
┌─────────────────────────────────────────────────────────────────┐
│ DISASTER RECOVERY ACTIVATION CHECKLIST                          │
├─────────────────────────────────────────────────────────────────┤
│ □ Confirm primary site is unreachable (3 health checks failed)  │
│ □ Notify DR team via emergency broadcast                        │
│ □ ⚠ [NOT YET EXECUTABLE] Activate DR site database             │
│     (promote replica to primary) — no replica configured        │
│ □ ⚠ [NOT YET EXECUTABLE] Update DNS records to DR endpoint     │
│     — no DR endpoint configured                                 │
│ □ ⚠ [NOT YET EXECUTABLE] Verify mTLS certificates on DR site   │
│     — mTLS not yet deployed; no DR site                         │
│ □ Run smoke tests on critical endpoints (when DR available)     │
│ □ Notify SOC team of failover completion                        │
│ □ Begin root cause analysis on primary site                     │
│ □ Document timeline in Incident Report                          │
└─────────────────────────────────────────────────────────────────┘
```

> **⚠ DR activation readiness:** Steps 3–5 above require infrastructure not yet configured. This checklist is the target runbook. Work with AEGIS engineering to establish standby database replication, DNS failover endpoint, and (if required) mTLS configuration before this procedure is operational.

## 6.3 Data Backup Schedule

| Data Type | Frequency | Retention | Storage | Current Status |
|-----------|-----------|-----------|---------|----------------|
| Audit trail | Real-time | 10 years (policy set; automated enforcement not yet active) | SHA-256 hash-chained immutable log in-database | **Implemented** — immutable hash chain in-DB; offsite transfer not yet implemented |
| Transaction logs | Real-time append | 7 years (policy set) | Database | **Implemented** — offsite transfer not yet implemented |
| Database backup | pg_dump schedule | Per deployment config | Local storage | **Implemented** — offsite replication not yet configured |
| User profiles | On-change (DB persistence) | Per data-retention policy | Database (encrypted PII columns) | **Implemented** — dedicated encrypted snapshots not configured |
| AI integration config | On change | Git repository | Git | **Implemented** |
| AI model | Not applicable | Not applicable | Not applicable | Threat scoring uses Anthropic Claude API (external hosted model) — no local model registry |

---

# 7. Appendix: Quick Reference Cards

## 7.1 SOC Analyst Quick Reference

```
┌─────────────────────────────────────────────────────────────────┐
│ AEGIS COMMAND CENTER - QUICK REFERENCE                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ DASHBOARD INDICATORS:                                           │
│   🟢 Green  = System healthy, no active threats                 │
│   🟡 Yellow = Elevated risk, monitoring recommended             │
│   🔴 Red    = Active threat, immediate action required          │
│   ⚫ Black  = System offline, failover active                   │
│                                                                 │
│ KEYBOARD SHORTCUTS:                                             │
│   Ctrl+N  = Neutralize selected threat                          │
│   Ctrl+I  = Isolate session                                     │
│   Ctrl+R  = Refresh dashboard                                   │
│   Ctrl+E  = Export current view                                 │
│                                                                 │
│ ESCALATION CONTACTS:                                            │
│   L1 Support:  support@aegis-cyber.com                          │
│   L2 Urgent:   +256-XXX-XXXX (24/7 hotline)                     │
│   CISO Alert:  ciso-alert@bank.co.ug                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

## 7.2 Error Code Reference

| Code | Category | Description | Resolution |
|------|----------|-------------|------------|
| AEGIS_ERR_001 | AUTH | Invalid session token | Re-authenticate |
| AEGIS_ERR_002 | AUTH | Insufficient permissions | Contact admin |
| AEGIS_ERR_101 | THREAT | Threat not found | Check threat ID |
| AEGIS_ERR_102 | THREAT | Already neutralized | No action needed |
| AEGIS_ERR_201 | CBS | Integration timeout | Check CBS status |
| AEGIS_ERR_301 | CRYPTO | Key rotation required | Run rotation procedure |
| AEGIS_ERR_401 | COMPLIANCE | PDPO deadline approaching | Submit report |

## 7.3 Regulatory Compliance Checklist

```
┌─────────────────────────────────────────────────────────────────┐
│ MONTHLY COMPLIANCE VERIFICATION                                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│ PDPO 2019 (Uganda Data Protection and Privacy Act):             │
│   □ Data residency verified (processing within Uganda)          │
│   □ Breach notifications prepared (if applicable)               │
│   □ Data subject requests (DSARs) processed within 30 days      │
│   □ DSAR purge worker tick confirmed clean (deployment logs)     │
│                                                                 │
│ Bank of Uganda Requirements:                                    │
│   □ Monthly threat summary submitted to BOU-SOC                 │
│   □ Audit trail integrity verified (GET /api/resilience/        │
│       chain/validate)                                           │
│   □ DR test results documented (when DR infrastructure ready)   │
│   □ Schema conformance boot assertion clean at last restart     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

> **Note:** DORA (EU Digital Operational Resilience Act) has been removed from this checklist — it is an EU regulation applicable to EU financial entities and is not a compliance obligation for Ugandan banks under PDPO 2019 / BoU supervision. If AEGIS CYBER is deployed in EU-jurisdiction contexts in future, a separate DORA compliance annex should be prepared.

---

# Document Control

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 4.2.2 | 2026-06-09 | AEGIS Team | §2–§7 operational refresh: corrected static fallback rules (RULE_001–004 verified against codebase); §3 SLA targets changed from committed figures to design targets with measurement status; §3.3 model calibration reframed for Claude API; §4.2/§4.3 HSM and mTLS marked NOT-YET-DEPLOYED; §4.4 PQC readiness scoped to pending HSM hardware; §5.1 auth model corrected to session cookie + CSRF token; forensics endpoint removed (not implemented); §6 DR sections marked NOT-YET-EXECUTABLE with posture note; §6.3 backup schedule reconciled to actual implementation; §7.3 DORA removed (EU regulation, not applicable to Ugandan banks — see note). |
| 4.2.1 | Jan 2026 | AEGIS Team | Added Interaction DNA, Executive Reports |
| 4.2.0 | Dec 2025 | AEGIS Team | Added KYT, Agentic Commerce, SupTech |
| 4.1.0 | Nov 2025 | AEGIS Team | Added Commercial-Grade Resilience Layer |
| 4.0.0 | Oct 2025 | AEGIS Team | Initial enterprise release |

---

**AEGIS CYBER - Sovereign Security for African Banking**

*For questions or support, contact: enterprise@aegis-cyber.com*