🔄 Riksdagsmonitor — Business Continuity Plan

🛡️ Dual-Deployment Resilience Framework
🎯 Enterprise-Grade Availability Through Geographic Redundancy

📋 Document Owner: CEO | 📄 Version: 1.3 | 📅 Last Updated: 2026-05-28 (UTC)
🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-08-28
📌 Classification: Public

🎯 Purpose Statement

Riksdagsmonitor's business continuity framework demonstrates how geographic redundancy and automated failover directly enable operational resilience and service availability. Our dual-deployment strategy serves as both operational necessity and technical demonstration of enterprise-grade reliability principles.

This plan is designed to maintain the riksdagsmonitor.com platform during infrastructure disruptions through AWS multi-region deployment (primary) and GitHub Pages disaster recovery (standby), targeting 99.998% availability under normal operating conditions, with CloudFront origin failover typically completing in under 60 seconds and DNS/Route 53 failover (including health checks and DNS propagation) completing within approximately 15 minutes during full-region incidents.

— James Pether Sörling, CEO/Founder

📊 Business Impact Analysis

🎯 Service Availability Requirements

Riksdagsmonitor provides public political transparency services requiring high availability but tolerating brief disruptions:

%%{
  init: {
    "theme": "base",
    "themeVariables": {
      "primaryColor": "#1565C0",
      "primaryTextColor": "#0d47a1",
      "lineColor": "#1565C0",
      "secondaryColor": "#4CAF50",
      "tertiaryColor": "#FF9800"
    }
  }
}%%
graph TB
    subgraph BIA["📊 Business Impact Analysis"]
        FINANCIAL[💰 Financial Impact<br/>No direct revenue loss]
        OPERATIONAL[⚙️ Operational Impact<br/>Service unavailable]
        REPUTATIONAL[🤝 Reputational Impact<br/>Public trust in transparency]
        CIVIC[🏛️ Civic Impact<br/>Democratic accountability]
    end
    
    subgraph RECOVERY["🔄 Recovery Requirements"]
        RTO["⏰ RTO Target<br/>&lt; 30 seconds origin failover<br/>&lt; 15 minutes DNS failover"]
        RPO["💾 RPO Target<br/>&lt; 15 minutes<br/>near-zero effective RPO (S3 replication lag)"]
        AVAILABILITY["📈 Availability Target<br/>99.998%<br/>≈10.5 minutes (~631 seconds) downtime/year"]
    end
    
    subgraph DEPLOYMENT["🌍 Deployment Strategy"]
        PRIMARY[☁️ AWS Primary<br/>CloudFront + S3 Multi-Region]
        DR[📝 GitHub Pages DR<br/>Standby Deployment]
        FAILOVER[🔄 Automatic Failover<br/>Route 53 Health Checks]
    end
    
    FINANCIAL --> RTO
    OPERATIONAL --> RTO
    REPUTATIONAL --> RPO
    CIVIC --> AVAILABILITY
    
    RTO --> PRIMARY
    RPO --> PRIMARY
    AVAILABILITY --> PRIMARY
    
    PRIMARY --> FAILOVER
    DR --> FAILOVER
    
    style BIA fill:#1565C0,color:#ffffff
    style RECOVERY fill:#FF9800,color:#000000
    style DEPLOYMENT fill:#4CAF50,color:#000000
Copy

📈 Impact Thresholds

Service Component	💰 Financial Impact	⚙️ Operational Impact	🤝 Reputational Impact	🏛️ Civic Impact	🎯 Recovery Priority
🌐 Static Website					🔴 Critical
📊 Content Updates					🟡 Medium
🔍 Search Indexing					🟢 Standard

🏗️ Infrastructure Architecture

🌍 Dual-Deployment Strategy

%%{
  init: {
    "theme": "base",
    "themeVariables": {
      "primaryColor": "#1565C0",
      "primaryTextColor": "#0d47a1",
      "lineColor": "#1565C0",
      "secondaryColor": "#4CAF50",
      "tertiaryColor": "#FF9800"
    }
  }
}%%
graph TB
    subgraph ROUTE53["🌐 Route 53 DNS"]
        DNS[📡 DNS Service<br/>Health Checks Every 30s]
        HEALTHCHECK[⚕️ Health Checker<br/>Tests CloudFront Endpoint]
    end
    
    subgraph PRIMARY["☁️ AWS Primary (Active)"]
        CF["🌍 CloudFront CDN<br/>600+ PoPs<br/>Automatic Origin Failover"]
        S3_US[💾 S3 us-east-1<br/>Primary Origin<br/>Versioning Enabled]
        S3_EU["💾 S3 eu-west-1<br/>Replica Origin<br/>Asynchronous Replication (&lt;15 min RPO)"]
        
        CF -->|Primary| S3_US
        CF -->|Failover on 5xx errors| S3_EU
        S3_US -.->|Replication| S3_EU
    end
    
    subgraph DR["📝 GitHub Pages (Standby)"]
        GH["📄 GitHub Pages<br/>Default branch (root)<br/>Automated Deployment"]
    end
    
    USERS[👥 Users] -->|DNS Query| DNS
    HEALTHCHECK -->|Monitor| CF
    DNS -->|"Healthy: Return CloudFront alias/hostname"| USERS
    DNS -.->|"3 Failed Checks (~90s detection)<br/>+ DNS TTL/propagation (up to ~15 min total)"| USERS
    USERS -->|"HTTPS/TLS 1.3"| CF
    USERS -.->|"HTTPS/TLS 1.3 (DR)"| GH
    
    style ROUTE53 fill:#1565C0,color:#ffffff
    style PRIMARY fill:#4CAF50,color:#000000
    style DR fill:#FF9800,color:#000000
Copy

🛡️ Availability Objectives & Assumptions

These are business continuity design objectives, not contractual guarantees. Availability figures are based on underlying cloud provider SLAs and documented reliability targets.

Disclaimer: These are business continuity design objectives based on AWS published SLAs (CloudFront 99.9%, S3 99.99%, Route 53 100%) and GitHub public reliability targets. The combined 99.998% availability is a theoretical design target assuming largely independent failures. Actual end-to-end availability may be lower in practice. RPO values reflect S3 cross-region replication characteristics (typically < 15 minutes) and static content deployment timing; actual RPO may vary.

🚨 Disaster Recovery Scenarios

Scenario 1: S3 us-east-1 Region Failure

🔍 Detection:

• CloudFront origin monitoring detects 500+ HTTP errors from us-east-1
• Automatic failover triggered without manual intervention

🔄 Recovery Procedure:

1. ⚡ CloudFront automatically routes to S3 eu-west-1 origin (< 30 seconds)
2. 📊 Verify service availability via monitoring
3. 📝 Log incident for post-event analysis
4. ⏳ Monitor AWS status for us-east-1 restoration
5. 🔙 Automatic failback when us-east-1 recovers

✅ Validation:

• Service availability confirmed via health checks
• User experience unaffected (transparent failover)
• Content served from eu-west-1 (identical to us-east-1)

Scenario 2: CloudFront Global Outage

🔍 Detection:

• Route 53 health checks fail for CloudFront endpoint
• Automated DNS failover to GitHub Pages after health check detection + DNS propagation (≈ 15 minutes total)

🔄 Recovery Procedure:

1. ⚕️ Route 53 detects CloudFront health check failures (30s intervals × 3 failures = 90 seconds detection time)
2. 🌐 DNS automatically updates riksdagsmonitor.com → GitHub Pages
3. 📊 Verify GitHub Pages serving traffic
4. 📧 Notify CEO of failover event
5. ⏳ Monitor CloudFront status for restoration
6. 🔙 Intentionally manual DNS failback after CloudFront recovery and stability confirmation
   • Rationale: Failback is manual by design to avoid DNS flapping and ensure human verification before restoring CloudFront as primary

✅ Validation:

• GitHub Pages availability confirmed
• Users redirected via DNS (up to 15-minute TTL)
• Content identical (synchronized deployment)

Scenario 3: Both AWS S3 Regions Unavailable

🔍 Detection:

• CloudFront cannot reach either S3 origin
• Route 53 health checks fail

🔄 Recovery Procedure:

1. ⚡ CloudFront attempts origin failover (< 30 seconds)
2. 🌐 Route 53 DNS failover to GitHub Pages (15 minutes)
3. 📊 Verify GitHub Pages serving traffic
4. 📧 CEO notification of major AWS outage
5. ⏳ Monitor AWS status dashboard
6. 🔙 DNS failback after AWS recovery

✅ Validation:

• Service restored via GitHub Pages
• Incident documented with AWS service disruption details

Scenario 4: AWS Account Compromise

🔍 Detection:

• CloudTrail alerts for unauthorized API calls
• GuardDuty security findings
• Unexpected configuration changes

🔄 Recovery Procedure:

1. 🔒 Immediate DNS failover to GitHub Pages (operator action: 2 minutes; client-visible cutover: up to DNS TTL propagation ~15 minutes)
2. 🔐 Revoke all AWS IAM credentials and access keys
3. 🔄 Update AWS IAM role trust policy for GitHub Actions OIDC provider to revoke compromised trust
4. 📊 CloudTrail audit of unauthorized actions
5. 🛡️ AWS Support engagement for forensics
6. 🔧 Restore infrastructure from documented configuration and backups (future-state: Infrastructure-as-Code)
7. ✅ Security validation before DNS failback

✅ Validation:

• Service operational on GitHub Pages
• All compromised credentials revoked
• Forensic analysis completed
• Infrastructure hardened before restoration

Scenario 5: GitHub Pages Unavailable (During DR)

🔍 Detection:

• GitHub Pages deployment failure
• Health checks fail for GitHub Pages endpoint

🔄 Recovery Procedure:

1. 📊 Verify GitHub status dashboard
2. 🌐 If AWS available, revert DNS to CloudFront immediately
3. 📄 If both unavailable, deploy to alternative CDN (Cloudflare Pages, Netlify)
4. 📦 Build static site from Git main branch
5. 🌐 Update DNS to alternative CDN
6. 🔙 Restore to primary after AWS/GitHub recovery

✅ Validation:

• Alternative deployment confirmed operational
• DNS propagation verified
• Incident escalated to GitHub Support

📋 Recovery Team Structure

🎯 Business Continuity Team

👨‍💼 CEO (James Pether Sörling) - Business Continuity Coordinator

• 🔑 Authority: Full decision-making power for continuity actions
• 🎯 Responsibilities: Strategic decisions, stakeholder communication, recovery coordination
• 📞 Contact: Primary mobile, backup email, monitoring alerts
• 🛠️ Tools: AWS Console, GitHub CLI, Route 53 DNS management, CloudWatch

🔧 Technical Recovery (CEO as Technical Lead)

• 🎯 Responsibilities: AWS infrastructure, GitHub Pages, DNS failover, health check monitoring
• 🛠️ Tools: AWS Console, AWS CLI, GitHub Actions, Route 53, CloudWatch
• 📞 Escalation Paths: AWS Enterprise Support, GitHub Enterprise Support

📞 Emergency Contact Matrix

🚨 Emergency Activation

📞 Immediate Actions (First 15 Minutes)

1. 📊 Assess Situation: Determine scope via CloudWatch, Route 53 health checks
2. 🔍 Identify Failure Point: AWS infrastructure, DNS, GitHub Pages
3. 🚀 Activate Recovery: Automatic (CloudFront failover) or manual (DNS update)
4. 📢 Log Incident: Document detection time, symptoms, actions taken
5. 📧 Stakeholder Notification: CEO notification via monitoring alerts

🔄 Recovery Activation Decision Tree

%%{
  init: {
    "theme": "base",
    "themeVariables": {
      "primaryColor": "#1565C0",
      "primaryTextColor": "#0d47a1",
      "lineColor": "#1565C0",
      "secondaryColor": "#4CAF50",
      "tertiaryColor": "#FF9800"
    }
  }
}%%
graph TD
    INCIDENT[🚨 Service Disruption Detected] --> CHECK_CF{CloudFront<br/>Accessible?}
    
    CHECK_CF -->|No| MANUAL_DNS[🌐 Manual DNS Failover<br/>to GitHub Pages<br/>RTO: 2 minutes]
    CHECK_CF -->|Yes| CHECK_S3{S3 Origins<br/>Accessible?}
    
    CHECK_S3 -->|us-east-1 No| AUTO_FAILOVER[⚡ Automatic Origin Failover<br/>to eu-west-1<br/>RTO: &lt; 30 seconds]
    CHECK_S3 -->|Both No| ROUTE53_FAILOVER[⚕️ Route 53 Health Check<br/>DNS Failover<br/>RTO: 15 minutes]
    CHECK_S3 -->|Yes| CHECK_HEALTH{Health Check<br/>Passing?}
    
    CHECK_HEALTH -->|No| INVESTIGATE[🔍 Investigate Root Cause<br/>Application Error?<br/>Configuration Issue?]
    CHECK_HEALTH -->|Yes| FALSE_ALARM[✅ False Alarm<br/>Monitor and Document]
    
    MANUAL_DNS --> VERIFY[✅ Verify Service Restored]
    AUTO_FAILOVER --> VERIFY
    ROUTE53_FAILOVER --> VERIFY
    INVESTIGATE --> VERIFY
    
    VERIFY --> DOCUMENT[📝 Incident Documentation<br/>Post-Event Analysis]
    
    style INCIDENT fill:#FF9800,color:#000000
    style MANUAL_DNS fill:#1565C0,color:#ffffff
    style AUTO_FAILOVER fill:#4CAF50,color:#000000
    style ROUTE53_FAILOVER fill:#1565C0,color:#ffffff
    style VERIFY fill:#4CAF50,color:#000000
Copy

🧪 Testing & Validation

📅 BCP Testing Schedule

🎯 Testing Methodology

Quarterly Origin Failover Test:

1. 🔧 Temporarily deny CloudFront access to S3 us-east-1 via bucket policy (add temporary Deny statement for CloudFront Origin Access Identity)
2. ⏱️ Measure CloudFront automatic failover time to eu-west-1
3. ✅ Verify content served from eu-west-1 origin
4. 🔙 Remove the temporary Deny from us-east-1 bucket policy and confirm failback to primary origin
5. 📝 Document results and improvements

Semi-Annual DNS Failover Test:

1. 🔧 Update Route 53 health check to force failure
2. ⏱️ Measure DNS propagation time
3. ✅ Verify GitHub Pages serving traffic
4. 🔙 Restore Route 53 health check
5. 📝 Document results and TTL impact

📊 Business Continuity Metrics

🎯 Performance Tracking

Note: The "Current Status" values in this table are illustrative planning examples. Actual operational metrics are monitored via AWS CloudWatch, Route 53 health check logs, and GitHub Pages status, and documented in operational runbooks.

🏢 Single-Person Company Adaptation

Hack23 AB Single-Person BCP Model

As CEO/Founder is the sole employee, traditional business continuity teams are not possible. Riksdagsmonitor implements automated infrastructure resilience + comprehensive documentation:

🎯 CEO As Business Continuity Coordinator

Capabilities:

• Cloud Infrastructure Expertise: AWS Solutions Architect, 15+ years experience
• Automated Failover: CloudFront origin failover, Route 53 health checks (no manual intervention)
• Documentation: All procedures documented in ISMS for continuity
• Monitoring: CloudWatch alarms, Route 53 health checks, automated notifications
• Supplier Relationships: AWS Enterprise Support, GitHub Enterprise Support

🎯 Compensating Controls

📚 Related Documents

🏗️ Architecture & Security

• 🏗️ ARCHITECTURE.md - System architecture and AWS infrastructure design
• 🔐 SECURITY_ARCHITECTURE.md - Security controls and AWS security architecture
• 🚀 FUTURE_SECURITY_ARCHITECTURE.md - Security roadmap and planned enhancements
• 🎯 THREAT_MODEL.md - STRIDE threat analysis and risk assessment

🔧 Operations

• ⚙️ WORKFLOWS.md - CI/CD workflows and deployment automation
• 📖 README.md - Project overview and quick start guide

ℹ️ Alignment notice: WORKFLOWS.md, FUTURE_SECURITY_ARCHITECTURE.md and THREAT_MODEL.md are pending update to fully align with the dual-deployment continuity model and current primary hosting described in this BCPPlan. If there is any conflict regarding the current hosting/deployment architecture, this BCPPlan is the authoritative source.

📖 Incident Response Playbooks

This section provides detailed, step-by-step incident response playbooks for the three highest-probability incident scenarios for Riksdagsmonitor. All playbooks follow the PICERL framework: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.

Playbook 1: Content Tampering Incident

Playbook ID: IR-PB-001
Version: 1.0
Owner: James Pether Sörling, CEO
Last Reviewed: 2026-02-25

Trigger Conditions and Detection Signals

This playbook activates when any of the following are detected:

Severity Classification

Step-by-Step Response Procedure

PHASE 1: DETECT (0-15 minutes for P1)

1. Receive Alert — GitHub Actions notification, user report, or automated monitoring
2. Verify Authenticity — Confirm alert is genuine (not false positive)
   • Check GitHub Actions run logs for the deploy job
   • Verify SHA-256 hashes in build metadata
   • Review Git commit history on main branch
3. Classify Severity — Apply classification matrix above
4. Document Start Time — Record incident start timestamp in UTC
5. Open Incident Record — Create GitHub Issue with label security-incident

PHASE 2: TRIAGE (15-30 minutes for P1)

1. Scope Assessment — Which files are affected? (index.html, all 14 language variants, news articles?)
2. Impact Assessment — Is tampered content currently visible to users?
3. Source Identification — Review GitHub audit log for:

   Settings > Security > Audit log
   Filter: Action = "repo.create_actions_secret" or "git.push" or "protected_branch"
   Copy

4. Blast Radius — Determine if compromise is isolated or widespread

PHASE 3: CONTAIN (30-60 minutes for P1)

1. Immediate Rollback — Revert to last known good commit:

   git log --oneline -20  # Identify last known good commit
   git revert HEAD...<last-good-sha>  # Revert to good state
   git push origin main  # Trigger redeploy
   Copy

2. Block Malicious User (if external) — Via GitHub repository settings
3. Revoke Compromised Credentials — If credentials were used:
   • Rotate all GitHub Secrets immediately
   • Revoke compromised PATs
   • Regenerate Amazon Bedrock API keys
4. Enable Temporary Maintenance Mode — If content integrity cannot be confirmed:
   • Temporarily set CloudFront to return 503 for affected paths
   • Display maintenance page with explanation

PHASE 4: ERADICATE (1-4 hours)

1. Root Cause Analysis — Determine exact attack vector:
   • Social engineering?
   • Compromised credentials?
   • Supply chain attack via dependency?
   • GitHub Actions workflow injection?
2. Remove Malicious Content — Clean all affected files
3. Verify Clean State — SHA-256 comparison against last known good
4. Patch Vulnerability — Fix the root cause (update dependency, revoke credential, harden workflow)

PHASE 5: RECOVER (4-24 hours)

1. Restore Service — Deploy verified clean content
2. Verify Integrity — Automated integrity checks pass
3. Monitor Closely — Increased monitoring for 72 hours post-incident
4. Stakeholder Communication — Post transparent incident report (see template below)

PHASE 6: POST-INCIDENT (Within 72 hours)

1. Lessons Learned Meeting — Document findings
2. Update Controls — Implement additional preventive measures
3. Update Threat Model — If new attack vector discovered
4. NIS2 Assessment — Determine if ENISA notification required

Communication Template

Subject: [Riksdagsmonitor] Security Incident Report - Content Integrity

Incident: Potential content tampering detected
Date/Time: [UTC timestamp]
Severity: [P1/P2/P3]
Status: [Investigating / Contained / Resolved]

Summary:
We detected [brief description]. Our investigation found [findings].

Actions Taken:
1. [Action taken]
2. [Action taken]

Impact:
Content was [not affected / affected for X minutes] between [time] and [time].

Preventive Measures:
[Measures implemented to prevent recurrence]

Contact: security@hack23.com
Copy

Rollback Procedure Using Git History

# Step 1: Identify good commit
git log --oneline --graph --all | head -30

# Step 2: Verify content of last known good commit
git show <good-sha>:index.html | sha256sum

# Step 3: Create revert commit (preserves history)
git revert --no-commit <bad-sha>..<HEAD>
git commit -m "security: revert content tampering incident [IR-PB-001]"

# Step 4: Push and trigger redeploy
git push origin main

# Step 5: Verify production content
curl -s https://riksdagsmonitor.com/ | sha256sum
Copy

Evidence Collection Checklist

• [ ] GitHub Actions run logs (download and archive)
• [ ] GitHub Audit Log export for incident timeframe
• [ ] Git commit history with diff
• [ ] SHA-256 hashes of affected and clean files
• [ ] CloudFront access logs for incident timeframe
• [ ] SLSA attestation records
• [ ] Sigstore transparency log entries
• [ ] Browser screenshots of tampered content (if visible)
• [ ] User reports with timestamps
• [ ] Credential access logs from GitHub

Playbook 2: MCP Service Outage Incident

Playbook ID: IR-PB-002
Version: 1.0
Owner: James Pether Sörling, CEO
Last Reviewed: 2026-02-25

Trigger Conditions

Severity Classification

Step-by-Step Response Procedure

PHASE 1: DETECT AND VERIFY

1. Confirm Outage — Check GitHub Actions run history:
   • Navigate to Actions tab
   • Filter by workflow: news-generation.yml
   • Check last 5 runs for failure pattern
2. Identify Scope — Determine which component is failing:
   • Riksdag API unavailable?
   • Amazon Bedrock rate limited or unavailable?
   • riksdag-regering-mcp server issue?
   • Network egress blocked by harden-runner?
3. Check External Status Pages:
   • https://www.riksdagen.se/sv/kontakt/ (Riksdag IT contact)
   • https://status.aws.amazon.com/ (Amazon Bedrock status)
   • https://www.githubstatus.com/ (GitHub Actions status)
4. Classify Severity and start incident timer

PHASE 2: TRIAGE

1. Check Cached Data Availability — Verify cia-data/ directory has recent data
2. Determine User Impact — Are dashboards showing stale data? How stale?
3. Estimate Recovery Time — Is this an external outage (wait) or internal issue (fix)?

PHASE 3: CONTAIN / GRACEFUL DEGRADATION

1. Activate Stale Data Banner — If data is more than 48 hours old:
   • Edit index.html to show data freshness warning
   • Deploy immediately
2. Use Cached Data — Pipeline automatically falls back to cia-data/ cache
3. Disable Failed Pipeline — If pipeline is producing errors, temporarily disable cron:

   # Temporarily comment out schedule trigger in workflow YAML
   # on:
   #   schedule:
   #     - cron: '0 1 * * *'
   Copy

4. Document Outage Start — Record in incident log

PHASE 4: INVESTIGATE AND RESTORE

1. External Outage: Wait for provider recovery, monitor status pages
2. Internal Issue - API Change:
   • Review Riksdag API changelog
   • Update MCP server configuration
   • Test with npm run test:mcp
3. Internal Issue - Credential:
   • Verify Amazon Bedrock API key in GitHub Secrets
   • Rotate key if expired or compromised
4. Internal Issue - Rate Limiting:
   • Implement exponential backoff
   • Reduce fetch frequency temporarily
   • Check Riksdag API terms of service

PHASE 5: RESTORE SERVICE

1. Re-enable Pipeline — Restore cron schedule in workflow
2. Run Manual Trigger — workflow_dispatch to verify pipeline works
3. Verify Output — Confirm articles generate successfully in all 14 languages
4. Remove Stale Banner — Update HTML once fresh data available
5. Verify Dashboards — Confirm CIA data dashboards show current data

PHASE 6: POST-INCIDENT

1. Document Root Cause — In incident GitHub Issue
2. Add Monitoring — Alert if no successful pipeline run in 36 hours
3. Update Runbooks — If new failure mode discovered
4. Resilience Improvement — Implement recommendation from this incident

Service Restoration Checklist

• [ ] MCP server responding to tool discovery
• [ ] Riksdag API returning valid JSON
• [ ] Amazon Bedrock API responding within 30s
• [ ] News generation pipeline completes without error
• [ ] 14 language articles successfully generated
• [ ] SHA-256 integrity check passes
• [ ] Git commit and PR created successfully
• [ ] CIA data dashboards showing fresh data
• [ ] Stale data banners removed from all 14 language pages
• [ ] GitHub Actions workflow next scheduled run confirmed

Communication Template

Subject: [Riksdagsmonitor] Service Notification - Data Pipeline Status

Status: [Investigating / Degraded / Restored]
Affected: Automated news generation and/or data dashboard updates
Date: [UTC date]

Current Status:
The automated data pipeline is [description]. 
Content published before [timestamp] remains accurate.

Expected Resolution:
[ETA or "Awaiting external provider recovery"]

Data Freshness:
Most recent data: [timestamp]
Best available data is displayed with staleness indicator.

Updates: Follow https://github.com/Hack23/riksdagsmonitor/issues
Copy

Playbook 3: Data Poisoning / Integrity Incident

Playbook ID: IR-PB-003
Version: 1.0
Owner: James Pether Sörling, CEO
Last Reviewed: 2026-02-25

Trigger Conditions

Severity Classification

Step-by-Step Response Procedure

PHASE 1: DETECT

1. Initial Detection — Via human review gate, quality scoring, or user report
2. Preserve Evidence — Before any changes:
   • Screenshot anomalous content
   • Download and archive current cia-data/ directory
   • Export GitHub Actions run log
   • Record all timestamps in UTC
3. Initial Assessment — Is this:
   • LLM hallucination (most likely)?
   • Corrupted source data from Riksdag API?
   • Malicious injection into CIA platform export?
   • Supply chain compromise in MCP server?

PHASE 2: TRIAGE

1. Trace to Source — Identify where anomalous data entered:

   # Check raw API response data
   cat cia-data/raw-export.json | jq '.["votingStats"]'
   
   # Compare with previous good data
   git diff HEAD~1 -- cia-data/
   
   # Check MCP tool call logs in GitHub Actions
   # Navigate: Actions > run-id > news-generation > step-logs
   Copy

2. Scope Assessment — How much content is affected?
3. Published vs Pending — Is anomalous content live or only in pipeline?

PHASE 3: CONTAIN

1. If Content Is Live — Immediate quarantine:

   # Revert to last clean version
   git revert HEAD --no-commit
   git commit -m "security: quarantine poisoned content [IR-PB-003]"
   git push origin main
   Copy

2. Pause Pipeline — Disable automated news generation until source validated:
   • Comment out cron schedule in workflow YAML
   • Push change to temporarily halt pipeline
3. Quarantine Data Files — Move suspicious data to quarantine directory:

   mkdir -p cia-data/quarantine/$(date +%Y%m%d)
   cp cia-data/*.json cia-data/quarantine/$(date +%Y%m%d)/
   Copy

4. Update Cache — Restore from last verified clean data backup (Git history)

PHASE 4: VALIDATE SOURCE DATA

1. Cross-Reference with Riksdag.se — Manually verify key statistics:
   • Party seat counts at https://riksdagen.se
   • Recent vote outcomes
   • Member information
2. Verify CIA Platform Data — Check CIA platform directly:
   • Access https://cia.hack23.com and compare key figures
   • Check CIA platform's own data integrity logs
3. Re-fetch Clean Data — Trigger fresh MCP data fetch after source verified:

   npm run fetch:cia-data  # Fetch fresh data
   npm run validate:data   # Run validation suite
   Copy

4. Schema Comparison — Verify data structure matches expected schema:

   npm run validate:schema -- --input cia-data/export.json
   Copy

PHASE 5: ERADICATE

1. Remove All Poisoned Content — From production and Git history if needed
2. Re-validate All Published Articles — Check recent articles against source data
3. Update Quality Filters — Add detection rules for the anomaly type seen
4. Enhance LLM Guardrails — Add explicit factual verification prompts

PHASE 6: RECOVER

1. Re-enable Pipeline — Restore cron schedule after validation
2. Generate Fresh Articles — Replace any quarantined content
3. Issue Correction — If incorrect information was public, issue transparent correction
4. Enhanced Monitoring — Increase review frequency for 30 days

PHASE 7: POST-INCIDENT

1. Root Cause Report — Document in incident GitHub Issue
2. Control Enhancement — Implement additional preventive measures
3. Threat Model Update — Update THREAT_MODEL.md with new attack vector
4. Communication — If users were exposed to false information, issue public statement

Root Cause Analysis Template

## Data Poisoning Incident RCA - [DATE]

**Incident ID:** IR-PB-003-[YYYYMMDD]
**Severity:** [P1/P2/P3]
**Detection Time:** [UTC]
**Containment Time:** [UTC]
**Resolution Time:** [UTC]

### Timeline
| Time (UTC) | Event |
|------------|-------|
| [time] | Anomaly first detected by [method] |
| [time] | [Action taken] |

### Root Cause
[Describe the root cause: LLM hallucination / API corruption / supply chain]

### Attack Vector (if malicious)
[Describe how attacker introduced false data]

### Impact Assessment
- Content affected: [list of files/articles]
- Time live: [duration if published]
- User exposure: [estimated unique users who may have seen false content]

### Remediation Steps Taken
1. [Step taken]
2. [Step taken]

### Preventive Measures Implemented
1. [Control enhancement]
2. [Control enhancement]

### Lessons Learned
[Key takeaways for future incident prevention]
Copy

Preventive Measures

Playbook Summary Reference Card

📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification:
📅 Effective Date: 2026-05-28
⏰ Next Review: 2026-08-28
🎯 Framework Compliance:

🌐 IMF API Outage — Business Continuity Scenarios

Effective: 2026-04-24 · Authoritative hub: analysis/imf/README.md · analysis/imf/agentic-integration.md · analysis/imf/indicators-inventory.json · analysis/imf/data-dictionary.md · .github/aw/ECONOMIC_DATA_CONTRACT.md

IMF dependency criticality

IMF outage scenarios

IMF + multi-provider resilience

The IMF-primary, WB-residue, SCB-Sweden split is itself a BCP control: a single-provider outage degrades but does not break the platform. Look-ahead article workflows degrade gracefully because:

1. Last cached IMF vintage remains valid for 6 months by contract
2. SCB national-accounts cover the highest-priority Swedish-specific indicators
3. WB residue continues to flow for governance/environment/social classes

Canonical rule. Every economic claim in a Riksdagsmonitor article cites an IMF dataflow first; World Bank citations are reserved for governance, environment and social residue (the classes IMF does not publish). SCB is the Swedish-specific ground truth layer. See ECONOMIC_DATA_CONTRACT.md v2.1 for the banned-phrase list and vintage discipline (>6 mo → annotation).

🔗 Hack23 Ecosystem

🗳️ Empower citizens · 🔍 Strengthen democratic accountability · 🕵️ Illuminate the political process

_{© 2008–2026 Hack23 AB (Org.nr 559534-7807) · Maintainer: James Pether Sörling, CISSP CISM}