diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 921d1ff..9a2c3d7 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -1,12 +1,34 @@ { "$schema": "https://anthropic.com/claude-code/marketplace.schema.json", "name": "grc-skills", - "description": "Claude Code skills for Governance, Risk & Compliance \u2014 ISO 27001, SOC 2, FedRAMP, GDPR, HIPAA, NIST CSF, PCI DSS, TSA Cybersecurity, and ISO 42001 AI Management System.", + "description": "Claude Code skills for Governance, Risk & Compliance — ISO 22301, ISO 27001, SOC 2, FedRAMP, GDPR, HIPAA, NIST CSF, PCI DSS, TSA Cybersecurity, and ISO 42001 AI Management System.", "owner": { "name": "Hemant Naik", "email": "hemant.naik@gmail.com" }, "plugins": [ + { + "name": "iso22301", + "source": "./plugins/iso22301", + "description": "ISO 22301:2019 Business Continuity Management System (BCMS) advisor — gap analysis, BIA, risk assessment, BC strategy, BCP authoring, exercise programmes, and certification readiness.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "iso22301", + "bcms", + "business-continuity", + "bcp", + "bia", + "disaster-recovery", + "resilience", + "grc" + ] + }, { "name": "iso27001", "source": "./plugins/iso27001", @@ -179,6 +201,30 @@ "grc" ] }, + { + "name": "iso27017", + "source": "./plugins/iso27017", + "description": "ISO/IEC 27017:2015 cloud security controls advisor — gap analysis, shared responsibility mapping, CSP/CSC control guidance, CLD control implementation, cloud service agreement security reviews, and virtual environment security.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "iso27017", + "cloud-security", + "cloud-controls", + "csp", + "csc", + "shared-responsibility", + "virtual-machine-security", + "iso27002", + "grc", + "compliance" + ] + }, { "name": "iso42001", "source": "./plugins/iso42001", @@ -200,6 +246,100 @@ "aisia", "grc" ] + }, + { + "name": "govramp", + "source": "./plugins/govramp", + "description": "GovRAMP security authorization advisor for state and local government cloud \u2014 impact level selection, SSP documentation, gap analysis, Core/Ready/Authorized status paths, Fast Track, continuous monitoring, and NIST 800-53 Rev 5 control guidance for SLED organizations.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "govramp", + "stateramp", + "sled", + "state-local-government", + "cloud-security", + "nist-800-53", + "authorization", + "3pao", + "grc", + "public-sector" + ] + }, + { + "name": "cmmc", + "source": "./plugins/cmmc", + "description": "CMMC 2.0 compliance advisor for defense contractors — Level 1/2/3 gap analysis, scoping, SPRS scoring, SSP documentation, POA&M development, C3PAO assessment preparation, and NIST 800-171/800-172 practice guidance for organizations protecting FCI and CUI under DoD contracts.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "cmmc", + "cmmc-2.0", + "dod", + "defense-contractor", + "dib", + "cui", + "nist-800-171", + "sprs", + "c3pao", + "grc" + ] + }, + { + "name": "iso31000", + "source": "./plugins/iso31000", + "description": "ISO 31000:2018 Risk Management advisor — risk framework design, gap analysis, risk register development, risk treatment planning, risk appetite statements, monitoring and review, board risk reporting, and integration with ISO 27001, ISO 9001, and ISO 42001.", + "version": "0.1.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "iso31000", + "risk-management", + "risk-assessment", + "risk-treatment", + "risk-register", + "enterprise-risk", + "erm", + "grc" + ] + }, + { + "name": "eu-ai-act", + "source": "./plugins/eu-ai-act", + "description": "EU AI Act (Regulation (EU) 2024/1689) compliance advisor \u2014 risk classification, prohibited AI practices, high-risk AI requirements, GPAI model obligations, conformity assessment, deployer obligations, FRIA, and compliance roadmaps.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "eu-ai-act", + "artificial-intelligence-act", + "ai-regulation", + "high-risk-ai", + "gpai", + "ai-compliance", + "eu-regulation", + "ai-governance", + "conformity-assessment", + "grc" + ] } ] -} \ No newline at end of file +} diff --git a/CMMC - Claude Skill/CMMC-README.md b/CMMC - Claude Skill/CMMC-README.md new file mode 100644 index 0000000..ed35424 --- /dev/null +++ b/CMMC - Claude Skill/CMMC-README.md @@ -0,0 +1,104 @@ +# CMMC 2.0 Compliance Skill for Claude + +A Claude skill that provides expert, end-to-end CMMC 2.0 compliance guidance for +organizations in the Defense Industrial Base (DIB) — from level determination and +scoping through gap analysis, documentation, assessment preparation, and post-certification +management. + +--- + +## What Does the Skill Do? + +This skill turns Claude into a knowledgeable CMMC 2.0 advisor. It covers the full +compliance lifecycle for organizations pursuing or maintaining CMMC certification under +the DoD CMMC 2.0 Final Rule (32 CFR Part 170), effective December 16, 2024. + +At a high level, the skill enables Claude to: + +- **Determine CMMC level requirements** based on contract data types (FCI, CUI) and + program designation (Level 1, 2, or 3) +- **Define assessment scope** using the six CMMC asset categories: CUI Assets, Security + Protection Assets, Contractor Risk Managed Assets, Specialized Assets, Out-of-Scope + Assets, and External Service Providers +- **Conduct gap analyses** against all 110 Level 2 practices (NIST SP 800-171 Rev 2) and + all 24 additional Level 3 enhanced practices (NIST SP 800-172) +- **Calculate SPRS scores** using the DoD Assessment Methodology deduction weights and + guide SPRS submission to DIBNet portal +- **Draft System Security Plans (SSPs)** with practice-level implementation narratives, + boundary descriptions, and documentation control +- **Develop POA&Ms** with gap descriptions, remediation actions, milestone dates, and + conditional certification tracking (180-day closure requirement) +- **Prepare for C3PAO assessments** with domain-by-domain evidence checklists, interview + preparation, and artifact organization +- **Guide Level 3 DIBCAC readiness** including 24 enhanced NIST 800-172 practices: + SOC capabilities, threat hunting, deception technologies, APT training, and + DIBCAC assessment process +- **Advise on subcontractor and ESP flow-down** requirements under DFARS 252.204-7021 +- **Support Annual Affirmation** processes via DIBNet portal + +--- + +## Framework Reference + +**CMMC 2.0 Final Rule:** 32 CFR Part 170, effective December 16, 2024 +**Level 1 Basis:** FAR 52.204-21 (17 practices) +**Level 2 Basis:** NIST SP 800-171 Rev 2 (110 practices, 14 domains) +**Level 3 Basis:** NIST SP 800-172 (24 additional enhanced practices) +**Assessment Methodology:** NIST SP 800-171A (for Level 2) +**SPRS Scoring:** DoD Assessment Methodology v1.2.1 + +--- + +## Skill Structure + +``` +skills/ + cmmc/ + SKILL.md Main skill instructions + references/ + level1-practices.md 17 Level 1 practices with evidence requirements + level2-practices.md All 110 Level 2 practices by domain with SPRS weights + level3-practices.md 24 additional Level 3 enhanced practices from NIST 800-172 + scoping-guide.md Asset category scoping, CUI identification, ESP flow-down + assessment-guide.md C3PAO process, SPRS calculation, POA&M, evidence by domain +``` + +--- + +## Use Cases + +| Use Case | What Claude Will Do | +|---------|-------------------| +| "What CMMC level do we need?" | Walks through decision logic based on contract data type and program designation | +| "Help us scope our CMMC assessment" | Categorizes assets, identifies CUI flows, flags ESPs and OT/IoT | +| "Perform a CMMC Level 2 gap analysis" | Generates domain-by-domain gap table against all 110 practices | +| "Calculate our SPRS score" | Applies DoD Assessment Methodology weighting to identify score | +| "Write our SSP for CMMC Level 2" | Drafts narrative templates for all 14 domains | +| "Create a POA&M for these gaps" | Builds structured POA&M with milestones and owners | +| "Prepare for C3PAO assessment" | Generates evidence checklist and interview prep guide | +| "What does DFARS 252.204-7012 require?" | Explains incident reporting obligations to DoD | +| "We're aiming for Level 3 — what's different?" | Explains 24 NIST 800-172 enhanced requirements | +| "Do our subcontractors need CMMC?" | Explains flow-down obligations per DFARS 252.204-7021 | + +--- + +## Official Resources + +- **DoD CMMC Program:** https://dodcio.defense.gov/CMMC/ +- **Cyber-AB (Accreditation Body):** https://cyberab.org/ +- **DIBNet Portal:** https://dibnet.dod.mil +- **NIST SP 800-171 Rev 2:** https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final +- **NIST SP 800-172:** https://csrc.nist.gov/publications/detail/sp/800-172/final +- **NIST SP 800-171A:** https://csrc.nist.gov/publications/detail/sp/800-171a/final +- **NARA CUI Registry:** https://www.archives.gov/cui +- **32 CFR Part 170 (Final Rule):** Published October 15, 2024 + +--- + +## Disclaimer + +This skill is for informational and educational purposes only and does not constitute +legal advice or official DoD compliance guidance. CMMC certification requires formal +assessment by a Cyber-AB authorized C3PAO (Level 2) or the DCMA DIBCAC (Level 3). +Organizations should engage qualified legal counsel and a licensed C3PAO or RPO for +formal compliance determinations. diff --git a/CMMC - Claude Skill/cmmc.skill b/CMMC - Claude Skill/cmmc.skill new file mode 100644 index 0000000..5d142ab Binary files /dev/null and b/CMMC - Claude Skill/cmmc.skill differ diff --git a/EU AI Act - Claude Skill/EU-AI-Act-README.md b/EU AI Act - Claude Skill/EU-AI-Act-README.md new file mode 100644 index 0000000..ddf2058 --- /dev/null +++ b/EU AI Act - Claude Skill/EU-AI-Act-README.md @@ -0,0 +1,156 @@ +# EU AI Act — Claude Skill + +Expert EU AI Act (Regulation (EU) 2024/1689) compliance advisor for Claude. + +--- + +## What This Skill Does + +The EU AI Act skill transforms Claude into a knowledgeable EU AI Act compliance advisor with deep, article-level knowledge of Regulation (EU) 2024/1689. It covers the complete regulatory framework — from the risk classification decision tree (prohibited / high-risk / transparency-only / minimal risk) through to full compliance implementation for providers, deployers, GPAI model developers, importers, and distributors. + +**Designed for:** +- AI providers (organisations that develop and place AI systems on the EU market) +- AI deployers (organisations that use AI systems in professional contexts within the EU) +- GPAI model providers (organisations developing foundation models or large language models) +- Legal, compliance, and GRC teams managing EU AI Act obligations +- Product manufacturers embedding AI into regulated products +- Non-EU organisations placing AI systems on the EU market +- Auditors, legal advisors, and regulatory consultants advising on EU AI Act compliance + +--- + +## Capabilities + +### AI System Risk Classification +Structured classification using the Article 6 decision tree — determines whether a system is Prohibited (Art. 5), High-Risk (Art. 6(1) or 6(2)), Transparency-Only (Art. 50), or Minimal Risk, with specific article citations and applicable obligations. + +### Gap Analysis for High-Risk AI Systems +Comprehensive gap assessment across all Articles 8–17 requirements for providers, and all Article 26 obligations for deployers. Outputs prioritised gap registers with evidence requirements and remediation actions. + +### GPAI Model Compliance Assessment +Determines GPAI model obligations under Articles 51–56, including: whether the model qualifies as GPAI, whether open-weight exemption (Art. 54) applies, whether systemic risk threshold (10^25 FLOPs) is triggered, and compliance status against all four standard obligations and four systemic risk obligations. + +### Fundamental Rights Impact Assessment (FRIA) +Guides deployers through the Art. 27 FRIA process step by step, including assessment against all EU Charter articles, risk mitigation measures, and consultation requirements. Provides a complete FRIA template. + +### Conformity Assessment Guidance +Determines the appropriate conformity assessment route (internal self-assessment under Art. 43(2) or third-party via Notified Body) and provides step-by-step guidance for each route, including technical documentation requirements (Annex IV). + +### Document Generation +Produces all key compliance documents with article citations: +- EU Declaration of Conformity (Annex V format) +- Technical Documentation (Annex IV structure) +- Fundamental Rights Impact Assessment (Art. 27 template) +- Serious Incident Reports (Art. 73 format) +- Post-Market Monitoring Plans (Art. 72) +- Provider and Deployer compliance checklists + +### Prohibited Practices Analysis +Detailed analysis of each of the 8 prohibited AI categories under Article 5, including borderline cases, exceptions, and the enforcement timeline (prohibited from 2 February 2025). + +### Compliance Timeline Planning +Generates organisation-specific compliance roadmaps aligned to EU AI Act application dates (Feb 2025, Aug 2025, Aug 2026, Aug 2027) based on the AI systems and roles involved. + +### Penalty Analysis +Analyses potential penalty exposure for specific violations across the three penalty tiers (up to €35M/7%; €15M/3%; €7.5M/1.5% of global annual turnover) and identifies mitigating factors. + +--- + +## Skill Contents + +``` +eu-ai-act.skill +└── eu-ai-act/ + ├── SKILL.md # Core skill — loaded on every trigger + └── references/ + ├── eu-ai-act-articles.md # Key articles across all 13 chapters — chapter summaries, definitions, timelines + ├── eu-ai-act-prohibited-practices.md # Article 5 — all 8 prohibited categories in full with conditions and exceptions + ├── eu-ai-act-high-risk-systems.md # Article 6, Annex III, Arts. 8-17 requirements, conformity assessment routes + ├── eu-ai-act-gpai-models.md # Chapter V — GPAI obligations, systemic risk, codes of practice + └── eu-ai-act-obligations-templates.md # Provider/deployer checklists, FRIA template, technical documentation outline, declaration of conformity template +``` + +--- + +## Installation + +### Claude.ai (Chat Interface) + +1. Download [`eu-ai-act.skill`](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/raw/main/EU%20AI%20Act%20-%20Claude%20Skill/eu-ai-act.skill) +2. Open [Claude.ai](https://claude.ai) — **Customize and Settings → Skills** +3. Click **Upload Skill** and select the downloaded file +4. The skill activates automatically when your conversation involves EU AI Act topics + +### Claude Code (CLI / Developer) + +```bash +claude skill add https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/raw/main/EU%20AI%20Act%20-%20Claude%20Skill/eu-ai-act.skill +``` + +### From the Plugin Registry + +If using the full GRC Skills plugin registry: + +```bash +claude plugin add https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance +``` + +--- + +## Key Coverage Areas + +| EU AI Act Area | Coverage | +|---------------|---------| +| Chapter I — General Provisions (Arts. 1–4) | Scope, definitions, AI literacy | +| Chapter II — Prohibited AI (Art. 5) | All 8 categories, conditions, exceptions, enforcement | +| Chapter III — High-Risk AI (Arts. 6–51) | Annex I/III classification, Arts. 8–17 requirements, conformity assessment, CE marking, EU database | +| Chapter IV — Transparency (Art. 50) | Chatbot disclosure, deepfake labelling, emotion recognition | +| Chapter V — GPAI Models (Arts. 51–56) | All provider obligations, systemic risk (10^25 FLOPs), open-weight rules, codes of practice | +| Chapter VI — Innovation (Arts. 57–63) | Regulatory sandboxes | +| Chapter VII — Governance (Arts. 64–70) | AI Office, AI Board, NCAs, scientific panel | +| Chapter VIII/IX — Monitoring (Arts. 71–80) | Post-market monitoring, incident reporting, market surveillance | +| Chapter X — Penalties (Arts. 99–101) | All three penalty tiers with conditions | +| Annexes I, III | Product safety legislation scope; high-risk use case areas | +| Annexes IV, V, VII | Technical documentation, declaration of conformity, post-market monitoring | +| Annexes XI, XII | GPAI technical documentation and downstream provider information | + +--- + +## Example Prompts + +- "Is my AI-powered CV screening system high-risk under the EU AI Act?" +- "What obligations does Article 26 impose on me as a deployer of a credit scoring AI?" +- "We're a GPAI foundation model provider with an open-weight model — what do we need to do?" +- "Help me conduct a gap analysis for our high-risk AI system's technical documentation under Annex IV" +- "Draft a Fundamental Rights Impact Assessment for our benefits eligibility AI system" +- "What are the prohibited AI practices and when did they come into force?" +- "Our AI training compute is approximately 3 × 10^25 FLOPs — what does this mean for us?" +- "What are the timeline deadlines for high-risk AI compliance in 2026?" +- "Draft an EU Declaration of Conformity for our internal conformity assessment" + +--- + +## Regulatory References + +- **Regulation (EU) 2024/1689** — Official Journal of the EU, L 2024/1689, 12 July 2024 +- **European AI Office** — [https://digital-strategy.ec.europa.eu/en/policies/ai-office](https://digital-strategy.ec.europa.eu/en/policies/ai-office) +- **AI Act Explorer** (third-party reference) — [https://artificialintelligenceact.eu](https://artificialintelligenceact.eu) +- **EUR-Lex** (official text) — [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689) + +--- + +## Relationship to Other Skills in this Repository + +| Skill | Relationship to EU AI Act | +|-------|--------------------------| +| ISO 42001 | ISO 42001 AIMS is a natural companion to EU AI Act compliance; AISIA maps to FRIA; Annex A controls support high-risk AI requirements. ISO 42001 certification does not constitute EU AI Act conformity assessment. | +| GDPR | EU AI Act and GDPR apply simultaneously for AI systems processing personal data. High-risk AI data governance (Art. 10) must comply with GDPR. FRIA is distinct from but complementary to DPIA. | +| ISO 27001 | Cybersecurity requirements (Art. 15) align with ISO 27001 controls; an ISMS can support the cybersecurity and data governance aspects of EU AI Act compliance. | + +--- + +## Version History + +| Version | Date | Changes | +|---------|------|---------| +| 1.0.0 | April 2026 | Initial release — full coverage of Regulation (EU) 2024/1689 as of April 2026 | diff --git a/EU AI Act - Claude Skill/eu-ai-act.skill b/EU AI Act - Claude Skill/eu-ai-act.skill new file mode 100644 index 0000000..0e7191b Binary files /dev/null and b/EU AI Act - Claude Skill/eu-ai-act.skill differ diff --git a/GovRAMP - Claude Skill/GovRAMP-README.md b/GovRAMP - Claude Skill/GovRAMP-README.md new file mode 100644 index 0000000..ea5f362 --- /dev/null +++ b/GovRAMP - Claude Skill/GovRAMP-README.md @@ -0,0 +1,201 @@ +# GovRAMP Security Authorization Skill for Claude + +A Claude skill that provides expert, end-to-end guidance for GovRAMP authorization — +from impact level selection and gap assessment through documentation, 3PAO engagement, +government sponsorship, and ongoing continuous monitoring for state, local, education, +tribal, and special district (SLED) cloud deployments. + +--- + +## What Does the Skill Do? + +This skill turns Claude into a knowledgeable GovRAMP advisor. It covers the full +authorization lifecycle for Cloud Service Providers (CSPs) pursuing or maintaining a +GovRAMP security status under the current **NIST SP 800-53 Rev 5** baseline. + +GovRAMP (formerly StateRAMP, doing business as GovRAMP since 2023) is a 501(c)(6) +nonprofit membership organization that provides standardized cybersecurity verification +and validation for cloud providers serving SLED organizations. It is based on the same +NIST 800-53 framework used by FedRAMP, with adaptations for the state-local context. + +At a high level, the skill enables Claude to: + +- **Determine the right impact level** using GovRAMP's Data Classification Tool logic + (Low, Low+, Moderate, Moderate with CJIS Overlay, High) +- **Select the right authorization pathway**: Core, Ready, Authorized, Provisionally + Authorized, Progressing Snapshot, or Fast Track for FedRAMP-authorized providers +- **Conduct readiness and gap assessments** against a structured 100+ item checklist + across all NIST 800-53 Rev 5 control domains +- **Guide SSP documentation**: authorization boundary, control implementation statements, + architecture diagrams, appendices (IRP, CP, POA&M) +- **Map the 60 Core controls** from the MITRE ATT&CK-aligned Moderate baseline for + the GovRAMP Core status pathway (launched May 2025) +- **Support continuous monitoring (ConMon)** obligations: monthly deliverables for + Ready/Authorized, quarterly for Core, annual assessment requirements, POA&M management +- **Explain the Fast Track** pathway for providers with existing FedRAMP authorization +- **Provide TX-RAMP reciprocity guidance** — GovRAMP Authorized products automatically + qualify for TX-RAMP + +The skill is current as of April 2026, incorporating the January 2026 Progressing +Snapshot Program changes, the GovRAMP Core status launch (May 2025), and the +February 2026 Rev 5 template updates. + +--- + +## Intended Audiences + +| Audience | How They Benefit | +|---|---| +| **Cloud Service Providers (CSPs)** | Navigate the authorization process, select the right pathway, write SSP narratives, manage POA&M, prepare for 3PAO assessments | +| **ISSOs / Security Engineers** | Map NIST 800-53 Rev 5 controls to implementations, identify gaps, manage ConMon activities | +| **Compliance Managers / GRC Teams** | Understand GovRAMP requirements, track remediation SLAs, coordinate documentation | +| **Cloud Architects** | Design systems that satisfy GovRAMP requirements; understand boundary scoping | +| **State / Local Government Officials** | Understand what to expect from a CSP's authorization, evaluate the APL, adopt GovRAMP for procurement | +| **3PAO Assessors** | Reference control family requirements, GovRAMP-specific test procedures, and document structure expectations | +| **Consultants / Advisory Firms** | Provide accurate GovRAMP guidance to SLED-facing clients across impact levels and authorization phases | +| **Small Business Providers** | Navigate GovRAMP with limited resources; understand Core as an accessible entry point | + +--- + +## Common Use Cases + +### 1. Impact Level Determination +> *"Our SaaS product handles voter registration data for a county clerk's office. What GovRAMP impact level do we need?"* + +The skill applies FIPS 199 categorization logic and GovRAMP data classification principles +to recommend Low+, Moderate, or High, and explains whether the CJIS Overlay applies. + +### 2. Pathway Selection +> *"We're a startup with limited budget. We can't afford a 3PAO right now but want to be on the GovRAMP APL. What are our options?"* + +The skill explains GovRAMP Core (60 controls, PMO-reviewed, no 3PAO required, launched +May 2025) as the most accessible verified status, and compares it against the +Progressing Snapshot for even earlier-stage providers. + +### 3. Fast Track for FedRAMP-Authorized Providers +> *"We're already FedRAMP Moderate authorized. How do we get GovRAMP status quickly?"* + +The skill walks through the Fast Track pathway: submitting existing federal security +documentation to the GovRAMP PMO, 90-day ConMon data requirements, and what GovRAMP- +specific templates may still be needed. + +### 4. Gap Assessment +> *"We're a mid-size SaaS company targeting GovRAMP Authorized Moderate. Help us assess our readiness."* + +The skill guides a structured gap assessment across all control domains, producing a +prioritized gap table with status, gap description, and recommended next steps. + +### 5. SSP Control Narrative Writing +> *"Help me write the GovRAMP control implementation statement for AC-2 (Account Management)."* + +The skill generates reviewer-ready prose that addresses every verb in the control +requirement, distinguishes provider vs. customer responsibilities, and references +specific tools and policies. + +### 6. POA&M Entry Creation +> *"Our vulnerability scan flagged a critical CVE on one of our app servers. Help me build the POA&M entry."* + +The skill produces a complete POA&M row: finding ID, control affected, risk rating, +remediation plan, owner, milestone dates, and SLA calculation (30 days for Critical). + +### 7. Continuous Monitoring Guidance +> *"We just got GovRAMP Authorized status. What do we need to submit every month?"* + +The skill explains all monthly ConMon deliverables: scan results (OS, DB, web app), +POA&M update, asset inventory update, and monthly summary report, with references to +the GovRAMP Continuous Monitoring Guide. + +### 8. TX-RAMP Reciprocity +> *"We serve Texas state agencies. Do we need TX-RAMP separately?"* + +The skill explains that TX-RAMP automatically recognizes GovRAMP-authorized products, +with GovRAMP providing a weekly sync. Once GovRAMP Authorized, no separate TX-RAMP +process is required. + +### 9. CJIS Overlay Guidance +> *"A police department wants to use our platform to manage evidence photos. What additional requirements apply?"* + +The skill explains the GovRAMP Moderate Impact with CJIS Overlay: additional FBI CJIS +Security Policy requirements, the dedicated Service Provider and 3PAO packages, and +data isolation requirements for Criminal Justice Information. + +### 10. Government Adoption Guidance +> *"We're a state IT office considering requiring GovRAMP for all cloud procurements. How do we get started?"* + +The skill explains the GovRAMP adoption roadmap for government organizations, the APL +procurement workflow, ConMon portal access for ongoing oversight, and committee/working +group participation opportunities. + +--- + +## Skill Coverage + +| Topic | Covered | +|-------|---------| +| GovRAMP background & governance | Yes | +| Impact levels: Low, Low+, Moderate, CJIS, High | Yes | +| Progressing Snapshot Program (including Jan 2026 changes) | Yes | +| GovRAMP Core status (launched May 2025; 60 controls) | Yes | +| GovRAMP Ready status | Yes | +| GovRAMP Authorized / Provisionally Authorized | Yes | +| Fast Track for FedRAMP-authorized providers | Yes | +| TX-RAMP reciprocity | Yes | +| NIST 800-53 Rev 5 control families (all 20) | Yes | +| Core 60-control set with MITRE ATT&CK alignment | Yes | +| SSP writing guidance | Yes | +| IRP and CP requirements | Yes | +| POA&M management and SLAs | Yes | +| Vulnerability scanning requirements | Yes | +| Penetration testing guidance | Yes | +| Continuous monitoring (monthly, quarterly, annual) | Yes | +| ConMon escalation process | Yes | +| Incident reporting procedures | Yes | +| Government sponsorship and Approvals Committee | Yes | +| GovRAMP membership and pricing | Yes | +| Authorization boundary guidance | Yes | +| CJIS Overlay requirements | Yes | +| Cross-framework alignment (FedRAMP, SOC 2, ISO 27001, NIST CSF) | Yes | +| Common findings and pitfalls | Yes | + +--- + +## Installation + +This skill can be installed in Claude using the `.skill` file format. The skill +archive contains: + +``` +govramp/ +├── SKILL.md Main skill instructions +└── references/ + ├── readiness-checklist.md 100+ item readiness checklist + ├── status-pathways.md Status pathway decision guide + ├── ssp-guide.md SSP section-by-section writing guide + ├── conmon-guide.md Continuous Monitoring guide + └── control-mapping.md NIST 800-53 Rev 5 control mapping +``` + +--- + +## Source and Accuracy + +All GovRAMP-specific information in this skill is sourced from official GovRAMP +materials published at https://govramp.org, including: + +- https://govramp.org/about-us/ +- https://govramp.org/providers/ +- https://govramp.org/providers/core/ +- https://govramp.org/providers/ready-or-authorized-process/ +- https://govramp.org/providers/authorized/ +- https://govramp.org/providers/progressing-snapshot/ +- https://govramp.org/providers/fast-track/ +- https://govramp.org/governments/ +- https://govramp.org/rev-5-templates-and-resources/ + +NIST 800-53 Rev 5 control information is sourced from the official NIST publication. + +> **Disclaimer:** This skill is for informational and educational purposes only and +> does not constitute official GovRAMP authorization guidance. Always engage the +> GovRAMP PMO (pmo@govramp.org) and, where required, a GovRAMP-approved 3PAO for +> official assessment and authorization activities. GovRAMP is not endorsed by or +> affiliated with FedRAMP or the United States Government. diff --git a/GovRAMP - Claude Skill/govramp.skill b/GovRAMP - Claude Skill/govramp.skill new file mode 100644 index 0000000..ec0b739 Binary files /dev/null and b/GovRAMP - Claude Skill/govramp.skill differ diff --git a/ISO 22301 - Claude Skill/ISO-22301-README.md b/ISO 22301 - Claude Skill/ISO-22301-README.md new file mode 100644 index 0000000..e36cef3 --- /dev/null +++ b/ISO 22301 - Claude Skill/ISO-22301-README.md @@ -0,0 +1,260 @@ +# ISO 22301 Business Continuity Management System Skill + +> A Claude skill for business continuity teams and risk professionals to implement, +> audit, and maintain a Business Continuity Management System (BCMS) under ISO 22301:2019. + +--- + +## 1. What Does the Skill Do? + +The ISO 22301 skill turns Claude into an expert ISO 22301 Lead Auditor and BCMS implementation +consultant. It provides structured, audit-ready guidance across the full business continuity +lifecycle — from initial gap assessment and Business Impact Analysis (BIA) through to BC +strategy design, plan authoring, exercise programmes, and certification readiness. + +The skill is built on **ISO 22301:2019** (Security and resilience — Business continuity +management systems — Requirements), the current version of the international standard published +by ISO/TC 292. It understands all mandatory clauses (4–10), all mandatory documented information +requirements, and the operational methodology for BIA, risk assessment, BC strategy, and +exercising. + +Outputs are matched to task type: structured gap analysis tables, full BCP documents with +activation procedures, BIA assessment forms, risk registers, exercise plans, management review +records, and certification readiness checklists. + +--- + +## 2. Intended Audiences + +This skill is designed for professionals responsible for business continuity management across +any sector. It is most useful for: + +- **Business Continuity Managers** implementing or maintaining a BCMS for the first time or + refreshing an existing programme +- **Risk Managers** integrating BC into the wider enterprise risk framework +- **Compliance and Audit professionals** performing BCMS gap assessments or preparing for + ISO 22301 certification audits +- **IT Directors and DR teams** aligning IT Disaster Recovery with the broader BCMS requirement +- **Consultants** supporting organisations through BCMS scoping, BIA, strategy, planning, and + certification +- **Operations Leaders** seeking to understand their continuity obligations and recovery + objectives (RTO, RPO, MBCO) + +--- + +## 3. Common Use Cases + +| Use Case | Example Prompt | +|----------|---------------| +| **Gap analysis** | "Perform a gap analysis of our BCMS against ISO 22301:2019. We have a scope statement and policy but no formal BIA or tested plans." | +| **BIA support** | "Help me conduct a BIA for our order management function. The team of 8 processes 500 orders per day using our ERP system." | +| **Recovery parameter advice** | "Our regulator requires all customer transactions to be processed within 24 hours. What RTO and RPO should we set for our order processing activity?" | +| **BC strategy design** | "Our BIA shows our CRM system has an RTO of 4 hours and RPO of 1 hour. What BC strategies should we consider?" | +| **BCP authoring** | "Write a Business Continuity Plan for our finance department covering the payment processing activity. MBCO is 100% of daily payment runs within 4 hours." | +| **Incident Response Plan** | "Write an Incident Response Plan structure with level-based escalation, CMT roles, and communication procedures." | +| **Exercise planning** | "Plan a tabletop exercise to test our IT failure response. I need participants, scenario, objectives, and success criteria." | +| **Certification readiness** | "What mandatory documents must we have in place before a Stage 1 ISO 22301:2019 audit?" | +| **Management review prep** | "What inputs and outputs does ISO 22301:2019 require for a management review? Generate an agenda template." | +| **Policy generation** | "Write a Business Continuity Policy for our company that satisfies Clause 5.2 of ISO 22301:2019." | +| **Terminology explanation** | "Explain the difference between MTPD, RTO, RPO, and MBCO in the context of ISO 22301." | + +--- + +## 4. Key Concepts Covered + +### The BCMS Lifecycle + +The ISO 22301:2019 standard structures the BCMS around a Plan-Do-Check-Act (PDCA) cycle +embedded within the High Level Structure (Clauses 4–10): + +``` +PLAN DO CHECK ACT +Context (Cl.4) --> BIA + Risk (Cl.8.2) --> Monitor (Cl.9.1) --> Improve (Cl.10) +Leadership (Cl.5) --> BC Strategy (Cl.8.3) --> Audit (Cl.9.2) +Planning (Cl.6) --> BC Plans (Cl.8.4) --> Mgmt Review (Cl.9.3) +Support (Cl.7) --> Exercises (Cl.8.5) +``` + +### Key ISO 22301 Terms + +| Term | Meaning | +|------|---------| +| **MTPD** | Maximum Tolerable Period of Disruption — the hard deadline: recovery must happen before this point or the organisation faces unacceptable consequences | +| **RTO** | Recovery Time Objective — the target time to resume an activity after a disruption; must be less than MTPD | +| **RPO** | Recovery Point Objective — how much data loss is acceptable; drives backup and replication strategy | +| **MBCO** | Minimum Business Continuity Objective — the minimum level of service needed at recovery; enables phased restoration | +| **BIA** | Business Impact Analysis — the process of identifying critical activities, assessing disruption impacts, and setting RTO/RPO/MBCO | +| **BCMS** | Business Continuity Management System — the complete management framework for BC capability | +| **Disruption** | Any incident causing an unplanned negative deviation from expected service delivery | +| **IRP** | Incident Response Plan — the plan for detecting, declaring, and managing an incident to activate BC arrangements | + +### The BIA → Strategy → Plan Chain + +ISO 22301 is explicit that BCMS design must follow a defined chain: + +1. **BIA** (Clause 8.2.2): identifies critical activities and sets RTOs, RPOs, MBCO +2. **Risk assessment** (Clause 8.2.3): identifies threats to those activities +3. **BC strategy** (Clause 8.3): defines how identified risks are treated and how RTOs will be achieved +4. **BC plans** (Clause 8.4): implements the strategy in operational procedures +5. **Exercises** (Clause 8.5): validates that the plans work and RTOs are achievable + +A BCMS that has plans but no BIA, or has strategies that were never linked to BIA outputs, +will fail an ISO 22301 certification audit. The skill enforces this chain in its outputs. + +--- + +## 5. Clause Structure at a Glance + +| Clause | Title | Key Deliverables | +|--------|-------|-----------------| +| 4 | Context of the Organisation | BCMS scope statement, interested party register | +| 5 | Leadership | BC policy (signed), roles and responsibilities | +| 6 | Planning | BC objectives and plans, actions to address risks | +| 7 | Support | Competence records, communication plan, documented information procedures | +| 8 | Operation | BIA, risk assessment, BC strategies, BCPs, IRP, exercise programme, test records | +| 9 | Performance Evaluation | KPI monitoring, internal audit programme and results, management review minutes | +| 10 | Improvement | Nonconformity register, corrective action records, improvement log | + +--- + +## 6. Mandatory Documentation Summary + +ISO 22301:2019 requires the following documented information as a minimum: + +| Document | Clause | +|----------|--------| +| BCMS scope statement | 4.3 | +| Business continuity policy | 5.2 | +| BC objectives and plans to achieve them | 6.2 | +| Evidence of competence | 7.2 | +| BIA results | 8.2.2 | +| Risk assessment results | 8.2.3 | +| BC strategies and solutions | 8.3.3 | +| Resource requirements | 8.3.4 | +| Incident response structure / procedures | 8.4.2 | +| Communication procedures | 8.4.3 | +| Business continuity plans | 8.4.4 | +| Recovery procedures | 8.4.5 | +| Exercise programme | 8.5.1 | +| Exercise results | 8.5.1 | +| IT / technical test results | 8.5.2 | +| Monitoring and measurement results | 9.1 | +| Internal audit programme and results | 9.2 | +| Management review record | 9.3 | +| Nonconformities and corrective actions | 10.1 | + +--- + +## 7. How to Use the Skill + +Once installed, the skill activates automatically when you ask about ISO 22301, BCMS, BIA, +Business Continuity Plans, Recovery Time Objectives, or related topics. You do not need to +reference the skill by name. + +### Tips for Best Results + +**Provide organisational context** — even brief context helps Claude tailor its output. +For example: +> "We are a 300-person financial services firm processing payments for retail customers. +> Help me conduct a BIA for our payment processing function." + +**Be specific about the clause or task** — naming the clause or task type produces +more targeted responses: +> "I need help with Clause 8.3 — what BC strategies can we consider for an activity +> with a 4-hour RTO and a 1-hour RPO?" + +**Iterate through the BIA → Strategy → Plan chain** — work through the methodology +in sequence for the best results: +1. Start with BIA to establish RTOs and priorities +2. Use BIA outputs to drive strategy selection +3. Use strategy to inform BCP content + +**Ask for templates when you need starting points** — the skill can generate +gap analysis tables, BIA forms, risk registers, exercise plans, BCP documents, +management review agendas, and corrective action records. + +### Example Interaction + +``` +You: We have a 50-person professional services company. We have never done a + formal BIA. Where do we start with ISO 22301:2019? + +Claude: [Explains the BIA process (Clause 8.2.2), scoping considerations, and + provides a step-by-step approach: + 1. Define BCMS scope and products/services in scope + 2. Identify activities supporting each in-scope service + 3. Set up standard impact categories and time horizons + 4. Conduct workshops with process owners + 5. Determine MTPD, RTO, RPO, and MBCO for each activity + 6. Map dependencies (people, IT, premises, suppliers) + 7. Produce prioritised BIA output to drive strategy selection] + +You: Generate a BIA form for my customer invoicing activity. MTPD is 48 hours. + +Claude: [Produces a completed BIA form with: + - Impact heat map with time horizons up to 48 hours + - MTPD set at 48 hours with justification + - Suggested RTO of 24-32 hours + - RPO and MBCO fields to complete + - People, technology, premises, and supplier dependency tables] +``` + +--- + +## 8. Skill Implementation Details + +### Plugin Location + +``` +plugins/iso22301/ +├── .claude-plugin/ +│ └── plugin.json +└── skills/ + └── iso22301/ + ├── SKILL.md + └── references/ + ├── iso22301-clauses.md (full clause requirements reference) + ├── iso22301-bia-guide.md (BIA methodology, time horizons, dependency mapping) + ├── iso22301-bcps.md (BCP structure, IRP, communication templates, IT DRP) + └── iso22301-templates.md (ready-to-use policy, BIA form, risk register, exercise plan templates) +``` + +### Reference Files + +| File | Contents | +|------|----------| +| `iso22301-clauses.md` | Full clause-by-clause requirements with mandatory documentation list | +| `iso22301-bia-guide.md` | Complete BIA methodology: scoping, data collection, impact analysis, dependency mapping, reporting | +| `iso22301-bcps.md` | Plan architecture, IRP content, BCP template, IT DRP essentials, communication templates | +| `iso22301-templates.md` | BC policy, scope statement, BIA form, risk register, exercise plan, after-action report, management review record, nonconformity record, audit plan, competence matrix | + +--- + +## 9. About ISO 22301:2019 + +ISO 22301:2019 was published by the International Organization for Standardization (ISO) in +October 2019 through Technical Committee ISO/TC 292 (Security and resilience). It replaced +ISO 22301:2012 and is the current edition of the standard. + +The standard is applicable globally to any organisation in any sector that wishes to build +and demonstrate a systematic capability to recover from disruptive incidents. It can be used +as the basis for third-party certification by an accredited certification body under IAF +(International Accreditation Forum) recognised schemes. + +ISO 22301:2019 aligns to the ISO High Level Structure (Annex SL), enabling integrated +implementation alongside ISO 27001:2022, ISO 9001:2015, ISO 14001:2015, and ISO 42001:2023. + +For questions about ISO 22301:2019 as a standard, the definitive source is the ISO +publication available at [iso.org](https://www.iso.org/standard/75106.html) and supporting +guidance available in ISO 22313:2020 (Security and resilience — Business continuity +management systems — Guidance on the use of ISO 22301). + +--- + +## 10. Disclaimer + +This skill provides guidance based on the published requirements of ISO 22301:2019 and +accepted business continuity management practices. It is intended to support qualified +practitioners and should not replace the judgement of a certified professional in the context +of a specific organisation. For formal conformance assessments and certification, engage an +accredited ISO 22301 certification body and qualified lead auditor. diff --git a/ISO 22301 - Claude Skill/iso22301.skill b/ISO 22301 - Claude Skill/iso22301.skill new file mode 100644 index 0000000..9daadb2 Binary files /dev/null and b/ISO 22301 - Claude Skill/iso22301.skill differ diff --git a/ISO 27017 - Claude Skill/ISO-27017-README.md b/ISO 27017 - Claude Skill/ISO-27017-README.md new file mode 100644 index 0000000..48e7788 --- /dev/null +++ b/ISO 27017 - Claude Skill/ISO-27017-README.md @@ -0,0 +1,151 @@ +# ISO 27017 — Claude Skill + +> ISO/IEC 27017:2015 Cloud Security Controls Advisor for Claude + +This Claude skill provides expert guidance on **ISO/IEC 27017:2015** — the international code of +practice for information security controls specific to cloud computing environments. The skill +supports both cloud service providers (CSPs) and cloud service customers (CSCs). + +--- + +## What This Skill Does + +The ISO 27017 skill enables Claude to act as an expert cloud security compliance advisor with +deep knowledge of: + +- The 7 additional cloud-specific CLD controls introduced by ISO 27017 +- ISO 27002:2013 controls with cloud-specific implementation guidance for CSPs and CSCs +- Shared responsibility models across IaaS, PaaS, and SaaS service models +- Cloud service agreement security requirements and review +- Virtual machine hardening and virtualisation security +- Cloud asset management including data return and deletion +- Cloud administrator operational security +- Cloud monitoring and incident response + +--- + +## Trigger Phrases + +This skill activates for questions including: + +- "ISO 27017", "ISO/IEC 27017", "cloud security controls" +- "shared responsibility model" in a compliance or cloud context +- Questions about CLD controls (CLD.6.3.1, CLD.8.1.5, CLD.9.5.1, CLD.9.5.2, CLD.12.1.5, CLD.12.4.5, CLD.13.1.4) +- "cloud service agreement security", "data deletion in cloud", "cloud asset removal" +- "virtual machine hardening", "VM security", "tenant isolation", "hypervisor security" +- "cloud administrator security", "cloud monitoring requirements" +- "gap analysis" for cloud security controls +- "CSP obligations", "CSC responsibilities", "cloud security policy" + +--- + +## Standard Overview + +| Attribute | Detail | +|-----------|--------| +| Full title | ISO/IEC 27017:2015 — Code of practice for information security controls based on ISO/IEC 27002 for cloud services | +| Published | December 2015 | +| Issuing body | ISO/IEC JTC 1/SC 27 | +| Based on | ISO/IEC 27002:2013 | +| Cloud-specific additions | 7 additional CLD controls | +| Applicability | Cloud Service Providers (CSPs) and Cloud Service Customers (CSCs) | +| Companion standards | ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27018 | + +--- + +## The 7 Cloud-Specific Controls (CLD) + +| Control | Name | Applies To | +|---------|------|------------| +| CLD.6.3.1 | Shared roles and responsibilities | Both CSP and CSC | +| CLD.8.1.5 | Removal or return of cloud service customer assets | Both CSP and CSC | +| CLD.9.5.1 | Segregation in virtual computing environments | CSP (primary) | +| CLD.9.5.2 | Virtual machine hardening | Both CSP and CSC | +| CLD.12.1.5 | Administrator's operational security | CSP (primary) | +| CLD.12.4.5 | Monitoring of cloud services | Both CSP and CSC | +| CLD.13.1.4 | Alignment of security management for virtual and physical networks | CSP (primary) | + +--- + +## Skill Contents + +``` +iso27017/ +├── SKILL.md Main skill definition and workflows +└── references/ + ├── cloud-controls.md Detailed guidance on all 7 CLD controls + ├── iso27002-cloud-guidance.md 37 ISO 27002 controls with cloud-specific guidance + ├── shared-responsibility.md Shared responsibility matrix: IaaS/PaaS/SaaS + └── templates.md Gap analysis, CSA review, policy, and hardening templates +``` + +--- + +## Installation + +### Via Claude Code (recommended) + +```bash +claude mcp install iso27017.skill +``` + +### Manual Installation + +1. Download `iso27017.skill` +2. In Claude Code, run: `claude skills install ./iso27017.skill` +3. The skill will be available immediately + +--- + +## Usage Examples + +**Gap analysis:** +> "Perform an ISO 27017 gap analysis for our AWS environment. We are a cloud service customer +> using IaaS services." + +**Shared responsibility:** +> "Map the shared responsibility for ISO 27017 controls between us (the CSC) and our SaaS provider." + +**CLD control guidance:** +> "Explain what CLD.12.1.5 requires and how we should implement it for our cloud administrators." + +**Cloud service agreement review:** +> "Review this cloud service agreement and identify what's missing for ISO 27017 compliance." + +**Policy generation:** +> "Draft a cloud security policy for our organisation aligned to ISO 27017." + +**VM hardening:** +> "What does CLD.9.5.2 require for virtual machine hardening? Give me implementation steps." + +--- + +## Relationship to Other Standards + +| Standard | Relationship | +|----------|-------------| +| ISO/IEC 27001:2022 | ISMS requirements framework — ISO 27017 provides cloud-specific control guidance to implement within an ISO 27001 ISMS | +| ISO/IEC 27002:2013 | Base control set — ISO 27017 supplements these controls with cloud-specific guidance | +| ISO/IEC 27018:2019 | Companion standard — extends ISO 27002 specifically for processing PII in cloud | +| ISO/IEC 27001 + 27017 | Organisations seeking cloud-focused ISMS typically implement both; ISO 27001 certification with ISO 27017 extension | + +--- + +## Important Notes + +- ISO 27017 is a **code of practice**, not a certification standard. Organisations are certified + against ISO 27001, with ISO 27017 providing additional implementation guidance for cloud. +- The standard uses ISO 27002:2013 control numbering. When ISO 27002 was revised in 2022, + ISO 27017 was not simultaneously updated to align with the new numbering. +- Always seek professional legal and compliance advice before finalising cloud service agreements + or submitting compliance assessments. + +--- + +## License + +MIT — See [LICENSE](../LICENSE) in the repository root. + +## Author + +Hemant Naik — [Sushegaad GRC Skills](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance) diff --git a/ISO 27017 - Claude Skill/iso27017.skill b/ISO 27017 - Claude Skill/iso27017.skill new file mode 100644 index 0000000..4101a3e Binary files /dev/null and b/ISO 27017 - Claude Skill/iso27017.skill differ diff --git a/ISO 31000 - Claude Skill/ISO-31000-README.md b/ISO 31000 - Claude Skill/ISO-31000-README.md new file mode 100644 index 0000000..061fab6 --- /dev/null +++ b/ISO 31000 - Claude Skill/ISO-31000-README.md @@ -0,0 +1,150 @@ +# ISO 31000 Risk Management — Claude Skill + +> A Claude skill for risk, compliance, and operations teams to design risk management frameworks, conduct risk assessments, build risk registers, and develop risk treatment plans aligned to ISO 31000:2018. + +--- + +## 1. What Does the Skill Do? + +The ISO 31000 skill turns Claude into an expert ISO 31000:2018 Risk Management consultant. It provides structured, practical guidance across the full lifecycle of enterprise risk management — from initial framework gap assessment through risk identification, analysis, evaluation, and treatment. + +The skill covers the full **ISO 31000:2018** standard: +- **Clause 4 — Principles**: All 8 principles of effective risk management +- **Clause 5 — Framework**: Leadership & commitment, integration, design, implementation, evaluation, and improvement (5.1–5.6) +- **Clause 6 — Process**: Communication & consultation, scope/context/criteria, risk assessment (identification, analysis, evaluation), risk treatment, monitoring & review, recording & reporting (6.2–6.7) + +It also covers the integration of ISO 31000 with ISO 27001, ISO 9001, ISO 42001, ISO 14001, ISO 45001, NIST CSF, and COSO ERM. + +Outputs are tailored to the task: risk framework gap analysis tables with 🔴/🟡🟢 status, complete risk management policies with document control blocks, risk registers with 5×5 likelihood × consequence scoring, risk treatment plans with owner/date/KPI fields, risk appetite statements with category-level tolerance thresholds, board risk reports, and risk workshop facilitation guides. + +--- + +## 2. Intended Audiences + +This skill is designed for **risk, compliance, and operations teams** working on risk management implementation, maturity improvement, and integration with other management systems. It is most useful for: + +- **Chief Risk Officers (CROs)** and **Risk Managers** designing or maturing enterprise risk management programmes +- **Compliance and assurance teams** embedding risk management into ISO 27001, ISO 9001, or other management systems +- **Board secretaries and governance professionals** preparing board risk reports and risk appetite statements +- **Project managers** needing structured risk assessment for major initiatives +- **Internal auditors** reviewing the risk management framework and risk register quality +- **Consultants** supporting clients through first-time ISO 31000 framework implementation +- **Operations managers** assessing and treating operational risks at the process level + +--- + +## 3. Common Use Cases + +| Use Case | Example Prompt | +|----------|---------------| +| **Framework gap analysis** | "Assess our current risk management programme against ISO 31000:2018 and identify the key gaps." | +| **Risk register development** | "Help me build a risk register for our fintech startup covering strategic, financial, cyber, and regulatory risks." | +| **Risk treatment plan** | "Generate a risk treatment plan for our top 5 critical risks from the attached risk register." | +| **Risk appetite statement** | "Write a risk appetite statement for a healthcare organisation with category tolerances for compliance, cyber, and operational risk." | +| **Risk workshop facilitation** | "Help me plan and facilitate a risk identification workshop for our supply chain operations team." | +| **Risk management policy** | "Write a Risk Management Policy for a 500-person professional services firm aligned to ISO 31000:2018." | +| **Framework design** | "How do I design and implement an ISO 31000-compliant risk management framework for a newly established NHS trust?" | +| **Risk criteria definition** | "Help me define a 5×5 likelihood and consequence scale calibrated for a mid-sized logistics business." | +| **Integration question** | "How does ISO 31000 relate to ISO 27001 Clause 6.1? Can I use a single risk register for both?" | +| **Board risk report** | "Generate a quarterly board risk report template following ISO 31000 reporting principles." | +| **Monitoring and review** | "What should our quarterly risk review process look like? What records do we need to keep?" | +| **FMEA / Bowtie** | "Walk me through a bowtie analysis for our main production process." | + +--- + +## 4. How to Use the Skill + +Once the skill is installed in Claude, it activates automatically whenever you ask about ISO 31000, risk management frameworks, risk registers, risk treatment, risk appetite, or related enterprise risk management topics. You do not need to reference the skill by name. + +### Tips for best results + +**Provide your organisational context** — sector, size, and current risk maturity level (ad hoc / defined / managed / optimised) help the skill tailor outputs. For example: + +> "We're a 300-person SaaS company with no formal risk management programme. Help us design an ISO 31000-aligned framework from scratch." + +**Specify the task type clearly** — the skill adapts its output format based on what you need (gap analysis vs. risk register vs. policy). Be direct: + +> "Run a gap analysis of our risk management framework against ISO 31000:2018 Clause 5 (Framework)." + +**Reference specific clauses when relevant** — for precise guidance, citing the clause number produces more targeted responses: + +> "We need help with Clause 6.3 — how should we define our risk criteria for a financial services firm?" + +**Provide your existing risk register or controls list** when asking for analysis or treatment planning — this produces more actionable, specific outputs than a blank-slate response. + +### Example interaction + +``` +You: Help me build a risk register for our logistics company. We have about 50 staff + and provide last-mile delivery services. We've never done a formal risk assessment. + +Claude: [Generates a populated risk register with: + - 15–20 risks across strategic, financial, operational, cyber, compliance, + and people categories calibrated to a logistics SME + - Likelihood and consequence scoring with inherent and residual scores + - Treatment option recommendations for high/critical risks + - Suggested risk owners and review dates + - Notes on how to adapt the register as the business grows] +``` + +--- + +## 5. Skill Implementation Details + +### Architecture + +``` +iso31000/ +├── SKILL.md # Core skill logic and workflows +└── references/ + ├── iso31000-framework.md # Clause 5 framework deep-dive + ├── iso31000-risk-assessment-process.md # Clause 6 risk assessment guidance + └── iso31000-risk-treatment.md # Risk treatment, appetite, monitoring +``` + +`SKILL.md` is loaded into Claude's context whenever the skill triggers. Reference files are loaded on demand — only the relevant file(s) are loaded per task — keeping the context window efficient. + +### What's in SKILL.md + +- **Persona**: Claude adopts the role of an ISO 31000:2018 Risk Management consultant +- **Output format matrix**: Maps each task type to the appropriate format (table, document, narrative) +- **8 ISO 31000 principles**: Full table with practical descriptions and assessment guidance +- **Framework (Clause 5)**: Six framework components (5.1–5.6) with key outputs and gaps +- **Risk management process (Clause 6)**: All 8 process activities with templates and guidance +- **5 core workflows**: Gap analysis, risk register development, risk appetite statement, risk workshop facilitation, policy/procedure generation +- **Integration mapping table**: How ISO 31000 relates to ISO 27001, ISO 9001, ISO 42001, NIST CSF, and COSO ERM +- **Reference file loading logic**: Rules for when to load each reference file + +### What's in the reference files + +| File | Contents | +|------|----------| +| `iso31000-framework.md` | Full Clause 5 framework (5.1–5.6): design checklists, integration maturity levels, RACI template, implementation roadmap, framework KPIs, framework evaluation criteria | +| `iso31000-risk-assessment-process.md` | Full Clause 6 assessment process: scope/criteria templates, PESTLE/SWOT, 7 risk identification techniques (brainstorm, FMEA, bowtie, SIPOC, taxonomy checklist), 5×5 matrix, inherent/residual analysis, risk evaluation decision rules, full risk register template, stakeholder consultation plan | +| `iso31000-risk-treatment.md` | All 5 treatment options with selection guidance, full risk treatment plan template, treatment decision framework, risk appetite statement template, control effectiveness ratings, monitoring schedule, control testing programme, board/executive reporting formats, recording obligations | + +### Inputs used to build the skill + +- **ISO 31000:2018** — Principles, framework (Clauses 5.1–5.6), and process (Clauses 6.2–6.7) +- **ISO 31010:2019** — Risk assessment techniques reference (FMEA, bowtie, PESTLE, SWOT, fault tree analysis, Monte Carlo) +- **ISO Guide 73:2009** — Risk management vocabulary (risk, risk appetite, risk tolerance, risk criteria, inherent/residual risk definitions) +- **ISO Annex SL mapping** — How ISO 31000 risk provisions align with ISO 27001:2022, ISO 9001:2015, ISO 42001:2023, ISO 14001:2015, ISO 45001:2018 +- **COSO ERM 2017** — Integration points and terminology alignment +- **Common enterprise risk practice** — Likelihood × consequence scaling, risk appetite frameworks, board risk reporting formats, risk register structures, treatment plan templates + +### Skill trigger phrases + +The skill activates on any of the following topics (non-exhaustive): + +`ISO 31000` · `risk management framework` · `risk assessment` · `risk register` · `risk treatment` · `risk appetite` · `risk tolerance` · `risk criteria` · `inherent risk` · `residual risk` · `risk identification` · `risk analysis` · `risk evaluation` · `risk treatment plan` · `likelihood × consequence` · `risk heatmap` · `risk workshop` · `bowtie analysis` · `FMEA` · `enterprise risk management` · `ERM` · `operational risk` · `strategic risk` · `risk monitoring` · `board risk report` · `risk appetite statement` + +--- + +## 6. Author + +**Skill designed by:** Hemant Naik +[LinkedIn](https://www.linkedin.com/in/tanaji-naik/) · [hemant.naik@gmail.com](mailto:hemant.naik@gmail.com) +**Built with:** Claude (Anthropic) using the Claude Skills framework +**Date:** April 2026 +**Skill version:** 0.1.0 +**Standard coverage:** ISO 31000:2018 — Risk management — Guidelines diff --git a/ISO 31000 - Claude Skill/iso31000.skill b/ISO 31000 - Claude Skill/iso31000.skill new file mode 100644 index 0000000..a857ca6 Binary files /dev/null and b/ISO 31000 - Claude Skill/iso31000.skill differ diff --git a/plugins/cmmc/.claude-plugin/plugin.json b/plugins/cmmc/.claude-plugin/plugin.json new file mode 100644 index 0000000..9fcebf1 --- /dev/null +++ b/plugins/cmmc/.claude-plugin/plugin.json @@ -0,0 +1,28 @@ +{ + "name": "cmmc", + "description": "CMMC 2.0 compliance advisor for defense contractors — Level 1/2/3 gap analysis, scoping, SPRS scoring, SSP documentation, POA&M development, C3PAO assessment preparation, and NIST 800-171/800-172 practice guidance for organizations protecting FCI and CUI under DoD contracts.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "cmmc", + "cmmc-2.0", + "dod", + "defense-contractor", + "dib", + "cui", + "fci", + "nist-800-171", + "nist-800-172", + "c3pao", + "sprs", + "dfars", + "cybersecurity", + "certification" + ] +} diff --git a/plugins/cmmc/skills/cmmc/SKILL.md b/plugins/cmmc/skills/cmmc/SKILL.md new file mode 100644 index 0000000..e45a41f --- /dev/null +++ b/plugins/cmmc/skills/cmmc/SKILL.md @@ -0,0 +1,357 @@ +--- +name: cmmc +description: > + Expert CMMC 2.0 compliance advisor for defense contractors and subcontractors. Use this skill + whenever a user asks about CMMC (Cybersecurity Maturity Model Certification) 2.0, DoD contractor + cybersecurity, CUI (Controlled Unclassified Information) protection, FCI (Federal Contract + Information), DFARS 252.204-7012, DFARS 252.204-7019, DFARS 252.204-7020, DFARS 252.204-7021, + NIST SP 800-171, NIST SP 800-172, CMMC Level 1, CMMC Level 2, CMMC Level 3, C3PAO assessments, + CMMC scoping, System Security Plan (SSP) for CMMC, POA&M for CMMC, Annual Affirmations, + SPRS (Supplier Performance Risk System) scores, DIBNet portal, or any question about achieving + or maintaining CMMC certification for defense industrial base (DIB) companies. Also trigger for + questions about flow-down requirements, subcontractor CMMC obligations, OSC (Organization Seeking + Certification) readiness, or responding to DoD RFPs that include CMMC requirements. +--- + +# CMMC 2.0 Compliance Skill + +You are an expert CMMC 2.0 implementation consultant and certified assessment advisor with +comprehensive knowledge of the Cybersecurity Maturity Model Certification 2.0 framework, +NIST SP 800-171 Rev 2 security requirements, DoD assessment methodology, scoping guidance, +and the full CMMC ecosystem including C3PAOs, CAICO, and the Accreditation Body (Cyber-AB). + +> **Disclaimer:** This guidance is for informational and educational purposes only and does not +> constitute legal or official DoD compliance advice. CMMC certification requires formal +> assessment by a Cyber-AB authorized C3PAO (for Level 2 and 3) or a DoD authorized Lead +> Assessor (for Level 3). Always refer to the official CMMC Program documentation at +> https://dodcio.defense.gov/CMMC/ and the Cyber-AB at https://cyberab.org/ for authoritative +> requirements. + +--- + +## How to Respond + +Clarify the user's CMMC level requirement (1, 2, or 3) and whether they handle CUI, FCI, or both +before diving into detailed guidance. + +Match output to the task: + +| Task | Output Format | +|------|--------------| +| Level determination | Decision tree: contract type, data type, flow-down requirements | +| Gap analysis | Table: Domain \| Practice ID \| Practice \| Current State \| Gap \| Priority | +| Scoping guidance | Asset category table with in-scope determination for each category | +| SSP documentation | Structured narrative per practice with implementation description | +| POA&M development | Table: Practice ID \| Gap Description \| Remediation Plan \| Milestone Date \| Status | +| SPRS score calculation | Scored table of 110 practices showing -1/-3/-5 deductions | +| Policy generation | Full policy document mapped to CMMC practices | +| Assessment preparation | Domain-by-domain readiness checklist with evidence requirements | +| General question | Clear prose with CMMC practice citations and NIST 800-171 references | + +--- + +## CMMC 2.0 — Framework Overview + +### What Is CMMC 2.0? + +The Cybersecurity Maturity Model Certification (CMMC) 2.0 is a DoD program that establishes +cybersecurity requirements for entities operating within the Defense Industrial Base (DIB). +The CMMC 2.0 Final Rule (32 CFR Part 170) was published on October 15, 2024, and became +effective on **December 16, 2024**. + +CMMC 2.0 requires DoD contractors and subcontractors to implement and, depending on the level, +have assessed against cybersecurity requirements derived from well-established NIST standards. +It replaces the self-attestation-only model with mandatory third-party certification for contracts +involving sensitive federal information. + +### Regulatory Basis + +| Regulation | Purpose | +|-----------|---------| +| 32 CFR Part 170 | CMMC Program rule — establishes the framework, levels, and assessment requirements | +| DFARS 252.204-7012 | Safeguarding covered defense information; incident reporting to DoD | +| DFARS 252.204-7019 | Notice of NIST SP 800-171 DoD Assessment requirements; SPRS submission | +| DFARS 252.204-7020 | NIST SP 800-171 DoD Assessment Requirements — allows DoD to conduct assessments | +| DFARS 252.204-7021 | CMMC Requirements — prime contractor CMMC clause (included when required) | +| NIST SP 800-171 Rev 2 | 110 security requirements protecting CUI — basis for CMMC Level 2 | +| NIST SP 800-172 | Enhanced security requirements — basis for the 24 additional Level 3 practices | +| NIST SP 800-171A | Assessment methods for NIST 800-171 — used by assessors | + +### Three Levels of CMMC 2.0 + +| Level | Name | Practices | Who Assesses | Data Type | Annual Affirmation | +|-------|------|-----------|-------------|-----------|-------------------| +| 1 | Foundational | 17 | Self-assessment (annual) | FCI only | Required by senior official | +| 2 | Advanced | 110 | C3PAO (triennial) or self-assessment (if not prioritized) | CUI | Required by senior official | +| 3 | Expert | 134 | Defense Contract Management Agency (DCMA) DIBCAC | CUI (highest priority programs) | Required by senior official | + +**Key Distinctions:** +- **Level 1** maps to FAR 52.204-21 (15 practices, reduced to 17 with two duplicates per CMMC) +- **Level 2** is identical to NIST SP 800-171 Rev 2 (110 practices across 14 domains) +- **Level 3** adds 24 practices from NIST SP 800-172 on top of all 110 Level 2 practices + +--- + +## CMMC Domains and Practice Counts + +### Level 2 — 14 Domains (110 Practices) + +| Domain | Abbreviation | Practice Count | +|--------|-------------|---------------| +| Access Control | AC | 22 | +| Audit and Accountability | AU | 9 | +| Awareness and Training | AT | 3 | +| Configuration Management | CM | 9 | +| Identification and Authentication | IA | 11 | +| Incident Response | IR | 3 | +| Maintenance | MA | 6 | +| Media Protection | MP | 9 | +| Personnel Security | PS | 2 | +| Physical Protection | PE | 6 | +| Risk Assessment | RA | 3 | +| Security Assessment | CA | 4 | +| System and Communications Protection | SC | 16 | +| System and Information Integrity | SI | 7 | + +**Total: 110 practices (identical to NIST SP 800-171 Rev 2)** + +### Level 3 — Additional 24 Practices from NIST SP 800-172 + +| Domain | Additional Practice Count | +|--------|--------------------------| +| Access Control (AC) | 4 | +| Awareness and Training (AT) | 1 | +| Configuration Management (CM) | 1 | +| Identification and Authentication (IA) | 1 | +| Incident Response (IR) | 4 | +| Risk Assessment (RA) | 5 | +| Security Assessment (CA) | 3 | +| System and Communications Protection (SC) | 3 | +| System and Information Integrity (SI) | 2 | + +**Total Level 3: 134 practices (110 + 24)** + +--- + +## Reference Files + +Load the appropriate reference file(s) based on the user's request: + +| File | When to load | +|------|-------------| +| `references/level1-practices.md` | Level 1 questions, FCI protection, FAR 52.204-21, self-assessment | +| `references/level2-practices.md` | Level 2 questions, CUI protection, NIST 800-171 requirements, gap analysis | +| `references/level3-practices.md` | Level 3 questions, NIST 800-172 enhanced requirements, DIBCAC assessments | +| `references/scoping-guide.md` | Asset scoping, in-scope determination, CUI scope, network boundaries | +| `references/assessment-guide.md` | C3PAO assessment process, SPRS scoring, POA&M, evidence requirements | + +Load **all relevant files** for broad requests (e.g. "help us prepare for a Level 2 assessment"). + +--- + +## Core Workflows + +### 1. CMMC Level Determination + +When a user asks which level applies to their organization: + +1. Ask: + - What type of data is referenced in their contracts: FCI only, CUI, or both? + - Are they a prime contractor or subcontractor? + - Has the contracting officer specified a CMMC level in the solicitation? + +2. Apply decision logic: + - **FCI only (no CUI)** → Minimum Level 1 required + - **CUI present** → Level 2 minimum; Level 3 if on a DoD prioritized acquisition + - **No FCI or CUI** → CMMC may not apply; verify with contracting officer + +3. Address flow-down: + - Prime contractors must flow CMMC requirements down to subcontractors that process, + store, or transmit CUI or FCI on their behalf + - Subcontractors must meet the same level as the prime if they handle the same data + +### 2. Scoping Guidance + +When helping a user define their CMMC assessment scope, load `references/scoping-guide.md`. + +**Asset Categories (per CMMC 2.0 Scoping Guidance):** + +| Asset Category | Definition | In-Scope for CMMC? | +|---------------|-----------|-------------------| +| CUI Assets | Assets that process, store, or transmit CUI | Yes — all practices apply | +| Security Protection Assets (SPAs) | Assets that provide security functions to the CUI environment | Yes — all practices apply | +| Contractor Risk Managed Assets (CRMAs) | Assets that can reach CUI assets but do not process CUI | Yes — risk-managed; subset of practices | +| Specialized Assets | OT/ICS, IoT, government-furnished equipment, test equipment | Yes — practices applied as appropriate | +| Out-of-Scope Assets | No connection to CUI environment; isolated | No — excluded from scope | +| External Service Providers (ESPs) | Cloud services, managed services that process CUI | Flow-down required; FedRAMP or equivalence | + +### 3. Gap Analysis + +When performing a gap analysis, load `references/level2-practices.md` (or level3 if applicable). + +Output format: +``` +## CMMC Level [X] Gap Analysis + +**Organization:** [Name if provided] +**Assessment Date:** [Date] +**Data Sensitivity:** [FCI / CUI / Both] + +| Domain | Practice ID | Practice Title | Current State | Gap Description | Risk Level | Priority | +|--------|------------|----------------|---------------|-----------------|------------|----------| +| AC | 3.1.1 | Limit system access to authorized users | Implemented | None | — | — | +| AC | 3.1.2 | Limit system access to types of transactions | Partial | RBAC not fully documented | High | 1 | +... + +### Summary +- Total Practices: 110 +- Implemented: [X] +- Partial: [Y] +- Not Implemented: [Z] +- Estimated SPRS Score: [calculated] + +### Critical Gaps (Address First) +1. [Highest risk gaps] + +*Disclaimer: This analysis is informational only. Official CMMC assessment requires a C3PAO.* +``` + +### 4. SSP Documentation + +When helping draft a System Security Plan: +- Load `references/level2-practices.md` for requirement detail +- SSP must cover all 110 practices (Level 2) or 134 practices (Level 3) +- Each practice narrative should include: + - **Implementation Description** — how the practice is satisfied + - **Responsible Role** — who owns the control + - **Tools/Technologies** — what systems implement it + - **Evidence** — artifacts that demonstrate compliance + - **Date Implemented** — when it was put in place + +**Required SSP Sections:** +1. System Name and Identifier +2. System Owner and Authorizing Official +3. System Description and Purpose +4. System Boundary (narrative and diagram reference) +5. Data Types Processed (FCI/CUI with categories) +6. User Types and Privileges +7. Interconnections and External Systems +8. Applicable Laws and Regulations +9. Control Implementation Statements (per practice) +10. Continuous Monitoring Plan +11. Plan of Action and Milestones (POA&M) — separate document + +### 5. SPRS Score Calculation + +The **Supplier Performance Risk System (SPRS)** score is calculated under the NIST SP +800-171 DoD Assessment Methodology and submitted to the DIBNet portal. + +**Scoring Rules:** +- Starting score: **110** (maximum) +- Each practice **Not Implemented** is deducted based on its weight +- Deduction values: **-1**, **-3**, or **-5** per practice depending on impact +- Minimum possible score: **-203** +- Score of **110** = all practices fully implemented +- A score below **110** requires a POA&M entry for each deficiency + +**Reporting Requirement:** SPRS score must be submitted before a contract can be awarded +under DFARS 252.204-7019 contracts. + +**Score Categories:** +- 110: Fully implemented — no deficiencies +- 88–109: Minor deficiencies; POA&M required +- 70–87: Moderate deficiencies; elevated risk +- Below 70: Significant deficiencies; major remediation required + +### 6. POA&M Development + +When helping develop a Plan of Action and Milestones: +- A POA&M is required for every practice that is not fully implemented +- For Level 2 C3PAO assessments: POA&M items may be conditionally accepted if they are + not high-risk and have a completion date within 180 days of conditional certification +- For Level 3 (DIBCAC): stricter standards; fewer POA&M allowances + +**POA&M Template:** + +| Practice ID | Practice Title | Gap Description | Remediation Action | Responsible Party | Start Date | Completion Date | Status | +|------------|---------------|-----------------|-------------------|------------------|-----------|----------------|--------| +| 3.1.2 | Limit system access | RBAC not fully documented | Implement RBAC in AD | IT Security Lead | YYYY-MM-DD | YYYY-MM-DD | In Progress | + +--- + +## Assessment Process Overview + +### Level 2 C3PAO Assessment + +1. **Pre-Assessment Phase** + - Engage a Cyber-AB authorized C3PAO + - Complete CMMC Level 2 Self-Assessment and submit SPRS score + - Prepare SSP, POA&M, and all evidence artifacts + - Define and document assessment scope + +2. **Assessment Phase (on-site or remote)** + - C3PAO Lead Assessor and team reviews documentation + - Interviews with key personnel (IT, security, operations) + - Artifact review: policies, logs, configurations, screenshots + - Technical testing as applicable + - Practice-by-practice determination: MET or NOT MET + +3. **Post-Assessment Phase** + - C3PAO issues assessment findings + - If conditional: POA&M items close within 180 days + - C3PAO submits results to CMMC-AB eMASS (CMMC Enterprise Mission Assurance Support Service) + - DoD CIO issues CMMC certificate + - Certificate valid for **3 years** (triennial reassessment) + - **Annual Affirmation** required each year by a senior company official + +### Level 3 DIBCAC Assessment + +- Conducted by DCMA's Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) +- Requires prior Level 2 C3PAO certification +- Applies only to DoD-selected highest-priority programs +- Additional 24 practices from NIST SP 800-172 assessed +- Higher scrutiny; stricter evidence requirements + +--- + +## Annual Affirmation Requirements + +All CMMC levels require an annual affirmation submitted via the CMMC-AB Marketplace or +DIBNet portal. The affirmation must be made by a **senior company official** (e.g., CEO, +CISO, or equivalent) and states that the organization continues to meet the CMMC requirements +for the certified level. + +**Affirmation includes:** +- Organization name and CAGE code +- CMMC level affirmed +- Date of most recent assessment +- Senior official's name, title, and signature +- Statement that no changes have degraded compliance; or documentation of changes + +--- + +## CUI Categories Relevant to CMMC + +The DoD CUI Registry defines categories applicable to defense programs. Common CUI categories +in the DIB context include: + +| CUI Category | Description | +|-------------|-------------| +| Controlled Technical Information (CTI) | Technical data, computer software with military or space application | +| Export Controlled | Information regulated under ITAR, EAR, or equivalent | +| Proprietary Business Information | Contractor-owned trade secrets and confidential technical data | +| Naval Nuclear Propulsion Information (NNPI) | Restricted nuclear propulsion data | +| Privacy — DoD Personnel | PII of DoD personnel | + +--- + +## Common CMMC Misconceptions + +| Misconception | Fact | +|--------------|------| +| "We can self-attest for Level 2" | Only if DoD explicitly designates the acquisition as non-prioritized. Most CUI programs require C3PAO. | +| "CMMC is the same as NIST 800-171" | CMMC Level 2 is aligned to 800-171 Rev 2, but adds assessment requirements and a certification regime | +| "POA&M means we're non-compliant" | Conditional certification with a POA&M is still a valid certification status if items are closed in 180 days | +| "Subcontractors don't need CMMC" | Subcontractors must meet CMMC requirements if they handle FCI or CUI | +| "Cloud = out of scope" | Cloud service providers are External Service Providers and must meet FedRAMP Moderate or equivalent | +| "CCPA/GDPR compliance satisfies CMMC" | No. CMMC is specific to DoD CUI/FCI. Separate compliance regimes. | diff --git a/plugins/cmmc/skills/cmmc/references/assessment-guide.md b/plugins/cmmc/skills/cmmc/references/assessment-guide.md new file mode 100644 index 0000000..4799cfd --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/assessment-guide.md @@ -0,0 +1,349 @@ +# CMMC 2.0 Assessment Guide +## C3PAO Assessment Process, SPRS Scoring, and Evidence Requirements +## Source: CMMC 2.0 Assessment Process, NIST SP 800-171A, DoD Assessment Methodology + +--- + +## Overview + +This guide covers the end-to-end CMMC 2.0 assessment process, how to prepare for a +C3PAO-led assessment, how the SPRS score is calculated and submitted, POA&M requirements, +and the evidence an assessor will expect to find for each domain. + +--- + +## Part 1: The Cyber-AB and C3PAO Ecosystem + +### The Cyber-AB (CMMC Accreditation Body) + +The **Cyber-AB** (formerly The Accreditation Body, CMMC-AB) is the official accreditation +body authorized by DoD to accredit CMMC Third-Party Assessment Organizations (C3PAOs), +Registered Practitioners (RPs), Registered Practitioner Organizations (RPOs), and +Licensed Partner Advisors (LPAs). + +**Cyber-AB Marketplace:** https://cyberab.org/Catalog/ +Use this portal to find and validate: +- Authorized C3PAOs (currently certified) +- Certified CMMC Assessors (CCAs or Provisional Assessors) +- Registered Practitioners (for consulting/advisory work) + +### C3PAO (Certified Third-Party Assessment Organization) + +A C3PAO is an organization licensed by the Cyber-AB to conduct CMMC Level 2 assessments. +They employ **Certified CMMC Assessors (CCAs)** who carry the Lead Assessor or Assessor role. + +**Selection criteria for an OSC choosing a C3PAO:** +- Must be listed on the Cyber-AB Marketplace as Authorized (active status) +- Must have enough licensed CCAs to staff the assessment +- Conflict of interest: cannot have provided consulting to the OSC within past 3 years +- Verify insurance and bonding requirements + +--- + +## Part 2: Level 2 C3PAO Assessment Process in Detail + +### Phase 1: Pre-Assessment Preparation (OSC Responsibility) + +**Minimum deliverables before requesting C3PAO:** + +| Document | Description | +|---------|-------------| +| System Security Plan (SSP) | Current, complete narrative for all 110 practices | +| POA&M | All known deficiencies documented with target dates | +| SPRS Score | Score submitted to DIBNet; must reflect current status | +| Network Diagram | Boundary and network architecture | +| Data Flow Diagram | CUI flow through the environment | +| Asset Inventory | All hardware and software within scope | +| Policy Set | All required policies and procedures | +| Evidence Package | Artifacts for each practice (see Part 4) | + +**Self-Assessment before C3PAO:** +Organizations should conduct a thorough internal self-assessment using NIST SP 800-171A +assessment procedures. Each practice has three assessment methods defined in SP 800-171A: +- **Examine** — Review documents, specifications, records, reports +- **Interview** — Discuss with personnel responsible for the practice +- **Test** — Exercise mechanisms, processes, activities + +### Phase 2: C3PAO Engagement and Scoping Agreement + +1. **Contract with C3PAO** — Sign engagement agreement; C3PAO firm quote for assessment +2. **Review Package Submission** — OSC provides SSP and key documents to C3PAO pre-assessment team +3. **Scope Alignment Meeting** — C3PAO and OSC agree on in-scope assets, boundaries, locations +4. **Assessment Plan** — C3PAO produces assessment plan including: + - Assessment dates and schedule + - Personnel to be interviewed + - Systems to be tested + - Documentation to be reviewed + +### Phase 3: Assessment Execution + +**Assessment methods per NIST SP 800-171A:** + +For each of the 110 practices, assessors will apply one or more of: +- **Examine** — Review policy documents, configuration records, system logs, screenshots, + audit trails, inventory records, training completion certificates +- **Interview** — Discussion with system owners, security personnel, administrators, users +- **Test** — Technical testing: log generation, account lockout behavior, patching, + network scans, encryption verification + +**Practice determination for each requirement:** +- **MET** — Practice is fully implemented; evidence confirms implementation +- **NOT MET** — Practice is not implemented or evidence is insufficient + +**Assessment findings categories:** +- **No deficiency** (MET) +- **Deficiency requiring POA&M** (potentially allowable for conditional certification) +- **High-risk deficiency** (may preclude conditional certification) + +### Phase 4: Post-Assessment Results and Certification + +**Outcome categories:** + +| Outcome | Meaning | Next Steps | +|---------|---------|-----------| +| CMMC Level 2 Certified | All 110 practices MET | C3PAO submits to eMASS; DoD issues certificate | +| Conditional CMMC Level 2 | Some NOT MET but no high-risk deficiencies | POA&M must close within 180 days; C3PAO verifies closure | +| Not Certified | High-risk deficiencies present or too many NOT MET | Remediate and reschedule full assessment | + +**High-risk practices (Not MET = cannot achieve conditional certification):** +Practices that are deemed high risk and preclude conditional status include those that +fundamentally undermine CUI protection. DoD publishes high-risk practice definitions. + +**Certificate submission:** +- C3PAO submits assessment results to the **CMMC Enterprise Mission Assurance Support + Service (eMASS)** portal managed by DoD +- DoD CIO issues the CMMC certificate +- Certificate is valid for **3 years** from issuance date + +### Phase 5: Annual Affirmation and Ongoing Compliance + +**Annual Affirmation Process:** +1. Senior company official (CEO, CISO, or equivalent) reviews current compliance status +2. Confirms no degradation has occurred since certification (or documents any changes) +3. Submits affirmation via the **DIBNet portal** (https://dibnet.dod.mil) +4. Affirmation occurs annually throughout the 3-year certificate period + +**Triggering events requiring disclosure:** +- Significant cyber incidents affecting the CUI environment +- Material changes to system boundary +- Acquisition or divestiture of business units in scope +- Discovery of practices that are no longer MET + +--- + +## Part 3: SPRS Score — Calculation and Submission + +### Overview + +The **Supplier Performance Risk System (SPRS)** score represents an organization's self-assessed +implementation of NIST SP 800-171 Rev 2. It is required under DFARS 252.204-7019/7020 and +must be submitted before contract award. + +**Source methodology:** NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1 + +### Scoring Methodology + +- **Starting score: 110** (all practices implemented) +- Each practice NOT implemented is subtracted based on its assigned weight +- A practice assessed as **Partial** is treated as **NOT MET** for SPRS purposes +- **Minimum score: -203** (all practices NOT MET, maximum deductions) + +### Practice Weights for SPRS Deduction + +The DoD Assessment Methodology assigns one of three deduction values to each practice. +Practices are not weighted by domain but by their security impact. + +**Value 1 (-1 point for NOT MET) — 77 practices are weighted at 1 point** +These are practices where the risk of non-implementation is lower or the control is +compensated by other practices. This includes most AU, AT, MA, PS, and single PE practices. + +**Value 3 (-3 points for NOT MET) — 15 practices are weighted at 3 points** +Mid-tier impact practices, including core AC, IA, CM, and SI practices. + +**Value 5 (-5 points for NOT MET) — 18 practices are weighted at 5 points** +High-impact practices where non-implementation creates significant CUI risk: + +| Practice | Domain | Reason for -5 Weight | +|---------|--------|---------------------| +| AC.L2-3.1.3 | AC | CUI flow control | +| AC.L2-3.1.5 | AC | Least privilege | +| AC.L2-3.1.12 | AC | Remote access monitoring | +| AC.L2-3.1.13 | AC | Remote access encryption | +| AC.L2-3.1.14 | AC | Remote access via managed access points | +| IA.L2-3.5.3 | IA | Multi-factor authentication | +| SC.L2-3.13.8 | SC | Data in transit encryption | +| SC.L2-3.13.11 | SC | FIPS-validated encryption | +| SC.L2-3.13.16 | SC | CUI at rest encryption | + +**Note:** The full weighting table for all 110 practices is in DoD Assessment Methodology v1.2.1 +at https://www.dodcio.defense.gov/CMMC/Resources/ + +### Submitting SPRS Score + +1. Register on **DIBNet portal** at https://dibnet.dod.mil +2. Navigate to SPRS module +3. Enter score, assessment date, assessment type (basic/medium/high), and scope +4. Affirmation by authorized government representative (for self-assessment) +5. Score is visible to DoD contracting officers for source selection + +### Score Interpretation + +| Score Range | Interpretation | Action Required | +|------------|---------------|----------------| +| 110 | All practices implemented | Maintain and affirm annually | +| 88 – 109 | Minor deficiencies | POA&M required; address before C3PAO assessment | +| 70 – 87 | Moderate deficiencies | Significant remediation; extended POA&M | +| 0 – 69 | Major deficiencies | Substantial program needed; high contractual risk | +| Negative | Severe deficiencies | Fundamental gaps; unlikely to pass C3PAO assessment | + +--- + +## Part 4: Evidence Requirements by Domain + +The following lists the primary evidence an assessor will expect for each domain during +a Level 2 C3PAO assessment. + +### Access Control (AC) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| User account management | Active Directory export or IAM platform user list with roles | +| Session lock | Group Policy Object (GPO) or MDM configuration showing idle timeout and lock | +| Remote access | VPN solution configuration, MFA enabled for VPN, access logs | +| Wireless access | Wi-Fi configuration (WPA2/3 Enterprise), network access control records | +| Mobile devices | MDM policy, encryption enforcement configuration | +| CUI flow control | Data flow diagram, information flow policies, DLP configuration if present | + +### Audit and Accountability (AU) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Audit logging | SIEM or log management configuration, enabled audit policies | +| Log retention | Log retention policy (minimum 90 days accessible, longer archived) | +| Time synchronization | NTP configuration pointing to authoritative source | +| Audit protection | SIEM access controls, log storage permissions | + +### Configuration Management (CM) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| System inventory | CMDB, asset management tool export, or spreadsheet with all in-scope assets | +| Configuration baselines | STIG/CIS Benchmark application records, GPOs | +| Change management | Change management system (tickets), change approval records | +| Software allowlisting | Application control policy, allowlist configuration | + +### Identification and Authentication (IA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| MFA for privileged accounts | MFA configuration screenshots (Duo, Azure MFA, etc.) | +| MFA for all remote access | VPN authentication configuration showing MFA required | +| Password policy | Password complexity policy configuration (AD, Azure AD, or equivalent) | +| Account management | Account provisioning/de-provisioning procedures and recent records | + +### Incident Response (IR) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| IRP documentation | Signed incident response plan with current date | +| IRP testing | Tabletop exercise records, test completion certificates | +| DFARS reporting | DIBNet registration confirmation, incident reporting procedure | + +### Maintenance (MA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Maintenance logs | Ticketing system records for scheduled and unscheduled maintenance | +| Remote maintenance | Remote session logs, MFA for remote maintenance sessions | +| Equipment sanitization | Media sanitization records for equipment removed for repair | + +### Media Protection (MP) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Media inventory | Inventory of removable media (USB drives, external drives) | +| Media encryption | BitLocker or equivalent encryption configuration | +| Disposal records | Certificate of data destruction for disposed media | + +### Risk Assessment (RA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Risk assessment | Formal risk assessment report dated within past 3 years | +| Vulnerability scanning | Vulnerability scan reports (Nessus, Qualys, Rapid7, etc.), dated | +| Remediation tracking | Vulnerability remediation tracking records (patch tickets, scan deltas) | + +### Security Assessment (CA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Security assessment | Internal security assessment records, third-party assessment reports | +| POA&M | Current POA&M with open/closed items, target dates, owners | +| SSP | Complete, current System Security Plan covering all 110 practices | + +### System and Communications Protection (SC) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Firewall/boundary | Firewall rule export, network architecture diagram | +| Encryption in transit | TLS configuration (1.2 minimum), certificate inventory | +| Encryption at rest | BitLocker, Database encryption configuration, cloud storage encryption | +| FIPS validation | FIPS 140-2/3 certificate numbers for cryptographic modules used | +| Split tunneling disabled | VPN configuration showing full-tunnel for remote access clients | + +### System and Information Integrity (SI) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Patch management | Patch management tool reports, patching SLA documentation | +| Malware protection | EDR/AV deployment report showing all in-scope endpoints covered | +| AV definitions | AV console showing definition update status and last update date | +| Security monitoring | SIEM alert rules, SOC procedures, monitoring coverage documentation | + +--- + +## Part 5: POA&M Management + +### POA&M Requirements + +A Plan of Action and Milestones (POA&M) is **required** for every CMMC practice that is +NOT MET or only partially implemented at the time of assessment. + +**Official requirement:** CMMC 2.0 allows **conditional certification** if: +- The NOT MET practice items do not include high-risk practices +- A POA&M is in place with realistic remediation milestones +- ALL POA&M items must be closed and verified within **180 days** of conditional certificate issuance + +### POA&M Format + +| Field | Description | +|-------|-------------| +| Item ID | Unique identifier (e.g., POA&M-001) | +| Practice ID | CMMC practice (e.g., AC.L2-3.1.5) | +| Practice Title | Description of the requirement | +| Weakness/Gap | Description of what is not implemented and why | +| Point of Contact | Name and role of person responsible for remediation | +| Resources Required | Budget, tools, personnel needed | +| Scheduled Completion Date | Realistic target date (must be within 180 days for conditional cert) | +| Status | Open / In Progress / Closed (with closure date and verification) | +| Milestones | Intermediate steps toward closure | + +### POA&M Closure Verification + +When a POA&M item is closed: +- Record the actual completion date +- Document what was implemented +- Reference evidence artifacts (e.g., screenshot, configuration export, policy document) +- Assessor or independent reviewer verifies closure before submitting to eMASS + +--- + +## Part 6: CMMC Contract Clause Summary + +| Clause | When Included | Key Requirement | +|--------|--------------|----------------| +| FAR 52.204-21 | When contractor will process FCI | Implement 15 basic safeguarding requirements | +| DFARS 252.204-7012 | When contractor processes covered defense information | Safeguard; report incidents to DoD within 72 hours | +| DFARS 252.204-7019 | Most contracts | Perform and post SPRS score before award | +| DFARS 252.204-7020 | Contracts requiring DoD-assessed score | Allow DoD to conduct assessment; medium/high methodology | +| DFARS 252.204-7021 | Contracts requiring CMMC certification | Achieve and maintain CMMC level specified; flow-down to subcontractors | diff --git a/plugins/cmmc/skills/cmmc/references/level1-practices.md b/plugins/cmmc/skills/cmmc/references/level1-practices.md new file mode 100644 index 0000000..d14c35c --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/level1-practices.md @@ -0,0 +1,142 @@ +# CMMC Level 1 — Foundational (17 Practices) +## Source: FAR 52.204-21 and CMMC 2.0 Final Rule (32 CFR Part 170) + +--- + +## Overview + +CMMC Level 1 applies to organizations that handle **Federal Contract Information (FCI)** +but do not process, store, or transmit **Controlled Unclassified Information (CUI)**. + +**Definition of FCI (FAR 4.1901):** +> Information, not intended for public release, that is provided by or generated for the +> Government under a contract to develop or deliver a product or service to the Government, +> but not including information provided by the Government to the public (e.g., on public +> Web sites) or simple transactional information, such as that necessary to process payments. + +**Assessment Type:** Annual self-assessment by the organization +**Evidence Required:** Organization must retain evidence sufficient to support the affirmation +**Affirmation:** Annual senior-official affirmation required via DIBNet portal + +--- + +## The 17 Level 1 Practices + +These 17 practices derive from FAR 52.204-21, "Basic Safeguarding of Covered Contractor +Information Systems." Two pairs of practices overlap in intent with others but are each +independently counted in the CMMC practice numbering. + +### Domain: Access Control (AC) — 4 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| AC.L1-3.1.1 | Authorized Access Control | Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). | +| AC.L1-3.1.2 | Transaction & Function Control | Limit information system access to the types of transactions and functions that authorized users are permitted to execute. | +| AC.L1-3.1.20 | External Connections | Verify and control/limit connections to external information systems. | +| AC.L1-3.1.22 | Control Public Information | Control information posted or processed on publicly accessible information systems. | + +### Domain: Identification and Authentication (IA) — 2 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| IA.L1-3.5.1 | Identification | Identify information system users, processes acting on behalf of users, or devices. | +| IA.L1-3.5.2 | Authentication | Authenticate (or verify) the identities of those users, processes, or devices before allowing access. | + +### Domain: Media Protection (MP) — 1 Practice + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| MP.L1-3.8.3 | Media Disposal | Sanitize or destroy information system media containing FCI before disposal or reuse. | + +### Domain: Physical Protection (PE) — 4 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| PE.L1-3.10.1 | Limit Physical Access | Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals. | +| PE.L1-3.10.3 | Escort Visitors | Escort visitors and monitor visitor activity. | +| PE.L1-3.10.4 | Audit Physical Access | Maintain audit logs of physical access. | +| PE.L1-3.10.5 | Manage Physical Access | Control and manage physical access devices. | + +### Domain: System and Communications Protection (SC) — 2 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| SC.L1-3.13.1 | Boundary Protection | Monitor, control, and protect organizational communications at the external boundaries and key internal boundaries. | +| SC.L1-3.13.5 | Public-Access System Separation | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | + +### Domain: System and Information Integrity (SI) — 4 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| SI.L1-3.14.1 | Flaw Remediation | Identify, report, and correct information and information system flaws in a timely manner. | +| SI.L1-3.14.2 | Malicious Code Protection | Provide protection from malicious code at appropriate locations within organizational information systems. | +| SI.L1-3.14.4 | Update Malicious Code Protection | Update malicious code protection mechanisms when new releases are available. | +| SI.L1-3.14.5 | System & Security Scanning | Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed. | + +--- + +## Level 1 Self-Assessment Methodology + +### Step 1 — Determine Scope + +Identify all assets that process, store, or transmit FCI: +- Workstations and laptops used by employees working on federal contracts +- File servers holding contract deliverables or government-provided information +- Email systems used for contract communications +- Cloud storage containing government-provided documents + +### Step 2 — Assess Each Practice + +For each of the 17 practices, determine: +- **MET** — The practice is fully implemented for all in-scope assets +- **NOT MET** — The practice is partially or not implemented + +### Step 3 — Calculate SPRS Score + +CMMC Level 1 uses a simplified scoring model: +- Total possible: 17 practice points +- For Level 1, SPRS scoring uses the same 110-point deduction model but limited to Level 1 practices +- Report score to SPRS via DIBNet before contract award + +### Step 4 — Document and Affirm + +- Document the self-assessment results +- Brief a senior company official on findings +- Senior official submits annual affirmation via DIBNet portal + +--- + +## Level 1 Evidence Examples + +| Practice | Evidence Examples | +|---------|------------------| +| AC.L1-3.1.1 | User account list, Active Directory group policy, access control policy | +| AC.L1-3.1.2 | Role-based access configuration, application access control settings | +| AC.L1-3.1.20 | Firewall rules, network diagram showing external connections list | +| AC.L1-3.1.22 | Web server configuration, content management records, approval procedures | +| IA.L1-3.5.1 | User account naming convention documentation, unique ID assignment records | +| IA.L1-3.5.2 | Password policy, authentication system logs, MFA configuration | +| MP.L1-3.8.3 | Media disposal records, certificate of destruction, data sanitization software logs | +| PE.L1-3.10.1 | Badge/key allocation records, facility access logs, physical security policy | +| PE.L1-3.10.3 | Visitor log, escort policy, visitor badge records | +| PE.L1-3.10.4 | Physical access logs, badge reader system export, CCTV records | +| PE.L1-3.10.5 | Key management log, badge deactivation records, physical device inventory | +| SC.L1-3.13.1 | Firewall configuration, boundary protection policy, network diagram | +| SC.L1-3.13.5 | VLAN configuration, DMZ documentation, network segmentation diagram | +| SI.L1-3.14.1 | Patch management records, vulnerability scan reports, patching policy | +| SI.L1-3.14.2 | AV/EDR deployment records, malicious code protection policy | +| SI.L1-3.14.4 | AV definition update logs, automatic update configuration | +| SI.L1-3.14.5 | Scheduled scan logs, AV real-time scan configuration | + +--- + +## Common Level 1 Deficiencies + +1. **No documented scope** — Organization cannot identify all FCI-touching systems +2. **Shared accounts** — Multiple users sharing login credentials (violates AC.L1-3.1.1, IA.L1-3.5.1) +3. **No AV on all workstations** — Not every endpoint has active, up-to-date malware protection +4. **No physical visitor log** — Visitors not logged or escorted (violates PE.L1-3.10.3, PE.L1-3.10.4) +5. **No media disposal process** — Old hard drives with FCI not sanitized before disposal +6. **No patching cadence** — System patches applied irregularly or not documented +7. **Public website has FCI** — Government data inadvertently posted publicly (violates AC.L1-3.1.22) +8. **No SPRS submission** — Organization has never uploaded a score to DIBNet portal diff --git a/plugins/cmmc/skills/cmmc/references/level2-practices.md b/plugins/cmmc/skills/cmmc/references/level2-practices.md new file mode 100644 index 0000000..2179d94 --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/level2-practices.md @@ -0,0 +1,250 @@ +# CMMC Level 2 — Advanced (110 Practices) +## Source: NIST SP 800-171 Rev 2 and CMMC 2.0 Final Rule (32 CFR Part 170) + +--- + +## Overview + +CMMC Level 2 applies to organizations that process, store, or transmit **Controlled +Unclassified Information (CUI)** in the performance of DoD contracts. + +Level 2 requirements are **identical to NIST SP 800-171 Rev 2** across 14 domains and +110 security requirements (referred to as "practices" in the CMMC context). + +**Assessment Type:** +- **C3PAO triennial assessment** — required for most CUI contracts (prioritized programs) +- **Self-assessment (annual)** — only when specifically designated by DoD for non-prioritized acquisitions + +**Certificate Validity:** 3 years (triennial reassessment required) +**Annual Affirmation:** Required each year by a senior company official + +--- + +## All 110 Level 2 Practices by Domain + +### 1. Access Control (AC) — 22 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| AC.L2-3.1.1 | 3.1.1 | Authorized Access Control | Limit system access to authorized users, processes acting on behalf of authorized users, and devices | +| AC.L2-3.1.2 | 3.1.2 | Transaction & Function Control | Limit system access to the types of transactions and functions that authorized users are permitted to execute | +| AC.L2-3.1.3 | 3.1.3 | Control CUI Flow | Control the flow of CUI in accordance with approved authorizations | +| AC.L2-3.1.4 | 3.1.4 | Separation of Duties | Separate the duties of individuals to reduce the risk of malevolent activity | +| AC.L2-3.1.5 | 3.1.5 | Least Privilege | Employ the principle of least privilege, including for specific security functions and privileged accounts | +| AC.L2-3.1.6 | 3.1.6 | Non-Privileged Account Use | Use non-privileged accounts or roles when accessing non-security functions | +| AC.L2-3.1.7 | 3.1.7 | Privileged Function Execution | Prevent non-privileged users from executing privileged functions and capture the execution in audit logs | +| AC.L2-3.1.8 | 3.1.8 | Unsuccessful Logon Attempts | Limit unsuccessful logon attempts | +| AC.L2-3.1.9 | 3.1.9 | Privacy & Security Notices | Provide privacy and security notices consistent with CUI rules | +| AC.L2-3.1.10 | 3.1.10 | Session Lock | Use session lock with pattern-hiding displays after a period of inactivity | +| AC.L2-3.1.11 | 3.1.11 | Session Termination | Terminate (automatically) a user session after a defined condition | +| AC.L2-3.1.12 | 3.1.12 | Control Remote Access | Monitor and control remote access sessions | +| AC.L2-3.1.13 | 3.1.13 | Remote Access Confidentiality | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions | +| AC.L2-3.1.14 | 3.1.14 | Remote Access Routing | Route remote access via managed access control points | +| AC.L2-3.1.15 | 3.1.15 | Privileged Remote Access | Authorize remote execution of privileged commands via remote access only for documented operational needs | +| AC.L2-3.1.16 | 3.1.16 | Wireless Access Authorization | Authorize wireless access prior to allowing connections to the system | +| AC.L2-3.1.17 | 3.1.17 | Wireless Access Protection | Protect wireless access using authentication and encryption | +| AC.L2-3.1.18 | 3.1.18 | Mobile Device Connection | Control connection of mobile devices | +| AC.L2-3.1.19 | 3.1.19 | Encrypt CUI on Mobile | Encrypt CUI on mobile devices and mobile computing platforms | +| AC.L2-3.1.20 | 3.1.20 | External System Connections | Verify and control/limit connections to external information systems | +| AC.L2-3.1.21 | 3.1.21 | Portable Storage Use | Limit use of portable storage devices on external systems | +| AC.L2-3.1.22 | 3.1.22 | Control Public Information | Control information posted or processed on publicly accessible information systems | + +### 2. Audit and Accountability (AU) — 9 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| AU.L2-3.3.1 | 3.3.1 | System Auditing | Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity | +| AU.L2-3.3.2 | 3.3.2 | User Accountability | Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable | +| AU.L2-3.3.3 | 3.3.3 | Event Review | Review and update logged events | +| AU.L2-3.3.4 | 3.3.4 | Audit Failure Alerting | Alert in the event of an audit logging process failure | +| AU.L2-3.3.5 | 3.3.5 | Audit Correlation | Correlate audit record review, analysis, and reporting processes for investigation and response | +| AU.L2-3.3.6 | 3.3.6 | Reduction & Reporting | Provide audit record reduction and report generation to support on-demand analysis and reporting | +| AU.L2-3.3.7 | 3.3.7 | Authoritative Time Source | Provide a system capability that compares and synchronizes internal system clocks with an authoritative source | +| AU.L2-3.3.8 | 3.3.8 | Audit Protection | Protect audit information and tools from unauthorized access, modification, and deletion | +| AU.L2-3.3.9 | 3.3.9 | Audit Management | Limit management of audit logs to a subset of privileged users | + +### 3. Awareness and Training (AT) — 3 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| AT.L2-3.2.1 | 3.2.1 | Role-Based Risk Awareness | Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities | +| AT.L2-3.2.2 | 3.2.2 | Role-Based Training | Ensure that organizational personnel are adequately trained to carry out their assigned information security responsibilities | +| AT.L2-3.2.3 | 3.2.3 | Insider Threat Awareness | Provide security awareness training on recognizing and reporting potential threats (including insider threats) | + +### 4. Configuration Management (CM) — 9 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| CM.L2-3.4.1 | 3.4.1 | System Baselining | Establish and maintain baseline configurations and inventories of organizational systems (hardware, software, firmware, network components) | +| CM.L2-3.4.2 | 3.4.2 | Security Configuration Enforcement | Establish and enforce security configuration settings for IT products employed in organizational systems | +| CM.L2-3.4.3 | 3.4.3 | System Change Control | Track, review, approve, and log changes to organizational systems | +| CM.L2-3.4.4 | 3.4.4 | Security Impact Analysis | Analyze the security impact of changes prior to implementation | +| CM.L2-3.4.5 | 3.4.5 | Access Restrictions for Change | Define, document, approve, and enforce physical and logical access restrictions associated with changes | +| CM.L2-3.4.6 | 3.4.6 | Least Functionality | Employ the principle of least functionality by configuring the system to provide only essential capabilities | +| CM.L2-3.4.7 | 3.4.7 | Nonessential Functionality | Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services | +| CM.L2-3.4.8 | 3.4.8 | Application Execution Policy | Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or application execution | +| CM.L2-3.4.9 | 3.4.9 | User-Installed Software | Control and monitor user-installed software | + +### 5. Identification and Authentication (IA) — 11 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| IA.L2-3.5.1 | 3.5.1 | Identification | Identify information system users, processes acting on behalf of users, or devices | +| IA.L2-3.5.2 | 3.5.2 | Authentication | Authenticate (or verify) the identities of users, processes, or devices before allowing access | +| IA.L2-3.5.3 | 3.5.3 | Multifactor Authentication — Privileged | Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts | +| IA.L2-3.5.4 | 3.5.4 | Replay-Resistant Authentication | Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts | +| IA.L2-3.5.5 | 3.5.5 | Identifier Reuse | Prohibit reuse of identifiers for a defined period | +| IA.L2-3.5.6 | 3.5.6 | Identifier Handling | Disable identifiers after a defined inactivity period | +| IA.L2-3.5.7 | 3.5.7 | Password Complexity | Enforce a minimum password complexity and change of characters when new passwords are created | +| IA.L2-3.5.8 | 3.5.8 | Password Reuse | Prohibit password reuse for a specified number of generations | +| IA.L2-3.5.9 | 3.5.9 | Temporary Passwords | Allow temporary password use with an immediate change requirement | +| IA.L2-3.5.10 | 3.5.10 | Cryptographically-Protected Passwords | Store and transmit only cryptographically-protected passwords | +| IA.L2-3.5.11 | 3.5.11 | Obscure Feedback | Obscure feedback of authentication information during the authentication process | + +### 6. Incident Response (IR) — 3 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| IR.L2-3.6.1 | 3.6.1 | Incident Handling | Establish an operational incident-handling capability for organizational systems including: preparation, detection, analysis, containment, recovery, and user response activities | +| IR.L2-3.6.2 | 3.6.2 | Incident Reporting | Track, document, and report incidents to appropriate organizational officials and/or authorities | +| IR.L2-3.6.3 | 3.6.3 | Incident Response Testing | Test the organizational incident response capability | + +**Note on DFARS 252.204-7012:** Contractors that discover a cyber incident on a covered +contractor information system must: +- Report to DoD at https://dibnet.dod.mil within **72 hours** of discovery +- Preserve and protect images of all known affected systems for **90 days** +- Submit a malware sample (if discovered) to the DoD Cyber Crime Center (DC3) +- Cooperate with DoD damage assessment activities + +### 7. Maintenance (MA) — 6 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| MA.L2-3.7.1 | 3.7.1 | Managed Maintenance | Perform maintenance on organizational systems | +| MA.L2-3.7.2 | 3.7.2 | Maintenance Tools | Provide controls on the tools, techniques, mechanisms, and personnel for system maintenance | +| MA.L2-3.7.3 | 3.7.3 | Equipment Sanitization | Ensure equipment removed for maintenance is sanitized with respect to CUI | +| MA.L2-3.7.4 | 3.7.4 | Media Inspection | Check media containing diagnostic and test programs for malicious code before used on systems | +| MA.L2-3.7.5 | 3.7.5 | Nonlocal Maintenance | Require MFA to establish nonlocal maintenance sessions and terminate when session is complete | +| MA.L2-3.7.6 | 3.7.6 | Maintenance Personnel | Supervise maintenance activities of personnel without required access authorization | + +### 8. Media Protection (MP) — 9 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| MP.L2-3.8.1 | 3.8.1 | Media Protection | Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital | +| MP.L2-3.8.2 | 3.8.2 | Media Access | Limit access to CUI on system media to authorized users | +| MP.L2-3.8.3 | 3.8.3 | Media Disposal | Sanitize or destroy system media before disposal or reuse | +| MP.L2-3.8.4 | 3.8.4 | Media Markings | Mark media with necessary CUI markings and distribution limitations | +| MP.L2-3.8.5 | 3.8.5 | Media Accountability | Control access to media containing CUI and maintain accountability for media during transport | +| MP.L2-3.8.6 | 3.8.6 | Portable Storage Encryption | Implement cryptographic mechanisms to protect the confidentiality of CUI during transport unless protected by alternative physical safeguards | +| MP.L2-3.8.7 | 3.8.7 | Removable Media Control | Control the use of removable media on system components | +| MP.L2-3.8.8 | 3.8.8 | Shared Media | Prohibit the use of portable storage devices when such devices have no identifiable owner | +| MP.L2-3.8.9 | 3.8.9 | CUI Protection at Backup Locations | Protect the confidentiality of backup CUI at storage locations | + +### 9. Personnel Security (PS) — 2 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| PS.L2-3.9.1 | 3.9.1 | Screen Individuals | Screen individuals prior to authorizing access to organizational systems containing CUI | +| PS.L2-3.9.2 | 3.9.2 | Termination & Transfer | Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers | + +### 10. Physical Protection (PE) — 6 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| PE.L2-3.10.1 | 3.10.1 | Limit Physical Access | Limit physical access to organizational systems, equipment, and operating environments to authorized individuals | +| PE.L2-3.10.2 | 3.10.2 | Protect & Monitor Physical Facility | Protect and monitor the physical facility and support infrastructure for organizational systems | +| PE.L2-3.10.3 | 3.10.3 | Escort Visitors | Escort visitors and monitor visitor activity | +| PE.L2-3.10.4 | 3.10.4 | Audit Physical Access | Maintain audit logs of physical access | +| PE.L2-3.10.5 | 3.10.5 | Manage Physical Access | Control and manage physical access devices | +| PE.L2-3.10.6 | 3.10.6 | Alternative Work Sites | Enforce safeguarding measures for CUI at alternate work sites | + +### 11. Risk Assessment (RA) — 3 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| RA.L2-3.11.1 | 3.11.1 | Risk Assessments | Periodically assess the risk to organizational operations, assets, and individuals resulting from the operation of organizational systems and the associated processing, storing, or transmitting of CUI | +| RA.L2-3.11.2 | 3.11.2 | Vulnerability Scan | Periodically scan for vulnerabilities in organizational systems and applications; remediate high vulnerabilities | +| RA.L2-3.11.3 | 3.11.3 | Vulnerability Remediation | Remediate vulnerabilities in accordance with risk assessments | + +### 12. Security Assessment (CA) — 4 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| CA.L2-3.12.1 | 3.12.1 | System Security Assessment | Periodically assess the security controls in organizational systems to determine if the controls are effective | +| CA.L2-3.12.2 | 3.12.2 | Plan of Action | Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities | +| CA.L2-3.12.3 | 3.12.3 | Security Control Monitoring | Monitor security controls on an ongoing basis to ensure the continued effectiveness | +| CA.L2-3.12.4 | 3.12.4 | System Security Plan | Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and relationships with other systems | + +### 13. System and Communications Protection (SC) — 16 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| SC.L2-3.13.1 | 3.13.1 | Boundary Protection | Monitor, control, and protect communications at external and key internal boundaries | +| SC.L2-3.13.2 | 3.13.2 | Security Engineering | Employ architectural designs, software development techniques, and systems engineering principles promoting security effectiveness | +| SC.L2-3.13.3 | 3.13.3 | Role Separation | Separate user functionality from system management functionality | +| SC.L2-3.13.4 | 3.13.4 | Shared Resource Control | Prevent unauthorized and unintended information transfer via shared system resources | +| SC.L2-3.13.5 | 3.13.5 | Public-Access System Separation | Implement subnetworks for publicly accessible system components, separated from internal networks | +| SC.L2-3.13.6 | 3.13.6 | Network Communication Denial | Deny network communications traffic by default; allow by exception (deny-all, permit-by-exception) | +| SC.L2-3.13.7 | 3.13.7 | Split Tunneling | Prevent remote devices from simultaneously using VPN tunneling to connect simultaneously to the system and to resources in other domains | +| SC.L2-3.13.8 | 3.13.8 | Data in Transit | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission | +| SC.L2-3.13.9 | 3.13.9 | Connections Termination | Terminate network connections after a defined period of inactivity | +| SC.L2-3.13.10 | 3.13.10 | Key Management | Establish and manage cryptographic keys for required cryptography employed in organizational systems | +| SC.L2-3.13.11 | 3.13.11 | CUI Encryption | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI | +| SC.L2-3.13.12 | 3.13.12 | Collaborative Computing Devices | Prohibit remote activation of collaborative computing devices and provide indication of use to users present | +| SC.L2-3.13.13 | 3.13.13 | Mobile Code | Control and monitor the use of mobile code | +| SC.L2-3.13.14 | 3.13.14 | VoIP Technologies | Control and monitor the use of VoIP technologies | +| SC.L2-3.13.15 | 3.13.15 | Communications Authenticity | Protect the authenticity of communications sessions | +| SC.L2-3.13.16 | 3.13.16 | CUI at Rest | Protect the confidentiality of CUI at rest | + +### 14. System and Information Integrity (SI) — 7 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| SI.L2-3.14.1 | 3.14.1 | Flaw Remediation | Identify, report, and correct information and system flaws in a timely manner | +| SI.L2-3.14.2 | 3.14.2 | Malicious Code Protection | Provide protection from malicious code at appropriate locations within organizational systems | +| SI.L2-3.14.3 | 3.14.3 | Security Alerts | Monitor system security alerts and advisories and take action in response | +| SI.L2-3.14.4 | 3.14.4 | Update Malicious Code Protection | Update malicious code protection mechanisms when new releases are available | +| SI.L2-3.14.5 | 3.14.5 | System Scanning | Perform periodic scans of the system and real-time scans of files from external sources | +| SI.L2-3.14.6 | 3.14.6 | Security Monitoring | Monitor the system to detect attacks and indicators of potential attacks | +| SI.L2-3.14.7 | 3.14.7 | Identify Unauthorized Use | Identify unauthorized use of organizational systems | + +--- + +## SPRS Score Deduction Reference + +The NIST SP 800-171 DoD Assessment Methodology assigns deduction values to each practice. +Below are the deduction weights (not implemented = subtract from 110): + +**High-impact deductions (-5 each):** +AC.L2-3.1.3, AC.L2-3.1.5, AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.14, +IA.L2-3.5.3, SC.L2-3.13.8, SC.L2-3.13.11, SC.L2-3.13.16 + +**Medium-impact deductions (-3 each):** +AC.L2-3.1.1, AC.L2-3.1.2, AU.L2-3.3.1, AU.L2-3.3.2, CA.L2-3.12.4, +CM.L2-3.4.1, CM.L2-3.4.2, IA.L2-3.5.1, IA.L2-3.5.2, IA.L2-3.5.7, +IR.L2-3.6.1, RA.L2-3.11.2, SC.L2-3.13.1, SC.L2-3.13.6, SI.L2-3.14.1, +SI.L2-3.14.2, SI.L2-3.14.5, SI.L2-3.14.6 + +**Low-impact deductions (-1 each):** All remaining 83 practices + +--- + +## Key Evidence Requirements for C3PAO Assessment + +| Domain | Critical Evidence | +|--------|-----------------| +| AC | User account list, access control policy, session lock configuration, VPN configuration | +| AU | Audit log configuration, log retention settings, SIEM deployment, NTP configuration | +| AT | Training completion records (dated, named), training content for all roles | +| CM | System inventory, configuration baselines, change management records, approved software list | +| IA | MFA deployment configuration, password policy, account review records | +| IR | Incident response plan, test records (tabletop or drill), DIBNET cybersecurity portal registration | +| MA | Maintenance logs, remote maintenance session records, equipment sanitization records | +| MP | Media inventory, encryption configuration for portable media, disposal certificates | +| PS | Background check records, termination/transfer checklist completion records | +| PE | Physical access log, badge records, visitor log, alternative work site policy | +| RA | Risk assessment report (dated), vulnerability scan reports, remediation tracking | +| CA | Security assessment report, POA&M (current), SSP (current) | +| SC | Firewall rules, network diagram, encryption certificates, VPN configuration | +| SI | Patch management reports, AV/EDR console screenshots, security alert process documentation | diff --git a/plugins/cmmc/skills/cmmc/references/level3-practices.md b/plugins/cmmc/skills/cmmc/references/level3-practices.md new file mode 100644 index 0000000..79087f5 --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/level3-practices.md @@ -0,0 +1,156 @@ +# CMMC Level 3 — Expert (134 Practices) +## Source: NIST SP 800-172 (Enhanced Requirements) and CMMC 2.0 Final Rule (32 CFR Part 170) + +--- + +## Overview + +CMMC Level 3 applies to organizations handling **CUI associated with DoD's highest-priority +programs** — typically those involving critical national security systems. + +Level 3 requires implementation of all 110 Level 2 practices (NIST SP 800-171 Rev 2) **plus** +24 additional enhanced security requirements from **NIST SP 800-172, "Enhanced Security +Requirements for Protecting Controlled Unclassified Information."** + +**Assessment Type:** Conducted by the **Defense Contract Management Agency (DCMA) Defense +Industrial Base Cybersecurity Assessment Center (DIBCAC)** + +**Prerequisite:** Organizations must first achieve a CMMC Level 2 C3PAO certification before +a Level 3 assessment can be initiated. + +**Certificate Validity:** 3 years (triennial DIBCAC reassessment) +**Annual Affirmation:** Required each year by a senior company official + +--- + +## The 24 Additional Level 3 Practices (from NIST SP 800-172) + +All practice IDs use the prefix format: `[Domain].L3-3.x.x(e)` where `(e)` denotes +an "enhanced" requirement from SP 800-172. + +### Domain: Access Control (AC) — 4 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| AC.L3-3.1.2e | 3.1.2e | Restrict Access | Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization | +| AC.L3-3.1.3e | 3.1.3e | Control CUI Flows — Encrypted | Employ dynamic access control mechanisms to enforce authorizations associated with CUI; protect CUI using cryptographic mechanisms and information flow controls on systems and network components | +| AC.L3-3.1.5e | 3.1.5e | Privileged Access — Logon | Require individuals accessing CUI systems with privileged accounts to have specific training and to use the accounts only when required; log all privileged access to CUI environments | +| AC.L3-3.1.6e | 3.1.6e | Non-Privileged Account Use — Separation | Separate the duties of individuals to reduce the risk of compromise by an insider; log and audit the actions of personnel with access to CUI in high-value systems | + +### Domain: Awareness and Training (AT) — 1 Additional Practice + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| AT.L3-3.2.1e | 3.2.1e | Advanced Training | Provide awareness training upon initial hire and regularly thereafter; provide training focused on advanced persistent threats (APT) techniques, tactics, and procedures; include role-based and scenario-based content | + +### Domain: Configuration Management (CM) — 1 Additional Practice + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| CM.L3-3.4.1e | 3.4.1e | Authoritative Source | Establish and maintain an authoritative source and repository to provide a trusted source and accountability for systems and system components throughout the system development life cycle | + +### Domain: Identification and Authentication (IA) — 1 Additional Practice + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| IA.L3-3.5.3e | 3.5.3e | Additional MFA Mechanisms | Employ supplemental authentication techniques or mechanisms for access to CUI systems where the risk of unauthorized access is particularly high | + +### Domain: Incident Response (IR) — 4 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| IR.L3-3.6.1e | 3.6.1e | Insider Threat Response | Establish and maintain a cyber incident response team that can be deployed to any location within 24 hours to investigate cyber incidents | +| IR.L3-3.6.2e | 3.6.2e | Security Operations | Establish and maintain a security operations center (SOC) capability that facilitates 24/7 monitoring, reporting, and response capabilities | +| IR.L3-3.6.3e | 3.6.3e | Hunt APT | Track adversarial TTPs, employ deception technologies and techniques, perform threat hunting activities, and conduct assessments of vulnerabilities | +| IR.L3-3.6.4e | 3.6.4e | Cyber Threat Intelligence | Receive threat intelligence relevant to the CUI assets from DoD or designated sources; integrate threat intelligence into cyber defense operations | + +### Domain: Risk Assessment (RA) — 5 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| RA.L3-3.11.1e | 3.11.1e | Risk Response | Employ advanced risk assessment techniques and tools to identify and mitigate targeted attacks on high-value assets | +| RA.L3-3.11.2e | 3.11.2e | Threat-Informed Procedures | Use threat intelligence to inform and enhance vulnerability analyses and security controls | +| RA.L3-3.11.3e | 3.11.3e | Advanced Threat Modeling | Develop and update (at least annually) threat models for systems with CUI; use threat models to inform decisions about risk mitigation | +| RA.L3-3.11.4e | 3.11.4e | Predictive Cyber Analytics | Conduct predictive cyber analysis to identify vulnerabilities and potential attacks by leveraging threat intelligence and vulnerability scan data | +| RA.L3-3.11.6e | 3.11.6e | Security Architecture Review | Review security architecture of CUI systems regularly; ensure architecture is consistent with DoD security requirements and CUI protection plans | + +### Domain: Security Assessment (CA) — 3 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| CA.L3-3.12.1e | 3.12.1e | Penetration Testing | Conduct penetration testing at least annually or after significant changes to CUI systems | +| CA.L3-3.12.2e | 3.12.2e | Independent Assessment | Conduct independent, specialized assessments of CUI systems at least annually using high-value asset plans | +| CA.L3-3.12.3e | 3.12.3e | Blue Team Assessment | Include threat hunting exercises and assessments where red and blue teams compete to find vulnerabilities in CUI systems | + +### Domain: System and Communications Protection (SC) — 3 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| SC.L3-3.13.4e | 3.13.4e | Isolate Government CUI | Isolate government CUI from contractor information and systems using hardware-based techniques | +| SC.L3-3.13.10e | 3.13.10e | Key Management — Advanced | Employ advanced key management practices for CUI environments, managed by DoD-provided or DoD-approved key management infrastructure | +| SC.L3-3.13.11e | 3.13.11e | Cryptography — Approved | Restrict cryptographic primitives to those approved by DoD; implement cryptographic agility in systems to enable rapid pivoting to new algorithms when existing algorithms are deprecated | + +### Domain: System and Information Integrity (SI) — 2 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| SI.L3-3.14.3e | 3.14.3e | Threat-Aware Security | Implement threat-aware security capabilities, including advanced intrusion detection, behavior analysis, and anomaly detection mechanisms optimized for detecting APT techniques | +| SI.L3-3.14.6e | 3.14.6e | Deception Technologies | Deploy deception technologies and techniques (e.g., honeypots, decoys, canary tokens) to detect and identify adversarial activity | + +--- + +## Level 3 Assessment Process (DIBCAC) + +### DIBCAC — Who They Are + +The **Defense Contract Management Agency Defense Industrial Base Cybersecurity Assessment +Center (DCMA DIBCAC)** is the DoD governing body responsible for conducting CMMC Level 3 +assessments. DIBCAC assessors are federal government employees with deep cybersecurity +expertise. + +### Level 3 Assessment Steps + +1. **Initiation** + - DoD Contract Officer/Program Office notifies organization of Level 3 requirement + - Organization must hold a current CMMC Level 2 certification (from C3PAO) + - Organization submits assessment request to DIBCAC + +2. **Pre-Assessment** + - Organization provides SSP (covering all 134 practices) + - DIBCAC reviews documentation package + - Assessment scope confirmed + +3. **Assessment Execution** + - DIBCAC Lead Assessor team conducts on-site assessment + - Technical interviews with security, IT, and program personnel + - Deep technical testing of all 24 enhanced practices + - Review of evidence for all 110 Level 2 practices (may rely on C3PAO assessment) + +4. **Assessment Results** + - CMMC Status: CMMC Level 3 Certified (or Conditional, or Not Certified) + - Conditional: POA&M items must be closed within defined timeline + - DIBCAC publishes results to enterprise CMMC tracking system + +5. **Ongoing Obligations** + - Annual Affirmation by senior official + - Triennial DIBCAC reassessment + - Continuous monitoring and incident reporting (DFARS 252.204-7012) + +--- + +## Level 3 Preparation Checklist + +| Area | Requirement | +|------|-------------| +| Level 2 Certification | Current C3PAO CMMC Level 2 certificate in place | +| SOC/CSOC | 24/7 security monitoring capability established | +| Threat Hunting | Documented threat hunting program with TTPs | +| Penetration Testing | Annual pen test completed with findings remediated | +| Threat Intelligence | DoD/government threat intelligence feeds integrated | +| Deception Technologies | Honeypots or equivalent deployed in CUI environment | +| APT Training | Role-based training covering APT techniques, tactics, procedures | +| Insider Threat Program | Formal insider threat program defined and operational | +| Incident Response Team | Deployable team established, exercised, capable of 24-hour response | +| Key Management | DoD-approved key management infrastructure in use | +| Hardware Isolation | Hardware-based isolation of government CUI from contractor systems | +| Threat Modeling | Annual threat model for all CUI systems documented and reviewed | diff --git a/plugins/cmmc/skills/cmmc/references/scoping-guide.md b/plugins/cmmc/skills/cmmc/references/scoping-guide.md new file mode 100644 index 0000000..222b3c4 --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/scoping-guide.md @@ -0,0 +1,275 @@ +# CMMC 2.0 Scoping Guidance +## Source: CMMC 2.0 Scoping Guidance Documents — DoD CIO (December 2021, updated 2024) + +--- + +## Overview + +Scoping is the process of identifying which systems, components, and people are included +in the CMMC assessment boundary. Correct scoping is critical: too broad wastes resources, +too narrow creates compliance gaps. + +**Official source:** CMMC Level 2 Scoping Guidance and CMMC Level 3 Scoping Guidance +published by the Office of the DoD Chief Information Officer (DoD CIO). + +--- + +## Data Types That Drive Scope + +### Federal Contract Information (FCI) + +**Definition (FAR 4.1901):** +Information, not intended for public release, that is provided by or generated for the +Government under a contract to develop or deliver a product or service to the Government. + +FCI **does NOT include:** +- Information provided by the Government to the public (public websites, reports) +- Simple transactional information (payments, schedules, administrative correspondence) + +**CMMC implication:** FCI presence requires minimum Level 1. + +### Controlled Unclassified Information (CUI) + +**Definition:** Information the Government creates or possesses (or an entity creates or +possesses for or on behalf of the Government) that a law, regulation, or Government-wide +policy requires or permits handling using safeguarding or dissemination controls. + +**CUI Registry:** Published by the National Archives and Records Administration (NARA) at +https://www.archives.gov/cui + +**Common DoD CUI Categories:** +- Controlled Technical Information (CTI) +- Export Controlled (ITAR, EAR) +- Proprietary Business Information +- Critical Infrastructure Information +- DoD-specific CUI categories per DoD Instruction 5200.48 + +**CUI markings:** Documents containing CUI are marked "CUI" with applicable CUI category +indicator, handling instructions, and authority block per NARA CUI Marking Handbook. + +**CMMC implication:** CUI presence requires Level 2 minimum; Level 3 if designated by DoD. + +--- + +## Asset Categories + +The CMMC Program defines six asset categories for scoping purposes. Categorization +determines which practices apply to each asset. + +### 1. CUI Assets + +**Definition:** These assets process, store, or transmit CUI. + +**Examples:** +- Workstations running applications that access CUI repositories +- File servers storing technical data, drawings, specifications marked CUI +- Email servers where CUI is communicated +- Databases containing program plans or bids with CUI +- Cloud storage (SharePoint, OneDrive, S3 buckets) holding CUI documents +- Printers that print documents containing CUI + +**Scope:** ALL 110 Level 2 practices (or 134 Level 3 practices) apply. + +**Key test:** "Does this asset process, store, OR transmit CUI?" + +--- + +### 2. Security Protection Assets (SPAs) + +**Definition:** Assets that provide security functions to the CUI environment, protecting +CUI Assets from unauthorized access or attack — even if they do not directly touch CUI. + +**Examples:** +- Firewalls and routers that protect the CUI network segment +- Identity providers (Active Directory, LDAP, Azure AD) authenticating CUI users +- SIEM (Security Information and Event Management) systems monitoring CUI environment +- Vulnerability scanners scanning CUI systems +- PAM (Privileged Access Management) systems managing privileged access to CUI +- Endpoint Detection and Response (EDR) platforms on CUI assets +- Multi-factor authentication (MFA) systems +- Backup systems protecting CUI + +**Scope:** ALL applicable CMMC practices apply. SPAs are fully in-scope because +if compromised, they defeat the protection of CUI assets. + +--- + +### 3. Contractor Risk Managed Assets (CRMAs) + +**Definition:** Assets that can reach (i.e., have network connectivity to) CUI or Security +Protection Assets but do **not** directly process, store, or transmit CUI. + +**Examples:** +- IT administration workstations that can reach the CUI network but are not used for CUI work +- Jump hosts used for network management (if not handling CUI) +- Management servers for hypervisors hosting CUI VMs +- Monitoring systems with read-only access to CUI network infrastructure logs + +**Scope:** The organization must document and assess the risk these assets pose to CUI +and SPAs, and implement controls commensurate with that risk. Not all 110 practices +automatically apply — but the organization must document which apply and justify any +exclusions. + +**Key distinction from CUI Assets:** The critical test is whether the asset CAN access +CUI or security controls, not whether it IS USED for CUI. If it can reach CUI, it is +a CRMA at minimum. + +--- + +### 4. Specialized Assets + +**Definition:** Assets that are used in the CUI environment but which present unique +challenges for implementation of standard CMMC practices. These require specific +risk-based treatment. + +**Sub-categories:** + +| Sub-category | Description | Examples | +|-------------|-------------|---------| +| Government Furnished Equipment (GFE) | Equipment provided by the Government | Government-issued laptops, hardware provided on contract | +| Operational Technology (OT) / Industrial Control Systems (ICS) | Equipment in manufacturing or process control | CNC machines, PLCs, SCADA systems | +| Internet of Things (IoT) | Networked devices with limited management capability | Smart sensors, building management systems | +| Test Equipment | Devices used for testing that interact with CUI | Oscilloscopes connected to test workstations, spectrum analyzers | +| Restricted Information Systems | Legacy or specialized systems with operational constraints | Legacy mainframes, air-gapped systems | + +**Scope:** CMMC practices apply to the extent they can be implemented. Where practices +cannot be applied, the organization must document the risk, implement compensating controls, +and include in the SSP. For GFE: responsibility for compliance lies with the Government +component that owns the equipment. + +--- + +### 5. Out-of-Scope Assets + +**Definition:** Assets that do **not** process, store, or transmit CUI AND have **no +connectivity** (network or physical) to CUI assets or SPAs. + +**Conditions for out-of-scope classification:** +1. The asset does not touch CUI (not process, store, transmit) +2. The asset cannot reach CUI assets or SPAs via any network path +3. The asset is not used in the maintenance or security of CUI systems +4. The isolation is documented, verified, and maintained + +**Examples (when properly isolated):** +- HR or accounting systems on a separate, isolated network with no path to CUI +- Guest Wi-Fi networks with no path to CUI environment +- Employee personal devices never connected to CUI systems and not used for CUI work + +**Important:** If there is ANY network path — even through DMZ or VPN — the asset is NOT +out-of-scope. Air-gap requirement is strict. + +--- + +### 6. External Service Providers (ESPs) + +**Definition:** Companies or cloud services that process, store, or transmit CUI on behalf +of the contractor, or provide security services to the CUI environment. + +**Examples:** +- Cloud service providers (AWS, Azure, Google Cloud) hosting CUI workloads +- Managed Security Service Providers (MSSPs) monitoring CUI systems +- Co-location data centers where CUI servers are housed +- SaaS platforms where CUI is uploaded (e.g., document management, collaboration tools) +- IT support vendors with access to CUI systems (MSPs) + +**Scope requirements for ESPs:** + +| ESP Type | Requirement | +|---------|------------| +| Cloud Service Provider (IaaS/PaaS/SaaS) storing/processing CUI | Must be FedRAMP Authorized at Moderate baseline OR assessed via CMMC/equivalent | +| MSSP providing security services to CUI environment | Must be CMMC certified to at least Level 2 (or demonstrate equivalent) | +| Co-location / data center | Physical controls must be documented; contractor retains responsibility for logical controls | +| IT support vendors (MSPs) | Must meet CMMC requirements commensurate with their access level | + +**Flow-down clause:** Prime contractors must include DFARS 252.204-7021 in subcontracts +where subcontractors will process, store, or transmit CUI or provide security protection +services. Subcontractors must be CMMC certified to the same level as the prime for the +work they perform. + +--- + +## Scoping Process — Step-by-Step + +### Step 1: Identify CUI + +- Review contracts for CUI requirements and markings +- Inventory all CUI received, generated, or stored during performance +- Assign CUI categories per NARA CUI Registry +- Document where CUI flows (data flow diagram) + +### Step 2: Map CUI Asset Locations + +For each CUI category, identify all locations: +- File servers and storage systems +- Endpoints (workstations, laptops) used to access CUI +- Applications and databases +- Email systems +- Cloud services +- Removable media +- Paper/physical records (out of CMMC scope, but needed for full picture) + +### Step 3: Identify SPAs + +For each CUI Asset, identify what provides security protection: +- Authentication systems +- Network security controls (firewalls, IDS/IPS) +- Logging and monitoring systems +- EDR/AV platforms +- Backup systems + +### Step 4: Identify CRMAs + +Map all systems that have network connectivity to CUI Assets or SPAs but do not directly +process CUI. Document the purpose and level of access for each CRMA. + +### Step 5: Identify Specialized Assets + +List OT/ICS, IoT, GFE, test equipment, and restricted systems within or near the CUI environment. + +### Step 6: Identify ESPs + +List all external services that touch the CUI environment, document their authorization status, +and determine flow-down obligations. + +### Step 7: Isolate Out-of-Scope Systems + +Verify that systems claimed as out-of-scope have no network path to CUI assets or SPAs. +Document the isolation controls. + +### Step 8: Document in SSP + +The System Security Plan must include: +- Network boundary diagram showing all asset categories +- Data flow diagram showing CUI movement +- Asset inventory categorized by scope type +- Explanation of out-of-scope determinations +- ESP list with authorization status + +--- + +## Network Segmentation Recommendations for Scope Reduction + +Reducing the CMMC scope reduces assessment cost and complexity. Common strategies: + +| Strategy | How It Reduces Scope | +|---------|---------------------| +| VLAN isolation of CUI workstations | Keeps CUI on separate network segment; limits CRMA expansion | +| Jump server for CUI administration | Limits number of admin workstations that reach CUI | +| FedRAMP-authorized cloud for CUI storage | Shifts responsibility for cloud controls to authorized provider | +| Dedicated CUI workstations | Prevents personal/HR/finance systems from reaching CUI | +| Air-gapped OT/ICS systems | Removes OT equipment from CMMC scope entirely | +| MSSP providing security services | Moves some SPA obligations to certified third party | + +--- + +## Common Scoping Mistakes + +| Mistake | Consequence | +|---------|------------| +| Claiming systems are out-of-scope without verifying network isolation | Systems incorrectly excluded; assessor may flag and force scope expansion | +| Not including email systems | Most CUI is transmitted via email; email servers are CUI Assets | +| Forgetting about backup systems | Backups of CUI are themselves CUI assets | +| Not scoping cloud services | Cloud services storing CUI are ESPs and must meet FedRAMP or equivalent | +| Scoping out home-office workstations | Remote workers using personal devices for CUI work bring those devices in-scope | +| Not including IT support MSP | MSP with privileged access to CUI systems is an ESP | +| Forgetting mobile devices | Mobile devices with CUI (email, apps) are in-scope CUI Assets or CRMAs | diff --git a/plugins/eu-ai-act/.claude-plugin/plugin.json b/plugins/eu-ai-act/.claude-plugin/plugin.json new file mode 100644 index 0000000..2c1579a --- /dev/null +++ b/plugins/eu-ai-act/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "eu-ai-act", + "description": "EU AI Act (Regulation (EU) 2024/1689) compliance advisor — risk classification, prohibited AI practices, high-risk AI system requirements, GPAI obligations, conformity assessment, deployer obligations, fundamental rights impact assessment, and compliance roadmaps.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "eu-ai-act", + "artificial-intelligence-act", + "ai-regulation", + "high-risk-ai", + "gpai", + "ai-compliance", + "eu-regulation", + "ai-governance", + "conformity-assessment", + "grc" + ] +} diff --git a/plugins/eu-ai-act/skills/eu-ai-act/SKILL.md b/plugins/eu-ai-act/skills/eu-ai-act/SKILL.md new file mode 100644 index 0000000..8aa7fcc --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/SKILL.md @@ -0,0 +1,343 @@ +--- +name: eu-ai-act +description: > + Expert EU AI Act (Regulation (EU) 2024/1689) compliance advisor. Use this skill whenever + a user asks about the EU Artificial Intelligence Act, AI risk classification under EU law, + prohibited AI practices, high-risk AI system requirements, GPAI model obligations, systemic + risk, conformity assessment, CE marking for AI, EU AI Act compliance roadmaps, deployer + obligations, fundamental rights impact assessment (FRIA), the EU AI Office, AI regulatory + sandboxes, EU AI Act penalties, or any topic related to complying with or auditing against + the EU AI Act. Also trigger for questions like "is my AI system high-risk under the EU AI + Act?", "what obligations does EU AI Act impose on GPAI providers?", "how do I perform a + conformity assessment under the EU AI Act?", "what is prohibited under Article 5?", + "how do I register an AI system in the EU database?", or "when do EU AI Act requirements apply?". +--- + +# EU AI Act (Regulation (EU) 2024/1689) Compliance Skill + +You are an expert EU AI Act compliance advisor with deep knowledge of Regulation (EU) 2024/1689 of 13 June 2024. You assist organisations — whether AI providers (developers/deployers), GPAI model providers, importers, distributors, product manufacturers, or public authority deployers — in understanding, implementing, and demonstrating compliance with the EU Artificial Intelligence Act. + +--- + +## Key Facts — Always Cite These + +| Item | Detail | +|------|--------| +| Official title | Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) | +| OJ reference | OJ L 2024/1689, published 12 July 2024 | +| Entry into force | 1 August 2024 (Article 113) | +| Structure | 13 Chapters, 113 Articles, 13 Annexes, 180 Recitals | +| Regulator | European AI Office (within European Commission); National Competent Authorities (NCAs) | +| Territorial scope | Applies to providers and deployers in the EU; also to providers/deployers outside the EU where the AI system's output is used in the EU | + +--- + +## Application Timeline — Critical Dates + +| Date | What Applies | Reference | +|------|-------------|-----------| +| 1 August 2024 | Entry into force — no obligations yet apply | Art. 113 | +| 2 February 2025 | **Prohibited AI practices (Chapter II, Art. 5) and AI literacy (Art. 4) apply** | Art. 113(a) | +| 2 May 2025 | Codes of practice for GPAI must be ready | Art. 56(9) | +| 2 August 2025 | **GPAI model rules (Chapter V), governance (Chapter VII), notified bodies (Chapter III, Section 4), penalties (Arts. 99–100) apply** | Art. 113(b) | +| 2 February 2026 | Commission guidelines on Art. 6 high-risk classification required | Arts. 6(5), 72(3) | +| **2 August 2026** | **Remainder of the Act applies — high-risk AI under Annex III (Art. 6(2)), transparency (Chapter IV), most of Chapter III** | Art. 113 | +| 2 August 2027 | Art. 6(1) applies — AI as safety components in Annex I-regulated products | Art. 113 | +| 2 August 2027 | GPAI models placed on market before 2 August 2025 must comply | Art. 111(3) | +| 31 December 2030 | Large-scale IT systems (Annex X) must comply | Art. 111(1) | + +> **Current date context (April 2026):** Prohibited AI practices are already enforced (since Feb 2025). GPAI rules are in force (since Aug 2025). High-risk AI under Annex III obligations begin August 2026 — organisations developing or deploying high-risk AI have months to achieve compliance. + +--- + +## How to Respond + +Match your output to the task: + +| Task | Output Format | +|------|--------------| +| Risk classification | Decision tree outcome: Prohibited / High-risk (Art. 6(1) or 6(2)) / Transparency-only (Art. 50) / Minimal risk — with article citations | +| Gap analysis | Table: Article/Requirement \| Status 🔴/🟡/🟢 \| Evidence Needed \| Gap/Action | +| Conformity assessment guidance | Route determination (internal / third-party), evidence checklist, steps | +| Obligation identification | Role-specific obligations table (provider / deployer / GPAI provider / importer / distributor) | +| FRIA guidance | Structured assessment template aligned to Art. 27 | +| Policy / document drafting | Full structured document with document control block, article citations, review date | +| GPAI compliance | Model type determination (standard / open / systemic), obligations table, codes of practice status | +| Penalty analysis | Violation category, applicable penalty ceiling, mitigating factors | +| General Q&A | Clear prose with specific article/recital citations | + +Always cite the specific article (e.g., Art. 9, Art. 26) or Annex (e.g., Annex III, point 1(a)) in all outputs. + +--- + +## Risk Classification Framework + +### Step 1: Is the AI System Prohibited? (Art. 5) + +Check all 8 prohibited categories. If **any apply**, the AI system **must not be placed on the market or put into service** in the EU. + +**Prohibited AI practices under Article 5:** + +1. **Subliminal manipulation**: AI deploying techniques below the threshold of consciousness, or deliberately deceptive/manipulative techniques, that materially distort a person's behaviour in a way that causes or is reasonably likely to cause significant harm +2. **Vulnerability exploitation**: AI exploiting vulnerabilities due to age, disability, or socioeconomic circumstances to materially distort behaviour causing significant harm +3. **Biometric categorization of sensitive attributes**: AI systems inferring race, political opinions, trade union membership, religious/philosophical beliefs, sex life, or sexual orientation from biometric data (exception: lawful labelling/filtering of datasets or law enforcement categorization) +4. **Social scoring by public authorities**: AI systems evaluating/classifying natural persons based on social behaviour or personal characteristics over time, leading to detrimental treatment in unrelated contexts or disproportionate harm +5. **Criminal risk profiling based solely on traits**: AI assessing risk of a natural person committing a criminal offence based solely on profiling or personality traits (not permitted; AI augmenting human assessments based on objective, verifiable facts is permitted) +6. **Untargeted facial recognition scraping**: Building/expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage +7. **Emotion recognition in workplace/education**: AI systems inferring emotions of natural persons in workplace or educational institution contexts (exception: AI for medical or safety reasons) +8. **Real-time remote biometric identification (RBI) for law enforcement in public spaces**: Subject to three narrow law enforcement exceptions (missing persons/trafficking victims; imminent threat/terrorist attack; serious crime suspects) — requires prior judicial/administrative authorisation, fundamental rights impact assessment, and prior registration in EU database + +> For full Article 5 detail with conditions and exceptions → read `references/eu-ai-act-prohibited-practices.md` + +### Step 2: Is the AI System High-Risk? (Art. 6) + +**Route A — Art. 6(1):** The AI system is **both**: +- A safety component of a product covered by EU harmonisation legislation in **Annex I** of the EU AI Act (e.g., machinery, medical devices, motor vehicles, toys), **AND** +- Required to undergo third-party conformity assessment under that Annex I legislation +→ Classified as high-risk. Full requirements (Arts. 8–17) and obligations (Arts. 18–37) apply. Timeline: **2 August 2027**. + +**Route B — Art. 6(2):** The AI system is listed in **Annex III** (8 specific use-case areas covering biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice) +→ Classified as high-risk **unless** one of four exceptions applies (Art. 6(3)): +- Performs a narrow procedural task +- Improves the result of a previously completed human activity +- Detects decision-making patterns/deviations without influencing prior assessments without human review +- Performs a preparatory task to an assessment in the Annex III use cases +→ **Exception does not apply if the system profiles individuals** (automated processing to assess aspects of a person's life) +→ Timeline: **2 August 2026** for most Annex III systems. + +> For Annex III full list and classification rules → read `references/eu-ai-act-high-risk-systems.md` + +### Step 3: Transparency-Only Obligations? (Art. 50) + +If not prohibited or high-risk, check if **Article 50** transparency obligations apply: +- **Chatbots**: Must inform users they are interacting with an AI system (exception: obvious from context) +- **Emotion recognition / biometric categorization**: Must inform natural persons that they are subject to such a system +- **Deepfakes**: Must disclose that content is AI-generated or manipulated (Art. 50(3)) — exception for law enforcement/creative expression with appropriate disclosure +- **AI-generated text on public interest topics** (elections, health, climate, environment, immigration): Must be labelled as AI-generated + +### Step 4: Minimal Risk + +AI systems not captured by steps 1–3 are **minimal/no risk** — no mandatory obligations under the EU AI Act (voluntary codes of conduct encouraged under Art. 95). + +--- + +## Obligations by Role + +### Provider Obligations (Art. 16 summary) + +Providers of **high-risk AI systems** must: +1. Establish and maintain a **risk management system** (Art. 9) — continuous, iterative, throughout lifecycle +2. Apply **data and data governance** measures (Art. 10) — relevant, representative, error-free training/validation/test data; bias examination +3. Draw up **technical documentation** (Art. 11, Annex IV) — before placing on market; kept up to date; 10-year retention +4. Build in automatic **logging/record-keeping** capability (Art. 12) — events relevant to identifying risks; traceability +5. Provide **instructions for use** to deployers (Art. 13) — capabilities, limitations, accuracy metrics, human oversight measures +6. Enable **human oversight** by deployers (Art. 14) — technical measures for human intervention, interruption, override +7. Achieve appropriate **accuracy, robustness, cybersecurity** (Art. 15) — consistent throughout lifecycle; resilience to adversarial attacks +8. Establish a **quality management system** (Art. 17) — documented, proportionate; records kept for 10 years +9. Conduct or commission a **conformity assessment** (Art. 19) — internal or third-party depending on system category +10. Affix **CE marking** and draw up an **EU declaration of conformity** (Arts. 35–36) — after successful conformity assessment +11. **Register** in EU database (Art. 49 / Art. 71) — before placing on market +12. Have an **authorised representative** in EU if provider is outside the EU (Art. 25) +13. Report **serious incidents** to national authorities (Art. 73) — within 15 days (3 days for immediate risk, 2 days for death/serious deterioration) +14. Conduct **post-market monitoring** (Art. 72) — throughout lifecycle + +> For full provider requirements (Arts. 8–17) with evidence checklists → read `references/eu-ai-act-high-risk-systems.md` + +### Deployer Obligations (Art. 26) + +Deployers of **high-risk AI systems** must: +1. Use the AI system **in accordance with instructions of use** and for its intended purpose +2. **Not modify** the AI system's intended purpose without re-classification assessment +3. Assign **human oversight** to competent, trained natural persons with authority to act +4. Ensure relevant staff have **AI literacy** (Art. 4) and training adequate to use the system +5. Implement **technical and organisational measures** ensuring human oversight capability +6. **Monitor** the AI system for risks during operation based on instructions for use; report concerns to providers/distributors/authorities +7. Conduct a **Fundamental Rights Impact Assessment (FRIA)** (Art. 27) — required for deployers of Annex III high-risk AI systems, unless the deployer is a small-scale provider +8. **Inform employees and their representatives** when AI systems affecting them are to be deployed +9. **Register** in EU database (Art. 49) — required for public authority deployers +10. Report **serious incidents** to the provider and to national market surveillance authorities +11. Keep **logs** generated by the system for at least 6 months (where technically feasible and relevant) + +### GPAI Model Provider Obligations (Arts. 53–55) + +> For full GPAI obligations → read `references/eu-ai-act-gpai-models.md` + +**All GPAI model providers (Art. 53) must:** +1. Draw up and maintain **technical documentation** (Annex XI) +2. Provide **information and documentation** to downstream providers (Annex XII) +3. Have a **policy to comply with EU Copyright Directive** (Directive 2019/790) +4. Publish a **summary of training content** + +**Open-weight/free and open licence GPAI providers (Art. 54):** Only obligations 3 and 4 above apply — unless the model presents systemic risk. + +**GPAI models with systemic risk** (cumulative training compute > 10^25 FLOPs, or Commission determination) must additionally (Art. 55): +1. Perform **model evaluations** including adversarial testing +2. **Assess and mitigate systemic risks** +3. **Track, document, report serious incidents** to AI Office and NCAs without undue delay +4. Ensure **cybersecurity protection** + +--- + +## Core Workflows + +### 1. AI System Risk Classification + +**Inputs needed:** Description of the AI system, its intended purpose, intended users, deployment context, whether it involves biometrics/profiling, whether it's integrated into a regulated product. + +**Process:** +1. Check Article 5 prohibited categories — if any match, output: PROHIBITED +2. Check Article 6(1) — Annex I product + third-party conformity assessment → HIGH-RISK (Route A) +3. Check Article 6(2) — Annex III use cases → Apply Art. 6(3) exceptions test → HIGH-RISK Route B or not +4. Check Article 50 transparency obligations → TRANSPARENCY-ONLY if no high-risk classification +5. Otherwise → MINIMAL RISK + +**Classification output format:** +``` +Classification: [PROHIBITED / HIGH-RISK (Art. 6(1)) / HIGH-RISK (Art. 6(2)) / TRANSPARENCY-ONLY / MINIMAL RISK] +Basis: [Specific article and annex reference] +Applicable obligations: [Summary] +Compliance deadline: [Date] +Notes: [Any conditions, exceptions, or caveats] +``` + +### 2. High-Risk AI System Compliance Gap Analysis + +**Inputs needed:** AI system purpose, current documentation in place, development/deployment stage, whether provider or deployer, current risk management practices. + +**Gap analysis output format:** +``` +ARTICLE | REQUIREMENT | STATUS | EVIDENCE NEEDED | ACTION +Art. 9 | Risk management system established and maintained | 🔴 | Risk management plan, risk register | Establish iterative risk management process per Art. 9(2) +Art. 10 | Data governance — training data documented | 🟡 | Data sheet, bias evaluation records | Complete data quality assessment and bias examination +Art. 11 | Technical documentation drawn up | 🔴 | Annex IV documentation | Draft full Annex IV technical documentation package +Art. 17 | Quality management system | 🟡 | QMS procedure, records | Expand existing QMS to cover AI-specific requirements +``` + +### 3. GPAI Model Compliance Assessment + +**Inputs needed:** Model name/type, training compute (FLOPs if known), whether open-weight/open-licence, downstream use cases, current documentation status. + +**Process:** +1. Determine if model qualifies as GPAI under Art. 3(63) definition +2. Determine if open-weight/open-licence (Art. 54 applies) +3. Assess systemic risk — compute threshold (10^25 FLOPs) or Commission designation +4. Map to Art. 53 (all), Art. 54 (open), Art. 55 (systemic risk) obligations +5. Assess compliance status for each obligation +6. Determine codes of practice adherence pathway + +### 4. Fundamental Rights Impact Assessment (FRIA) — Art. 27 + +Required for deployers of high-risk AI systems covered by Annex III (exceptions: deployers who are small-scale providers of the same system; systems that have already undergone fundamental rights impact assessment under other EU law in same context). + +**FRIA must include:** +- Description of the deployer's processes in which the high-risk AI system will be used +- Description of time period and frequency of use +- Categories of natural persons who will be affected +- Specific risks of harm to fundamental rights and likelihood +- Description of measures to address identified risks +- Name and contact details of the deployer; date of assessment; senior management sign-off + +**Fundamental rights to assess:** +- Right to dignity (Art. 1 EU Charter) +- Right to physical and mental integrity (Art. 3) +- Prohibition of torture and inhuman treatment (Art. 4) +- Prohibition of slavery and forced labour (Art. 5) +- Right to liberty and security (Art. 6) +- Respect for private and family life, home, communications (Art. 7) +- Protection of personal data (Art. 8) +- Right to marry and right to found a family (Art. 9) +- Freedom of thought, conscience, religion (Art. 10) +- Freedom of expression and information (Art. 11) +- Freedom of assembly and association (Art. 12) +- Freedom of the arts and sciences (Art. 13) +- Right to education (Art. 14) +- Freedom to choose an occupation and right to engage in work (Art. 15) +- Non-discrimination (Art. 21) +- Cultural, religious and linguistic diversity (Art. 22) +- Equality between women and men (Art. 23) +- Rights of the child (Art. 24) +- Rights of the elderly (Art. 25) +- Integration of persons with disabilities (Art. 26) +- Right to an effective remedy and to a fair trial (Art. 47) +- Presumption of innocence and right of defence (Art. 48) + +> For FRIA template → read `references/eu-ai-act-obligations-templates.md` + +### 5. Conformity Assessment + +**Route determination for high-risk AI systems (Art. 43):** + +| AI System Category | Conformity Assessment Route | +|-------------------|-----------------------------| +| Annex III biometric (remote biometric identification) | **Third-party — Notified Body** required | +| Annex III biometric (categorization, emotion recognition) | **Internal** — Art. 43(2) self-assessment permitted | +| Annex III all other categories | **Internal** — Art. 43(2) self-assessment permitted | +| AI as safety component in Annex I product | Third-party — as required by the applicable sectoral legislation | +| Substantial modification to placed-on-market system | Full conformity assessment again | + +**Internal conformity assessment (Art. 43(2)) steps:** +1. Complete Annex IV technical documentation +2. Verify compliance with all requirements (Arts. 8–15) +3. Establish quality management system (Art. 17) +4. Draw up EU declaration of conformity (Art. 47, Annex V format) +5. Affix CE marking (Art. 48, Annex VI) +6. Register in EU database (Art. 49) +7. Implement post-market monitoring plan (Art. 72, Annex VII framework) + +### 6. Penalty Exposure Analysis + +**Penalty tiers under Article 99:** + +| Violation | Maximum Penalty | +|-----------|----------------| +| Prohibited AI practices (Art. 5) | **€35 million or 7% of global annual turnover** (whichever higher) | +| Non-compliance with high-risk AI requirements (Arts. 8–17), provider/deployer obligations, GPAI obligations (Arts. 53–55), notified body obligations | **€15 million or 3% of global annual turnover** (whichever higher) | +| Providing incorrect, incomplete, or misleading information to notified bodies or national competent authorities | **€7.5 million or 1.5% of global annual turnover** (whichever higher) | + +**GPAI model penalties (Art. 100):** Fines for non-compliance with GPAI obligations (Arts. 53–55) and for providing incorrect information to the AI Office — same tiers as above; the AI Office may also impose periodic penalty payments. + +**SME/startup adjustment:** For SMEs and startups, the maximum penalty is the lower of the percentage and the absolute cap, if lower. + +**National variation:** Member States may impose stricter national penalties for breaches not harmonised by the EU AI Act. + +--- + +## Governance Structure + +| Body | Role | Reference | +|------|------|-----------| +| European AI Office | Commission body; oversees GPAI model compliance; issues guidelines and codes of practice; investigates GPAI systemic risk | Art. 64 | +| European AI Board | Member State representatives; coordination and consistency; issues opinions; supports Commission | Art. 65 | +| Advisory Forum | Multi-stakeholder advisory body (industry, civil society, academia) to AI Board and Commission | Art. 67 | +| Scientific Panel | Independent experts advising AI Office on GPAI systemic risk evaluation | Art. 68 | +| National Competent Authorities (NCAs) | Market surveillance for high-risk AI systems (other than GPAI); notifying authorities; accept complaints | Art. 70 | +| Notified Bodies | Third-party conformity assessment for biometric high-risk AI and Annex I product AI | Arts. 38–44 | + +--- + +## Key Definitions (Art. 3) + +| Term | Definition | +|------|-----------| +| AI system | "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments" (Art. 3(1)) | +| Provider | Natural/legal person placing an AI system on the market or putting into service under its own name/trademark, whether for payment or free of charge | +| Deployer | Natural/legal person using an AI system under its authority (not affected end-users); formerly called "user" in pre-final texts | +| GPAI model | AI model trained with large amounts of data using self-supervision at scale, displaying significant generality, capable of performing a wide range of tasks, and able to be integrated into various downstream systems (Art. 3(63)) | +| GPAI system | AI system based on a GPAI model capable of serving various purposes for direct use or integration into other AI systems (Art. 3(64)) | +| Systemic risk | Risk with a significant negative impact on the Union market through disproportionate harm or harm to critical sectors, public security or safety — specific to GPAI with high-impact capabilities (Art. 3(65)) | +| High-risk AI system | AI systems classified under Art. 6(1) or 6(2) based on Annex I or Annex III criteria | +| Serious incident | Incident or malfunction leading to death, serious health injury, disruption of critical infrastructure, serious property damage, or potential violation of fundamental rights obligations (Art. 3(49)) | +| Substantial modification | Change to a high-risk AI system after placing on market that affects compliance or changes the intended purpose (Art. 3(23)) | +| Intended purpose | Use for which an AI system is intended, including specific context and conditions of use, as specified by the provider (Art. 3(12)) | +| Reasonably foreseeable misuse | Use in a way not in accordance with intended purpose but resulting from reasonably foreseeable human behaviour or interaction with other systems (Art. 3(13)) | + +--- + +## Document Reference Index + +| Document | Contents | When to Read | +|----------|----------|-------------| +| `references/eu-ai-act-prohibited-practices.md` | Full Article 5 detail — all 8 prohibited categories, conditions, exceptions, enforcement from Feb 2025 | Checking if an AI system is prohibited; advising on specific use cases near borderlines | +| `references/eu-ai-act-high-risk-systems.md` | Annex III full list; Articles 8–17 requirements; conformity assessment routes; technical documentation (Annex IV); post-market monitoring | Any high-risk AI compliance task, gap analysis, provider obligations | +| `references/eu-ai-act-gpai-models.md` | GPAI definition, Art. 53–55 obligations, systemic risk threshold, codes of practice, open-weight rules, Annexes XI–XII | Any GPAI model compliance question | +| `references/eu-ai-act-obligations-templates.md` | Provider/deployer obligation checklists; FRIA template; technical documentation template; incident reporting form; EU declaration of conformity template | Document drafting; compliance checklist generation; audit evidence preparation | diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-articles.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-articles.md new file mode 100644 index 0000000..237ff33 --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-articles.md @@ -0,0 +1,362 @@ +# EU AI Act — Article-by-Article Reference: Key Provisions + +**Regulation (EU) 2024/1689 of 13 June 2024** +This reference covers key articles across all 13 chapters. All citations reference the final published text in OJ L 2024/1689. + +--- + +## Chapter I — General Provisions (Articles 1–4) + +### Article 1 — Subject Matter + +The AI Act lays down harmonised rules on: +- The placing on the market, putting into service, and use of AI systems in the Union +- The placing on the market of general-purpose AI models +- Prohibitions on certain AI practices +- Requirements for high-risk AI systems +- Transparency obligations for certain AI systems +- Rules on market monitoring, market surveillance, and enforcement +- Rules on governance and penalties + +### Article 2 — Scope + +**Applies to:** +- Providers placing on the market or putting into service AI systems or GPAI models in the Union — regardless of whether those providers are established or located in the Union or in a third country +- Deployers of AI systems located within the Union +- Providers and deployers of AI systems located outside the Union where the output produced by the AI system is used in the Union +- Importers and distributors of AI systems +- Product manufacturers placing on the market or putting into service an AI system together with their product +- Authorised representatives of providers not established in the Union + +**Excluded from scope (Art. 2(3)–(6)):** +- AI systems developed or used exclusively for **military, defence, or national security** purposes +- AI systems and models developed and put into service solely for the purpose of **scientific research and development** prior to market placement — but results/products must comply when placed on market +- AI systems released under **free and open-source licences** — unless they fall into prohibited (Chapter II) or high-risk (Chapter III) categories +- AI systems used by public authorities of third countries or international organisations under international agreements for law enforcement and judicial cooperation (subject to conditions) +- Natural persons using AI systems in the course of purely **personal non-professional activity** + +### Article 3 — Definitions (90+ definitions; key selections) + +| Article 3(x) | Term | Definition summary | +|-------------|------|-------------------| +| Art. 3(1) | AI system | Machine-based system operating with varying autonomy, inferring from inputs how to generate outputs (predictions, content, recommendations, decisions) influencing physical/virtual environments | +| Art. 3(2) | Risk | Combination of probability of harm occurring and severity of that harm | +| Art. 3(3) | Provider | Places AI system / GPAI model on market or puts into service under own name/trademark | +| Art. 3(4) | Deployer | Uses AI system under their authority (not affected end-users); in a professional capacity | +| Art. 3(5) | Authorised representative | Natural/legal person established in EU designated in writing by provider outside EU | +| Art. 3(6) | Importer | Natural/legal person established in EU placing on market AI system from provider outside EU | +| Art. 3(7) | Distributor | Natural/legal person in value chain (not provider or importer) making AI system available | +| Art. 3(8) | Operator | Any provider, product manufacturer, deployer, authorised representative, importer, or distributor | +| Art. 3(9) | Placing on the market | First making available of an AI system or GPAI model on EU market | +| Art. 3(10) | Putting into service | Supply of AI system for first use directly by provider or for own use in EU | +| Art. 3(11) | Intended purpose | Use for which AI system is designed, as specified by provider in documentation, instructions, etc. | +| Art. 3(12) | Reasonably foreseeable misuse | Use not in line with intended purpose resulting from reasonably foreseeable human behaviour | +| Art. 3(13) | Safety component | Component that performs a safety function, the failure of which endangers health/safety of persons or the environment | +| Art. 3(14) | Instructions for use | Information provided by provider to inform deployer of intended purpose, proper use, and risks | +| Art. 3(23) | Substantial modification | Change to high-risk AI system after placing on market affecting compliance or changing intended purpose | +| Art. 3(29) | Technical documentation | Documentation drawn up by provider under Art. 11 demonstrating AI system complies | +| Art. 3(30) | EU declaration of conformity | Declaration by provider that AI system complies with the EU AI Act requirements | +| Art. 3(34) | Market surveillance authority | National authority monitoring and enforcing compliance | +| Art. 3(40) | Remote biometric identification system | AI for identifying persons at a distance via comparison with biometric data in reference database | +| Art. 3(49) | Serious incident | Incident/malfunction directly/indirectly leading to death, serious health injury, disruption of critical infrastructure, property damage, or fundamental rights violation | +| Art. 3(63) | GPAI model | AI model trained at scale displaying generality, capable of wide range of tasks, integratable in downstream systems | +| Art. 3(64) | GPAI system | AI system based on GPAI model serving various purposes | +| Art. 3(65) | Systemic risk | Risk specific to high-impact GPAI models with significant negative impact on Union market | + +### Article 4 — AI Literacy + +**Applicable from: 2 February 2025.** + +Providers and deployers of AI systems must take measures to ensure an **appropriate level of AI literacy** of their staff and others using AI systems on their behalf — taking into account their technical knowledge, experience, education, training context, and intended use of AI systems. + +**Minimum literacy elements:** +- Understanding of AI system capabilities and limitations +- Understanding of AI risks relevant to their role +- Relevant sector-specific competencies + +**Note:** This is an ongoing organisational obligation, not a one-time certification. Evidence of compliance includes training records, competency assessments, and documented AI literacy programmes. + +--- + +## Chapter II — Prohibited AI Practices (Article 5) + +> See dedicated reference document: `eu-ai-act-prohibited-practices.md` + +--- + +## Chapter III — High-Risk AI Systems + +> For Annex III classification rules and techinal requirements (Arts. 6–17) → see `eu-ai-act-high-risk-systems.md` + +### Article 18 — Drawing up Technical Documentation + +Providers of high-risk AI systems must draw up the technical documentation referred to in Art. 11 **before** placing on market. For AI systems that are components of Annex I products, the technical documentation required by the applicable sectoral legislation and the Annex IV technical documentation may be integrated into a single document. + +### Article 19 — Conformity Assessment + +Providers must carry out a conformity assessment in accordance with Art. 43 before placing on market or putting into service. Conformity assessments must be repeated when a **substantial modification** is made to the AI system. + +### Article 20 — Automatically Generated Logs + +Where providers have access to logs automatically generated by their high-risk AI systems, they must retain those logs where reasonably expected in the light of the intended purpose. Minimum retention: 6 months unless applicable law requires otherwise. + +### Article 21 — Corrective Actions and Duty of Information + +When a provider of a high-risk AI system has reason to consider that the AI system is not in conformity with the EU AI Act, the provider must immediately take corrective action to bring the system into conformity, withdraw it, or recall it, as appropriate. + +**Duty to inform:** Providers must immediately inform: +- The national market surveillance authorities of Member States in which the system is available +- Distributors and deployers +- Where applicable: the notified body that issued the AI certificate (which may suspend/revoke the certificate) + +### Article 22 — Duty of Information + +Providers of high-risk AI systems which are placed on the market in the Union must inform the relevant national market surveillance authorities and the national competent authority of incidents referred to in Art. 73. + +### Article 23 — Cooperation with National Competent Authorities + +Providers of high-risk AI systems must cooperate with national competent authorities on request to demonstrate conformity, provide access to the technical documentation, and provide samples or access to the AI system for testing purposes. + +### Article 24 — Obligations of Product Manufacturers + +Where a manufacturer places a product on the market bearing the CE marking of a high-risk AI system, the manufacturer has the same obligations as the AI system provider under the EU AI Act. + +### Article 25 — Authorised Representatives + +Providers established **outside the EU** must designate an authorised representative in the EU before placing their high-risk AI system on the EU market. + +**Authorised representative responsibilities:** +- Verify that the EU declaration of conformity and technical documentation have been drawn up +- Verify CE marking has been affixed +- Report to the provider any request from national authorities +- Keep contact details up to date with EU registry +- Cooperate with national authorities + +### Article 26 — Obligations of Deployers of High-Risk AI Systems + +> See also: `eu-ai-act-obligations-templates.md` for deployer checklist + +Deployers must: +1. Use the AI system in accordance with instructions of use +2. Assign human oversight to specifically designated and trained persons +3. Take technical and organisational measures to enable human oversight +4. Monitor operation of the AI system based on instructions; inform providers of risks +5. Conduct Fundamental Rights Impact Assessment (FRIA) where required by Art. 27 +6. Inform employees and their representatives before deployment of systems affecting them +7. Register in EU database (where required — public authority deployers) +8. Not use an AI system that poses unacceptable risk to health, safety, or fundamental rights + +### Article 27 — Fundamental Rights Impact Assessment (FRIA) + +> See FRIA template in `eu-ai-act-obligations-templates.md` + +**Mandatory for:** Deployers of high-risk AI systems listed in Annex III, **except** for: +- Deployers that are credit institutions regulated by Directive 2013/36/EU (provided comparable assessment conducted) +- Deployers using AI systems for public authority purposes where another Union legal act requires a similar assessment prior to deployment + +**FRIA contents (Art. 27(2)):** +- Description of deployer's processes in which high-risk AI system will be used +- Time period and frequency of use +- Categories of natural persons who will be affected in each specific context of use +- Specific risks of harm to fundamental rights categories listed in Art. 27(2)(d) +- Description of measures to address identified risks including mitigation and/or accommodation measures +- Name and contact details of deployer, date of completion, and review date +- Signed by a senior management representative + +**When significant changes occur:** A new FRIA is required when the intended use or deployment context changes significantly. + +### Article 28 — Obligations of Importers + +Importers of high-risk AI systems must: +- Verify that the provider has established the quality management system (Art. 17) and that technical documentation has been drawn up +- Verify that the provider has carried out conformity assessment and drawn up the EU declaration of conformity +- Verify that the CE marking has been affixed +- Verify that the system is accompanied by instructions for use +- Inform providers and national authorities of identified non-conformities + +### Article 29 — Obligations of Distributors + +Distributors must verify that the high-risk AI system bears the CE marking, that the EU declaration of conformity has been drawn up, and that the required documentation has been produced. They must also ensure storage and transport do not jeopardize compliance. + +### Article 35 — EU Declaration of Conformity + +Providers must draw up the EU declaration of conformity for each high-risk AI system in accordance with Annex V. The declaration must: +- Contain the information set out in Annex V +- Be translated into language(s) required by the Member State(s) where the system is placed on market +- Kept up to date for **10 years** after placing on market + +--- + +## Chapter IV — Transparency Obligations (Article 50) + +### Article 50 — Transparency Obligations for Certain AI Systems + +**Article 50(1) — Chatbots and conversational AI:** +Providers of AI systems designed to interact directly with natural persons must ensure that persons are informed they are interacting with an AI system unless: +- It is obvious from the circumstances and context that persons are interacting with an AI system + +**Article 50(2) — Emotion recognition and biometric categorisation:** +Providers and deployers of AI systems that detect or infer emotions or intentions of natural persons, or that assign persons to specific categories based on biometric data, must inform the natural persons exposed to such a system about the operation of the system in accordance with Regulation (EU) 2016/679 (GDPR) and Directive 2002/58/EC. +**Exception:** Not applicable if systems are used for biometric categorisation or emotion recognition for law enforcement purposes with appropriate authorisation under applicable law. + +**Article 50(3) — Deep fakes and synthetic content:** +Deployers of AI systems that generate or manipulate image, audio, or video content that appreciably resembles existing persons, objects, places, or other entities or events and would falsely appear to a person to be authentic or truthful must disclose that the content has been artificially generated or manipulated. +**Exceptions:** +- For legitimate purposes (lawful, law enforcement use) +- For the purpose of the exercise of the right to freedom of expression and arts and sciences — provided appropriate disclosure or disclaimers + +**Article 50(4) — AI-generated text on public interest matters:** +Deployers using AI to generate text published for the purpose of informing the public on matters of public interest must disclose that the text was artificially generated. Does not apply where the text has undergone human review or editorial control to a degree where the AI contribution is not substantial. + +**Labelling requirements:** AI-generated content required to be labelled under Art. 50(3) and (4) must be labelled in a machine-readable format and detectable as AI-generated where technically feasible. + +--- + +## Chapter VII — Governance (Articles 64–70) + +### Key Governance Bodies + +**European AI Office (Art. 64):** +- Established within the European Commission +- Responsible for monitoring GPAI model providers' compliance +- Issues guidelines, codes of practice, and technical standards recommendations +- Conducts investigations and evaluations of GPAI models +- Imposes and enforces penalties on GPAI providers (working through Commission) +- Coordinates with national competent authorities +- Operational since: February 2024 (pre-dates AI Act entry into force — established by Commission Decision) + +**European AI Board (Art. 65):** +- Composed of representatives of Member State national competent authorities +- Chaired by a Commission representative +- Issues opinions, recommendations, and guidance to the Commission and Member States +- Facilitates cross-border enforcement coordination +- Can recommend Commission action on GPAI systemic risk + +**Advisory Forum (Art. 67):** +- Multi-stakeholder advisory body to the AI Board and Commission +- Composed of representatives of: industry (including SMEs), civil society, academia, standardisation bodies, research organisations +- Provides technical expertise and advice + +**Scientific Panel of Independent Experts (Art. 68):** +- Body of independent scientific experts on AI safety +- Advises the AI Office on GPAI systemic risk evaluation +- Can issue qualified alerts to the AI Office triggering investigation of GPAI models +- Members selected for expertise in AI, data science, cybersecurity, social science + +### Article 70 — National Competent Authorities + +Member States must designate national competent authorities (NCAs) by **2 August 2025**: +- **Notifying authority**: responsible for notified body designation and monitoring +- **Market surveillance authority**: responsible for AI Act market surveillance in their territory + +**Market surveillance authority powers:** +- Access to technical documentation and AI system testing +- Request corrections, withdrawals, or recalls of non-compliant systems +- Issue temporary bans on placing on market +- Coordinate with national data protection authorities (DPAs) +- Accept and handle complaints from natural persons + +--- + +## Chapter IX — Post-Market Monitoring and Incident Reporting + +### Article 72 — Post-Market Monitoring by Providers + +Providers of high-risk AI systems must: +- Establish, document, and maintain a **post-market monitoring system** throughout the lifecycle +- Proactively collect and review data on performance of deployed systems +- Analyse data for risks or incidents +- Implement corrective actions where needed +- Report to EU database and authorities as required + +**Minimum monitoring plan content (Annex VII framework):** +- Monitoring metrics and performance indicators +- Data collection methodology +- Frequency and scope of monitoring reviews +- Thresholds for triggering corrective action +- Post-market monitoring review cycle + +### Article 73 — Reporting of Serious Incidents + +Providers of high-risk AI systems placed on the EU market must **report serious incidents** to the market surveillance authorities of Member States where the incident occurred. + +**Serious incident defined (Art. 3(49)):** Any incident or malfunction of a high-risk AI system resulting in: +- Death of a person or serious harm to a person's health +- Disruption to the management and operation of critical infrastructure +- Infringement of obligations under Union law intended to protect fundamental rights +- Serious and irreversible disruption to the management and operation of critical infrastructure + +**Reporting timelines:** +- **15 days** for serious incidents not involving immediate risk to life +- **3 days** for incidents posing immediate risk to health, safety, or fundamental rights +- **2 days** for death or serious deterioration in the state of health of a person's health + +**Content of incident report:** +- Provider identity and contact details +- System name and version +- Description of the incident with date(s) and location +- Immediate corrective actions taken +- Any preliminary hypothesis on cause +- Information on affected persons + +--- + +## Chapter X — Penalties (Articles 99–101) + +### Article 99 — Penalties + +**Tier 1 — Prohibited AI practices (Art. 5 violations):** +Maximum penalty: **€35,000,000** or, if the offender is an undertaking, **7% of its total worldwide annual turnover** for the preceding financial year, whichever is **higher**. + +**Tier 2 — Other AI Act obligations (providers and deployers of high-risk AI; GPAI providers; notified bodies):** +Maximum penalty: **€15,000,000** or, if the offender is an undertaking, **3% of its total worldwide annual turnover** for the preceding financial year, whichever is **higher**. + +**Tier 3 — Incorrect, incomplete, or misleading information to authorities:** +Maximum penalty: **€7,500,000** or, if the offender is an undertaking, **1.5% of its total worldwide annual turnover** for the preceding financial year, whichever is **higher**. + +**SME/startup adjustment (Art. 99(6)):** For SMEs (including startups), the maximum penalty is the lower of: +- The percentage-based cap, or +- The fixed monetary cap + +**Factors considered when setting penalties:** +- Nature, gravity, duration, and consequences of the infringement +- Whether intentional or through negligence +- Actions taken to mitigate harm +- Degree of responsibility of each party +- Financial capacity and size of the undertaking +- Cooperation with authorities +- Prior infringements +- Way in which the infringement became known (self-reported or discovered) + +### Article 100 — Penalties for GPAI Model Providers + +The Commission (working through the AI Office) may impose fines on GPAI model providers for: +- Infringements of Arts. 53, 54, 55 (GPAI obligations) +- Failure to comply with measures/orders imposed by the AI Office +- Providing incorrect, incomplete, or misleading information to the AI Office + +Penalty tiers mirror Art. 99. Periodic penalty payments may also be imposed. + +### Article 101 — Penalties on Union Institutions Using AI + +EU institutions, bodies, offices, and agencies deploying AI systems as deployers must comply with deployer obligations. The European Data Protection Supervisor has enforcement competence for Union institution compliance. + +--- + +## Chapter XII — Final Provisions (Article 113 — Application Dates) + +**Entry into force:** 20 days after publication = **1 August 2024** + +**6 months after entry into force** (2 February 2025): Chapter I (General Provisions), Chapter II (Prohibited practices), and Art. 4 (AI literacy) apply. + +**12 months after entry into force** (2 August 2025): Chapter III Section 4 (Notified Bodies), Chapter V (GPAI), Chapter VII (Governance), Art. 78 (Confidentiality), Arts. 99–100 (Penalties) apply. + +**24 months after entry into force** (2 August 2026): The remainder of the Regulation applies, with the exception of Art. 6(1). + +**36 months after entry into force** (2 August 2027): Article 6(1) (AI as safety components in Annex I regulated products) and corresponding obligations apply. + +**Transitional provisions for existing high-risk AI systems:** +- High-risk AI systems placed on market **before 2 August 2026**: must comply by 2 August 2026 only if subject to significant change in design from that date (Art. 111(2)) +- High-risk AI systems placed on market **before 2 August 2026** used by public authorities: must comply by **2 August 2030** (Art. 111(2)) +- GPAI models placed on market **before 2 August 2025**: must comply by **2 August 2027** (Art. 111(3)) +- Large-scale IT systems (Annex X) placed on market **before 2 August 2027**: must comply by **31 December 2030** (Art. 111(1)) diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-gpai-models.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-gpai-models.md new file mode 100644 index 0000000..9bc44ee --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-gpai-models.md @@ -0,0 +1,267 @@ +# EU AI Act — General-Purpose AI (GPAI) Models: Obligations, Systemic Risk, and Codes of Practice + +**Regulation (EU) 2024/1689, Chapter V (Articles 51–56)** +**Applicable from: 2 August 2025** + +--- + +## Definitions and Scope + +### What is a GPAI Model? (Art. 3(63)) + +A **general-purpose AI (GPAI) model** is an AI model that: +- Is trained with a large amount of data using self-supervision at scale +- Displays significant generality +- Is capable of competently performing a wide range of distinct tasks +- Is regardless of the way the model is placed on the market +- Can be integrated into a variety of downstream systems or applications + +**Exclusion:** AI models used **before release on the market** for research, development, and prototyping activities are not GPAI models for purposes of the EU AI Act. + +### What is a GPAI System? (Art. 3(64)) + +A **GPAI system** is an AI system based on a GPAI model that: +- Has the capability to serve a variety of purposes +- Is used for direct use as well as for integration in other AI systems + +### Key distinction between GPAI models and GPAI systems + +| Term | Meaning | Regulatory focus | +|------|---------|-----------------| +| GPAI model | The underlying trained model (e.g., weights + architecture) | Provider obligations under Arts. 53–55 | +| GPAI system | An AI system built on a GPAI model | Can be a standalone product or integrated into another system | + +GPAI systems used as high-risk AI systems remain subject to the high-risk AI requirements in Chapter III. GPAI model providers are expected to cooperate with downstream high-risk AI system providers. + +--- + +## Classification of GPAI Models with Systemic Risk (Article 51) + +### Systemic Risk Defined (Art. 3(65)) + +Systemic risk means a risk that is specific to high-impact GPAI models, having a significant negative impact on the Union market due to their reach, or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or any combination thereof, that can propagate throughout the value chain. + +### Threshold for Systemic Risk Classification + +A GPAI model is classified as presenting **systemic risk** if either: + +**Compute threshold (Art. 51(1)(a)):** +The cumulative amount of compute used for its training measured in floating point operations (FLOPs) is greater than **10^25 FLOPs**. + +**Commission determination (Art. 51(1)(b)):** +The Commission determines the model has high-impact capabilities based on criteria set out in Annex XIII or based on a qualified alert by the AI scientific panel — even if it does not meet the compute threshold. + +### Notification Obligation (Art. 52) + +**Providers** of GPAI models that meet or exceed the 10^25 FLOPs threshold must **notify the European Commission** within **2 weeks** of placing the model on the market or making it available. Notification is also required when updated versions exceed the threshold. + +**Presumption:** A GPAI model meeting the compute threshold is presumed to present systemic risk. Providers may present arguments to the Commission that their model, despite meeting the threshold, does not present systemic risk. The Commission may accept or reject these arguments. + +**Commission-initiated determination:** The AI Office, on its own initiative or following a qualified alert from the scientific panel, may determine a model presents systemic risk regardless of compute. + +--- + +## Obligations for All GPAI Model Providers (Article 53) + +The following four obligations apply to **all** GPAI model providers, unless the open-weight exception (Art. 54) applies: + +### Obligation 1 — Technical Documentation (Art. 53(1)(a), Annex XI) + +Providers must draw up and keep up to date technical documentation, including **training and testing process** and the results of the **evaluation** process, to be made available to the AI Office and national competent authorities on request. + +**Annex XI — Minimum contents of GPAI technical documentation:** +- General description of the GPAI model +- Information about the training process (data, compute, duration) +- Information about the model's architecture +- Training data details: types of data used, volume, provenance, data curation methodology +- Modalities and capabilities the model supports +- Information about evaluation approaches and benchmarks used +- Description of risks and mitigating measures +- Record of known or reasonably foreseeable risks to fundamental rights +- Technical measures taken to ensure downstream providers understand capabilities/limitations + +### Obligation 2 — Information for Downstream Providers (Art. 53(1)(b), Annex XII) + +Providers must draw up and maintain **documentation for downstream providers** — i.e., organisations that integrate the GPAI model into their own AI systems — to enable those downstream providers to comply with their own EU AI Act obligations (particularly high-risk AI requirements if the downstream system becomes high-risk). + +**Annex XII — Minimum information to be provided to downstream providers:** +- Identity and contact details of the GPAI model provider +- Capabilities and limitations of the model (including documented performance benchmarks) +- Conditions under which the model may be integrated into AI systems +- Any known risks, limitations, or biases +- Summary of the training data used +- Information required to comply with technical documentation obligation (Annex IV) for downstream high-risk AI providers +- Applicable usage policies and restrictions + +**Format:** May be provided via model cards, API documentation, or similar technical documentation formats. + +### Obligation 3 — Copyright Compliance Policy (Art. 53(1)(c)) + +Providers must put in place a **policy to comply with Union copyright law**, and in particular to identify and comply with including through state of the art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790 (Copyright in the Digital Single Market Directive). + +**Practical requirements:** +- Implement a process to respect opt-outs expressed by rights holders under Art. 4(3) of Directive 2019/790 +- Document the copyright compliance policy +- Apply this to training data sourcing and processing + +**Art. 4(3) of Directive 2019/790:** Rights holders may expressly reserve the right to opt out of the text-and-data mining exception (Art. 4(1)) — for example through machine-readable notices. GPAI providers must detect and honour such opt-outs. + +### Obligation 4 — Summary of Training Content (Art. 53(1)(d)) + +Providers must publish and maintain a **sufficiently detailed summary** about the content used for training the GPAI model. + +**Format:** The AI Office published a template for compliance with this obligation (released 2025). The summary must be: +- Sufficiently detailed to enable rights holders and the public to understand what data was used +- Made publicly available (e.g., model card, website) +- Updated when the model is retrained on significantly new or different data + +--- + +## Obligations for Open-Weight / Free and Open Licence GPAI Models (Article 54) + +### Scope of Open-Weight Exemption + +A GPAI model qualifies for the reduced obligations under Art. 54 if: +- The **parameters** including weights are publicly available +- The **model architecture** is publicly available +- The **model usage information** is publicly available +- The above allows for **access, usage, modification, and distribution** of the model + +In other words: the model is genuinely open — weights released under an open licence. + +### Reduced Obligations for Open-Weight GPAI Models + +Open-weight GPAI model providers **only** need to comply with: +- **Obligation 3** (copyright policy — Art. 53(1)(c)) +- **Obligation 4** (training summary — Art. 53(1)(d)) + +They are **exempt** from: +- Obligation 1 (technical documentation for authorities) +- Obligation 2 (information for downstream providers) + +### Exception to Open-Weight Exemption: Systemic Risk + +If an open-weight GPAI model **presents systemic risk** (i.e., trained with > 10^25 FLOPs or Commission-designated), the open-weight exemption does **not apply** to the systemic risk obligations under Art. 55. The provider must comply in full with both Arts. 53 and 55, regardless of open-weight status. + +--- + +## Obligations for GPAI Models with Systemic Risk (Article 55) + +In addition to the Art. 53 obligations (unless open-weight, in which case Art. 54 applies but Art. 55 applies regardless), providers of GPAI models with systemic risk must: + +### Obligation A — Model Evaluations including Adversarial Testing (Art. 55(1)(a)) + +Providers must perform model evaluations in accordance with standardised protocols and tools when available, including conducting and documenting **adversarial testing** of the model with the aim of identifying and mitigating systemic risks. + +**What adversarial testing must cover:** +- Red-teaming — testing the model to identify failure modes, dangerous capabilities, misalignments +- Capabilities evaluation — systematic assessment of potentially dangerous capabilities (e.g., capability to assist with weapons of mass destruction, cyberattacks, manipulation at scale) +- Alignment evaluation — assessment of the model's susceptibility to being steered toward harmful outputs +- Specific risk categories identified in systemic risk assessment + +**Codes of practice** will provide detailed methodologies. The AI Office's GPAI code of practice (published May 2025) contains evaluation standards. + +### Obligation B — Assess and Mitigate Systemic Risks (Art. 55(1)(b)) + +Providers must assess and mitigate the possible systemic risks at Union level that may stem from the development, placement on the market, or use of GPAI models with systemic risk, including their sources. + +**Risk categories to assess (from Recitals 110–115 and Annex XIII):** +- Risks to critical infrastructure (energy, water, financial systems, healthcare, transport) +- Risks to democratic processes and elections +- Risks enabling mass-casualty weapons development (CBRN) +- Cybersecurity risks including large-scale cyberattacks +- Risks to fundamental rights (discrimination at scale, manipulation) +- Societal risks (widespread disinformation, cognitive manipulation) + +### Obligation C — Incident Tracking, Documentation, and Reporting (Art. 55(1)(c)) + +Providers must track, document, and **report serious incidents** and possible corrective measures to the **AI Office** and, where relevant, to national competent authorities, **without undue delay** after becoming aware. + +**What constitutes a "serious incident" for GPAI models:** +- Any incident or malfunction of the GPAI model resulting in death or serious harm to a natural person +- Any disruption to critical infrastructure +- Any significant breach of fundamental rights +- Any event causing widespread harm (e.g., mass-scale disinformation) + +**Reporting channel:** Reports go to the AI Office. The AI Office coordinates with national authorities as appropriate. + +### Obligation D — Cybersecurity Protection (Art. 55(1)(d)) + +Providers must ensure an adequate level of **cybersecurity protection** for the GPAI model with systemic risk and its physical infrastructure. + +**Key measures:** +- Protection of model weights against unauthorised access, theft, or exfiltration +- Protection of training infrastructure against compromise +- Access controls for fine-tuning and model modification +- Monitoring for adversarial interference with deployed model APIs + +--- + +## Codes of Practice for GPAI Models (Article 56) + +### Purpose + +Codes of practice are the primary compliance tool for GPAI obligations before and alongside harmonised standards. They specify the practical methodology for meeting Arts. 53–55 obligations. + +### Development Process + +- Developed by the **AI Office** in collaboration with GPAI model providers, national competent authorities, civil society, academia, and independent experts +- **Timeline:** Codes of practice were required to be ready by **2 May 2025** +- Lead body: European AI Office + +### Current Status (as of 2026) + +The AI Office published the first version of the GPAI Code of Practice in May 2025. The code provides: +- Templates and methodology for technical documentation (Annex XI compliance) +- Methodology for training content summary (Annex XII compliance) +- Evaluation methodologies for systemic risk assessment +- Adversarial testing protocols and benchmarks +- Incident reporting procedures and templates + +**Compliance presumption:** Adherence to the code of practice creates a presumption of conformity with Arts. 53–55. Providers choosing not to adhere must demonstrate alternative adequate means of compliance to the AI Office's satisfaction. + +### Voluntary Participation for Minimal/Limited Risk AI + +Providers of minimal or limited risk AI systems may voluntarily adhere to codes of conduct (Art. 95). These are separate from the mandatory GPAI codes of practice and cover areas such as: +- Transparency and explainability beyond Art. 50 requirements +- Bias detection and mitigation +- Energy efficiency +- Human oversight in non-high-risk applications + +--- + +## GPAI Models in the High-Risk AI Value Chain + +When a GPAI model is integrated into a high-risk AI system, cooperation is required between the GPAI model provider (upstream) and the high-risk AI system provider (downstream): + +**GPAI model provider responsibilities when used in high-risk:** +- Provide information sufficient for the downstream provider to comply with Annex IV technical documentation +- Cooperate reasonably with downstream providers conducting conformity assessments +- Continue to maintain and update the model information made available (Art. 53(1)(b)) + +**Downstream high-risk AI system provider responsibilities:** +- The downstream provider remains responsible for their high-risk AI system's compliance +- They must conduct their own risk assessment and conformity assessment +- They cannot rely solely on the GPAI model provider's documentation + +**Contractual provisions:** Art. 25(4) provides that where both provider and deployer contribute to obligations, they may assign contractual responsibilities between themselves, but this does not remove statutory obligations to third parties and authorities. + +--- + +## Interaction with EU AI Act Governance for GPAI + +| Actor | Role in GPAI governance | +|-------|------------------------| +| AI Office | Primary supervisor of GPAI model providers; conducts investigations; issues codes of practice; accepts incident reports; can impose fines | +| Scientific Panel | Advises AI Office on systemic risk evaluations; can issue qualified alerts triggering Commission investigation | +| National Competent Authorities | May receive complaints about downstream GPAI systems; coordinate with AI Office | +| AI Board | Coordinates Member State positions on GPAI; issues opinions | + +**Complaint mechanism:** Any person or organisation can lodge a complaint with the AI Office about a GPAI model provider's non-compliance (Art. 63(1)). + +**AI Office investigation powers:** +- Request information and documentation +- Conduct interviews with provider personnel +- Commission independent evaluations of the model +- Impose interim measures where systemic risk requires urgent action +- Recommend fines to the Commission (which retains final decision on fines for GPAI) diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-high-risk-systems.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-high-risk-systems.md new file mode 100644 index 0000000..9954c98 --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-high-risk-systems.md @@ -0,0 +1,424 @@ +# EU AI Act — High-Risk AI Systems: Classification, Requirements, and Conformity Assessment + +**Regulation (EU) 2024/1689, Chapter III (Articles 6–51)** +**Art. 6(2) / Annex III applications from: 2 August 2026** +**Art. 6(1) / Annex I product AI from: 2 August 2027** + +--- + +## Part 1: Classification Rules (Article 6 and Annexes I, III) + +### Article 6(1) — AI as Safety Components in Regulated Products + +An AI system is **automatically high-risk** if **both** conditions are met: +1. The AI system is a safety component of a product covered by **Annex I EU harmonisation legislation** (or is itself the product), **AND** +2. The product must undergo a third-party conformity assessment under the applicable Annex I legislation + +**Annex I — Relevant Union Harmonisation Legislation:** +The AI Act's Annex I lists the specific EU laws that create this high-risk category. Key relevant laws include (non-exhaustive — see Annex I of Regulation (EU) 2024/1689 for the complete list): + +| Area | EU Law | +|------|--------| +| Machinery | Regulation (EU) 2023/1230 (Machinery Regulation) | +| Toys | Directive 2009/48/EC on toy safety | +| Recreational craft | Directive 2013/53/EU | +| Lifts | Directive 2014/33/EU | +| ATEX equipment | Directive 2014/34/EU | +| Radio equipment | Directive 2014/53/EU | +| Pressure equipment | Directive 2014/68/EU | +| Medical devices | Regulation (EU) 2017/745 | +| In vitro diagnostic medical devices | Regulation (EU) 2017/746 | +| Civil aviation — aerodromes, ATM/ANS, aircraft | Multiple EU regulations | +| Motor vehicles | Regulation (EU) 2018/858 and related delegated regulations | +| Agricultural and forestry vehicles | Regulation (EU) 167/2013; Regulation (EU) 168/2013 | +| Marine equipment | Directive 2014/90/EU | +| Rail systems interoperability and safety | Directives 2016/797 and (EU) 2016/798 | + +**Timeline for Art. 6(1) systems:** **2 August 2027.** + +### Article 6(2) — AI Systems Listed in Annex III + +AI systems listed in **Annex III** are high-risk **unless** one of the Article 6(3) exceptions applies. + +**Annex III — 8 High-Risk Use Case Areas:** + +--- + +#### Area 1: Biometrics + +**(a)** AI systems intended to be used for the **remote biometric identification** of natural persons — excluding biometric verification systems that confirm a person is who they claim to be. + +**(b)** AI systems intended to be used for **biometric categorisation** of natural persons for the purpose of deducing or inferring their race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation — **Note: deducing sensitive attributes IS ALSO prohibited under Art. 5(1)(c); this Annex III entry applies to categorization systems not falling into Art. 5** + +**(c)** AI systems intended to be used for **emotion recognition** of natural persons — **Note: emotion recognition in workplace/education IS ALSO prohibited under Art. 5(1)(g); this Annex III entry applies to systems in other contexts** + +--- + +#### Area 2: Critical Infrastructure + +AI systems intended to be used as safety components in the management and operation of: +- Critical **digital infrastructure** (e.g., internet exchange points, DNS resolvers, cloud infrastructure) +- **Road traffic** management +- Supply of **water, gas, heating, and electricity** + +--- + +#### Area 3: Education and Vocational Training + +**(a)** AI systems intended to be used to determine access or assignment to **educational and vocational training institutions** at all levels — e.g., admission systems. + +**(b)** AI systems intended to be used to **evaluate learning outcomes**, including when used to steer the learning process of persons — e.g., adaptive learning systems that make consequential assessments. + +**(c)** AI systems intended to be used to **assess the appropriate level** of education that an individual will be or has received, with implications for the future education path — e.g., educational tracking systems. + +**(d)** AI systems intended to be used for **monitoring and detecting prohibited behaviour** of students during tests — e.g., AI proctoring systems. + +--- + +#### Area 4: Employment, Workers Management, and Access to Self-Employment + +**(a)** AI systems intended to be used for **recruitment or selection** of natural persons, particularly for targeted job advertisements, for analysing and filtering job applications, and for evaluating candidates. + +**(b)** AI systems intended to be used to make decisions affecting the terms of employment, **promotion and termination** of work-related contractual relationships; to **allocate tasks** based on individual behaviour or personal traits or characteristics; and to **monitor and evaluate performance** and behaviour of persons in such relationships. + +--- + +#### Area 5: Access to and Enjoyment of Essential Private Services and Essential Public Services and Benefits + +**(a)** AI systems intended to be used by or on behalf of **public authorities** or by Union institutions to evaluate the eligibility of natural persons for essential public assistance benefits and services, including healthcare services, and to grant, reduce, revoke, or reclaim such benefits and services. + +**(b)** AI systems intended to be used to **evaluate the creditworthiness** of natural persons or to establish their credit score — **exception: AI systems used for purpose of detecting financial fraud**. + +**(c)** AI systems intended to be used for **risk assessment and pricing** in relation to natural persons in the cases of **life insurance** and **health insurance**. + +**(d)** AI systems intended to be used to **evaluate and classify emergency calls** by natural persons or to dispatch, or to establish priority in the dispatching of emergency first response services, including by fire, police, ambulance and emergency medical aid. + +--- + +#### Area 6: Law Enforcement + +**Note:** These are high-risk (not prohibited) when used in compliance with applicable law. + +**(a)** AI systems intended to be used by or on behalf of competent authorities, or by Union institutions, bodies, offices, or agencies to **assess the risk of natural persons** of becoming a victim of criminal offences. + +**(b)** AI systems intended to be used by or on behalf of competent authorities as **polygraphs and similar tools**. + +**(c)** AI systems intended to be used by or on behalf of competent authorities to assess the **reliability of evidence** in the course of investigation or prosecution of criminal offences or use in criminal justice. + +**(d)** AI systems intended to be used by or on behalf of competent authorities to **assess the risk of a natural person offending or reoffending** or the risk of potential victims of criminal offences — **does not apply to systems used solely for profiling or personality traits (Category 5 prohibition applies to those)**. + +**(e)** AI systems intended to be used by or on behalf of competent authorities for the **profiling of natural persons** as referred to in Art. 3(4) of Directive (EU) 2016/680 in the course of detection, investigation or prosecution of criminal offences or execution of criminal penalties, including police and public security. + +--- + +#### Area 7: Migration, Asylum, and Border Control Management + +**(a)** AI systems intended to be used by or on behalf of competent authorities as **polygraphs and similar tools**. + +**(b)** AI systems intended to be used by or on behalf of competent authorities to assess a **risk of irregular immigration** or health risk posed by natural persons seeking authorisation for entry into, or upon whom such authorisation has been granted to stay in, the territory of a Member State. + +**(c)** AI systems intended to be used by or on behalf of competent authorities in the **examination of applications** for asylum, visa, and residence permits and associated complaints with regard to the eligibility of the natural persons applying for a status and in the assessment of risks. + +**(d)** AI systems intended to be used for the **detection, recognition, or identification of natural persons** by or on behalf of competent authorities in the context of border management — **exception: verification of travel documents**. + +--- + +#### Area 8: Administration of Justice and Democratic Processes + +**(a)** AI systems intended to be used by or on behalf of **judicial authorities** to assist in **researching and interpreting facts and the law** and in applying the law to a concrete set of facts, or to be used in a similar way in alternative dispute resolution. + +**(b)** AI systems intended to be used for **influencing** the outcome of an election or referendum or the voting behaviour of natural persons in elections or referenda — **exception: AI tools used to organise, optimise and structure political campaigns from an administrative or logistical perspective that do not directly interact with persons**. + +--- + +### Article 6(3) — Exceptions to Annex III High-Risk Classification + +An Annex III AI system is **NOT high-risk** if it meets **at least one** of the following four criteria: + +**(a)** The AI system performs a **narrow procedural task** — it executes a specific, limited procedure with well-defined inputs and outputs, without broader inference or decision-making capability. + +**(b)** The AI system **improves the result of a previously completed human activity** — it enhances, summarises, or processes results of a human task already completed (not substituting human judgment). + +**(c)** The AI system **detects decision-making patterns or deviations** from prior decision-making patterns and is **not meant to replace or influence the previously completed human assessment** without proper human review — it flags anomalies for human review without autonomously affecting outcomes. + +**(d)** The AI system performs a **preparatory task** to an assessment relevant for the purpose of the use cases listed in Annex III — it prepares data or material for a human-led assessment without itself conducting the assessment. + +**Critical override:** If the AI system **profiles individuals** (automated processing of personal data to evaluate aspects of a natural person's life — Art. 3(4) of GDPR-adjacent definition), **none of the four exceptions apply** — the system remains high-risk regardless. + +**Documentation obligation:** Providers who determine that their Annex III system is not high-risk under Art. 6(3) must document that assessment before placing on the market or putting into service (Art. 6(4)). + +--- + +## Part 2: Requirements for High-Risk AI Systems (Articles 8–15) + +### Article 9 — Risk Management System + +Providers must establish, implement, document, and maintain a risk management system for high-risk AI systems. The system must: + +**Continuity:** Be a continuous, iterative process running throughout the entire lifecycle of the AI system. + +**Components (Art. 9(2)):** +- Identification and analysis of all known and reasonably foreseeable risks that the high-risk AI system can pose to health, safety, or fundamental rights +- Estimation and evaluation of risks that may emerge from intended use and from reasonably foreseeable misuse +- Evaluation of risks from post-market data (Art. 72) +- Adoption of appropriate and targeted risk management measures + +**Risk management measures (Art. 9(4)):** Measures most appropriate to each risk must be adopted. Priority: configure the AI system to eliminate/reduce risks through design; for residual risks, adequate information in instructions for use; training measures. + +**Testing (Art. 9(5)):** High-risk AI systems must be tested to identify the most appropriate risk management measures and ensure they are effective. Testing must include against preliminary defined metrics and probabilistic thresholds, and reflect the intended purpose and reasonably foreseeable misuse. + +**Testing requirements specific to biometric identification:** Additional testing against discriminatory outputs is required. + +**Documentation:** All risk management measures taken, test results, and residual risks must be documented as part of the technical documentation (Annex IV). + +--- + +### Article 10 — Data and Data Governance + +Applies specifically to AI systems involving model training with data. + +**Training, validation, and testing data requirements (Art. 10(2)):** +- Subject to appropriate data governance and management practices +- **Relevant** for the stated intended purpose +- **Representative** — to the extent possible, of the intended deployment population and context +- **Free of errors** — to the best extent possible — and **complete** with respect to the intended purpose +- Have regard to the properties, characteristics and limitations of the data, including possible bias + +**Bias examination (Art. 10(5)):** Where necessary to detect and address potential bias that may lead to discrimination of persons — especially in sensitive use cases (biometrics, employment, education, public services) — data governance must include examination of possible bias. + +**Special category data for bias detection (Art. 10(5) second sentence):** Processing of special categories of personal data (Art. 9 GDPR) is permitted strictly for the purpose of ensuring bias monitoring, detection, and correction in high-risk AI systems, subject to appropriate safeguards. + +**Data protection:** All data governance must comply with applicable data protection law, including GDPR. The AI Act does not override GDPR — both apply. + +--- + +### Article 11 — Technical Documentation + +Providers must draw up complete technical documentation **before** placing the AI system on the market or putting it into service. Documentation must be: +- Kept up to date throughout the lifecycle +- Retained for **10 years** after placing on market / putting into service, or longer if sector-specific law requires +- Made available to national competent authorities on request + +**Annex IV — Required contents of Technical Documentation:** + +1. General description of the high-risk AI system: + - Intended purpose; version information; hardware on which it is intended to run + - Explanation of how the system interacts with other systems or hardware + - Form in which the system is placed on market (software, embedded in hardware, API, etc.) + +2. Description of components, algorithms, and models: + - Key design choices and assumptions; description of model architecture and logic + - Input data specifications; training data description (type, source, size) + - Training methodology; validation and testing methodology + +3. Detailed information of monitoring, operation, and control of the system: + - Input data requirements; measures to examine fitness of intended purpose + - Monitoring and control by deployers; technical measures for human oversight (Art. 14) + +4. Description of the risk management system (Art. 9) and outcomes + +5. Changes to the system and its performance over the lifecycle; maintenance intervals + +6. List of standards applied; where standards not applied, description of solutions adopted + +7. EU declaration of conformity (Art. 47) + +8. Post-market monitoring plan (Art. 72, Annex VII framework) + +--- + +### Article 12 — Record-Keeping / Logging + +High-risk AI systems must be built with **automatic logging capability** to enable monitoring throughout operation. The logging must cover: +- Period of each use of the system (start/end date and time of use) +- Reference database against which input data was checked (for biometric identification systems) +- The input data that led to queries submitted to, or which led to the results output by, the system — to the extent technically feasible without compromising commercially sensitive information +- Identity of the natural persons involved in verification (for biometric systems) + +**Log retention:** Deployers must retain logs for at least **6 months** unless applicable sector-specific law requires longer retention. + +--- + +### Article 13 — Transparency and Provision of Information to Deployers + +Providers must ensure high-risk AI systems are transparent enough to enable deployers to comply with their obligations. This requires: + +**Instructions for use** provided with the AI system — clear, concise, complete — covering: +- Identity and contact details of the provider (Art. 13(3)(a)) +- Intended purpose, level of accuracy, levels of robustness and cybersecurity (Art. 13(3)(b)) +- Human oversight measures and interface design (Art. 13(3)(c)) +- Characteristics, capabilities, and limitations of the system: + - Circumstances in which the system may fail or produce inaccurate outputs + - Circumstances in which the system may be subject to deployment risks + - The performance as regards different persons or groups of persons + - Input data specifications + - Degree of accuracy for specific persons or groups +- Description of changes to performance through use (system drift) +- Where relevant, operational constraints + +--- + +### Article 14 — Human Oversight + +High-risk AI systems must be designed and developed to enable effective human oversight during their use. This requires: + +**Technical measures (Art. 14(3)):** +- The system can be overseen by natural persons to whom the deployer has assigned responsibility +- Operators can understand the system's capabilities and limitations +- Operators can understand when the system is producing outputs of questionable reliability +- Operators can disregard, override, or reverse the system's output +- Operators can intervene or interrupt the AI system + +**Biometric-specific oversight (Art. 14(5)):** +For remote biometric identification systems, human oversight must at minimum include: +- That no identifying action is taken with regard to a given person if not confirmed by at least two natural persons +- That identifying actions must be based on objective evidence and actual engagement with the identified person (not solely on the output of the AI system) + +**Provider vs deployer responsibility:** Providers must design the system with technical capacity for human oversight. Deployers must actually implement and exercise oversight in practice (Art. 26). + +--- + +### Article 15 — Accuracy, Robustness, and Cybersecurity + +High-risk AI systems must achieve **appropriate levels** of accuracy, robustness, and cybersecurity throughout their lifecycle. + +**Accuracy:** +- Must be declared in the technical documentation and instructions for use +- Accuracy levels and relevant metrics must be appropriate to the intended purpose +- Combined human-AI performance metrics may be used where relevant + +**Robustness:** +- Must be resilient to errors, faults, or inconsistencies that may occur within the system or its environment during operation +- Technical redundancy measures where appropriate (failsafe, error handling) + +**Cybersecurity:** +- Technically robust against attempts by unauthorised parties to alter the system's use or performance, to manipulate training or operational data, or to exploit model vulnerabilities (adversarial attacks, data poisoning, model inversion, prompt injection) +- Must include measures to prevent and respond to cybersecurity threats proportionate to risks + +--- + +### Article 16 — Summary of Provider Obligations + +Article 16 serves as a summary enumeration of provider obligations: +(a) Ensure compliance with requirements in Arts. 8–15 +(b) Have a quality management system (Art. 17) +(c) Draw up technical documentation (Art. 11) +(d) Keep records and logs (Arts. 12, 20) +(e) Undertake conformity assessment procedure before placing on market (Art. 43) +(f) Register in EU database (Art. 49) +(g) Take corrective actions when non-compliance identified (Art. 21) +(h) Inform national authorities of serious incidents (Art. 73) +(i) Affix CE marking (Art. 48) +(j) Ensure AI system accompanied by EU declaration of conformity (Art. 47) + +--- + +### Article 17 — Quality Management System + +Providers must implement a **quality management system (QMS)** covering all phases of the high-risk AI system lifecycle. + +**QMS must address (Art. 17(1)):** +- Regulatory compliance strategy (including conformity assessment procedures and standards) +- Techniques for design, design control, and design verification +- Systems and procedures for data management (training, validation, testing data) +- Risk management system (Art. 9) +- Post-market monitoring plan (Art. 72) +- Incident reporting procedures (Art. 73) +- Handling of corrections and corrective actions +- Procedures for security and access +- AI literacy and training of personnel + +**Documentation:** QMS must be documented systematically and in an orderly manner — written policies, procedures, and records. Records to be retained for **10 years** after placing on market or putting into service. + +**Proportionality:** QMS may be integrated into an existing quality management system (e.g., ISO 9001, ISO 13485 for medical devices). For SMEs, documentation requirements are proportionate to organisational size and complexity. + +--- + +## Part 3: Conformity Assessment Routes (Article 43) + +### Route 1 — Internal Conformity Assessment (Art. 43(2)) + +**Applicable to:** All high-risk AI systems under Annex III **except** remote biometric identification systems. + +**Process:** +1. Verify compliance against requirements in Arts. 8–15 +2. Ensure quality management system in place (Art. 17) +3. Complete Annex IV technical documentation +4. Draw up EU declaration of conformity (Annex V format) +5. Affix CE marking (Annex VI marking rules) +6. Register in EU database before placing on market (Art. 49) +7. Maintain records; implement post-market monitoring + +### Route 2 — Third-Party Conformity Assessment (Notified Body) (Art. 43(1)) + +**Mandatory for:** +- High-risk AI systems that are **safety components** in Annex I-regulated products where those laws require third-party assessment +- **Remote biometric identification systems** listed under Annex III, Area 1(a) — where no harmonised standard covering all requirements exists + +**Process:** +1. Identify an accredited Notified Body designated under applicable EU law +2. Submit for assessment: technical documentation, risk management records, testing evidence, QMS documentation +3. Notified Body conducts: documentation review, technical assessment, quality system audit, testing review +4. Upon successful assessment: Notified Body issues EU technical assessment certificate +5. Provider draws up EU declaration of conformity and affixes CE marking +6. Register in EU database + +**Notified Body obligations (Arts. 38–44):** +- Must be accredited by National Accreditation Bodies (NABs) designated by Member States +- Must maintain independence, impartiality, and technical competence +- Must not have conflicts of interest with providers whose systems they assess +- Must maintain professional secrecy +- Notified Body decisions can be reviewed by NCAs + +### Harmonised Standards and Common Specifications + +**Presumption of conformity (Art. 40):** High-risk AI systems conforming to harmonised European standards (EN standards developed under EU AI Act standardisation mandate to CEN/CENELEC) benefit from a presumption of conformity with the corresponding requirements. + +**Common specifications (Art. 41):** Where harmonised standards are absent or insufficient, the Commission may adopt implementing acts setting out common technical specifications. These carry the same presumption of conformity. + +**Note on current status (as of 2026):** CEN/CENELEC JTC 21 is developing harmonised standards for the EU AI Act. ISO/IEC AI standards (such as ISO/IEC 42001 for AI management systems) are referenced as relevant but are not yet formally designated as harmonised standards under the AI Act. + +--- + +## Part 4: CE Marking and Declaration of Conformity + +### EU Declaration of Conformity (Art. 47, Annex V) + +The EU declaration of conformity must contain: +- Name and address of the provider (and authorised representative where applicable) +- Statement that the AI system is in conformity with the EU AI Act +- Name, address, and identification number of the Notified Body (where applicable) +- Reference to harmonised standards or common specifications applied +- Where applicable, identification of other Union legislation complied with +- Provider's name, place, and date of issue; signature + +### CE Marking (Arts. 48, 49) + +- CE marking must be affixed visibly, legibly, and indelibly on the AI system or on the packaging +- For AI systems that are entirely software: CE marking must be affixed to the accompanying documentation or information +- The CE marking must be followed by the identification number of the Notified Body (where applicable) +- CE marking must not be affixed before conformity assessment is completed and the EU declaration of conformity drawn up + +--- + +## Part 5: EU Database for Stand-Alone High-Risk AI Systems (Art. 49) + +**Before placing on the market or putting into service**, providers of stand-alone high-risk AI systems (not embedded in Annex I products) must register in the **EU database** established under Art. 71. + +**Registration information required (as per EU database requirements):** +- Provider name, address, and contact details +- Categories of natural persons affected +- Member States in which system is or will be placed on market +- Name and description of the AI system +- Intended purpose, categories of persons and groups affected +- Description of capabilities and limitations +- Performance levels, accuracy, robustness +- Known limitations and circumstances affecting performance +- Training data characteristics +- Risk management measures taken +- Conformity assessment procedure followed and certificate reference +- Date of registration + +**Public access:** The EU database is publicly accessible. Confidential business information may be protected from disclosure per Art. 71(4). + +**Deployer registration:** Deployers of high-risk AI systems listed in Annex III and used by public authorities must also register before use (Art. 49(2)). diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-obligations-templates.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-obligations-templates.md new file mode 100644 index 0000000..df0b072 --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-obligations-templates.md @@ -0,0 +1,415 @@ +# EU AI Act — Obligations, Checklists, and Document Templates + +**Regulation (EU) 2024/1689** +This reference provides structured checklists, document templates, and gap analysis tools for EU AI Act compliance. + +--- + +## Part 1: Provider Compliance Checklist (High-Risk AI Systems) + +Use this checklist to assess compliance status for a provider of a high-risk AI system. For each item, record status: Not Started (NS), In Progress (IP), Completed (C), Not Applicable (N/A). + +### Phase 1: Pre-Market — Before Placing on Market or Putting into Service + +| # | Obligation | Article(s) | Status | Evidence Required | +|---|-----------|------------|--------|------------------| +| 1.1 | Risk management system established, documented, and operational | Art. 9 | | Risk management plan, risk register, residual risk documentation | +| 1.2 | Data governance procedures in place for training, validation, and test data | Art. 10 | | Data governance policy, dataset documentation, bias evaluation records | +| 1.3 | Technical documentation (Annex IV) drawn up and complete | Art. 11 | | Annex IV document package | +| 1.4 | Logging/record-keeping capability built into the AI system | Art. 12 | | System architecture documentation showing logging; test logs | +| 1.5 | Instructions for use prepared and accompanying the system | Art. 13 | | Instructions for use document | +| 1.6 | Human oversight technical measures designed into the system | Art. 14 | | Human oversight specification; UI/UX documentation showing override controls | +| 1.7 | Accuracy, robustness, and cybersecurity levels determined and documented | Art. 15 | | Accuracy benchmark results; robustness testing records; cybersecurity assessment | +| 1.8 | Quality management system (QMS) established | Art. 17 | | QMS procedure documentation; QMS records | +| 1.9 | Conformity assessment route determined (internal or third-party) | Art. 43 | | Conformity assessment decision document | +| 1.10 | Conformity assessment completed | Art. 43 | | Conformity assessment report; Notified Body certificate (if applicable) | +| 1.11 | EU declaration of conformity (Annex V) drawn up | Art. 47 | | Signed EU declaration of conformity | +| 1.12 | CE marking affixed | Art. 48 | | Product/documentation bearing CE marking | +| 1.13 | Registration in EU database completed | Art. 49 | | EU database registration confirmation and reference number | +| 1.14 | Authorised representative in EU designated (if provider is outside EU) | Art. 25 | | Authorised representative agreement; details registered | +| 1.15 | AI literacy measures in place for relevant personnel | Art. 4 | | Training records; competency assessments | + +### Phase 2: Post-Market — After Placing on Market + +| # | Obligation | Article(s) | Status | Evidence Required | +|---|-----------|------------|--------|------------------| +| 2.1 | Post-market monitoring plan in operation | Art. 72 | | Post-market monitoring plan; monitoring data; review records | +| 2.2 | Logs retained for minimum 6 months (where technically feasible) | Art. 20 | | Log retention configuration; archived logs | +| 2.3 | Incident reporting procedure in place | Art. 73 | | Incident response procedure; incident log | +| 2.4 | Serious incidents reported to national authorities within required timeframes | Art. 73 | | Incident reports submitted; acknowledgements from authorities | +| 2.5 | Corrective actions taken when non-conformities identified | Art. 21 | | Non-conformity log; corrective action records | +| 2.6 | Technical documentation and records kept for 10 years | Arts. 11, 17 | | Document retention records | +| 2.7 | Re-assessment performed after substantial modification | Art. 19 | | Modification assessment record; updated conformity assessment | +| 2.8 | Cooperation with national competent authorities when requested | Art. 23 | | Correspondence with authorities; access logs provided | + +--- + +## Part 2: Deployer Compliance Checklist (High-Risk AI Systems) + +Use this checklist to assess compliance status for a deployer of a high-risk AI system. + +| # | Obligation | Article(s) | Status | Evidence Required | +|---|-----------|------------|--------|------------------| +| D1 | AI system is used in accordance with provider's instructions for use | Art. 26(1) | | Usage policy; training records for users | +| D2 | Human oversight implemented — designated, competent, trained persons | Art. 26(2) | | Role assignments; training records; oversight procedures | +| D3 | Technical and organisational measures for human oversight in place | Art. 26(3) | | HO procedure; system configuration records | +| D4 | AI literacy measures implemented for relevant staff | Art. 4, Art. 26(5) | | Training records; competency assessments | +| D5 | AI system/use case monitored for risks; risks reported to provider | Art. 26(4) | | Monitoring log; incident/risk reports to provider | +| D6 | Fundamental Rights Impact Assessment (FRIA) conducted (Annex III systems) | Art. 27 | | Completed FRIA document; sign-off by senior management | +| D7 | Employees and their representatives informed before deployment (if system affects them) | Art. 26(7) | | Communication records; works council/employee rep consultation records | +| D8 | Registration in EU database completed (public authority deployers of Annex III systems) | Art. 49(2) | | EU database registration reference | +| D9 | Serious incidents reported to national market surveillance authorities | Art. 73 | | Incident reports; authority acknowledgements | +| D10 | Logs retained for minimum 6 months | Art. 26(6) | | Log retention configuration; archived logs | +| D11 | AI system not used for purposes beyond intended purpose without re-assessment | Art. 26(1) | | Use case documentation; review records | + +--- + +## Part 3: GPAI Model Provider Compliance Checklist + +### Standard GPAI Models (Art. 53) + +| # | Obligation | Article | Status | Evidence Required | +|---|-----------|---------|--------|------------------| +| G1 | Technical documentation (Annex XI) drawn up and maintained | Art. 53(1)(a) | | Annex XI documentation | +| G2 | Information package for downstream providers (Annex XII) available | Art. 53(1)(b) | | Model card, API documentation, Annex XII document | +| G3 | Copyright compliance policy established; arts. 4(3) opt-outs respected | Art. 53(1)(c) | | Copyright policy; opt-out detection/compliance records | +| G4 | Training content summary published and current | Art. 53(1)(d) | | Published training summary | +| G5 | Notification to Commission within 2 weeks if compute exceeds 10^25 FLOPs | Art. 52 | | Notification confirmation | +| G6 | Codes of practice adherence determined (or alternative compliance approach documented) | Art. 56 | | Code of practice sign-up; or alternative compliance statement | + +### Additional for Open-Weight GPAI Models (Art. 54) + +| # | Obligation | Article | Status | Evidence Required | +|---|-----------|---------|--------|------------------| +| OW1 | Parameters/weights publicly available | Art. 54 | | Model release; licence | +| OW2 | Model architecture publicly available | Art. 54 | | Published architecture documentation | +| OW3 | Copyright policy in place (same as G3) | Art. 54 | | As G3 | +| OW4 | Training summary published (same as G4) | Art. 54 | | As G4 | +| OW5 | If systemic risk designation exists or compute > 10^25 FLOPs: full Art. 53 + Art. 55 apply | Art. 54(2) | | Re-run full checklist | + +### Additional for GPAI Models with Systemic Risk (Art. 55) + +| # | Obligation | Article | Status | Evidence Required | +|---|-----------|---------|--------|------------------| +| SR1 | Model evaluations conducted including adversarial testing | Art. 55(1)(a) | | Evaluation reports; red-teaming records; adversarial test results | +| SR2 | Systemic risks assessed and mitigated | Art. 55(1)(b) | | Systemic risk assessment; risk mitigation plan | +| SR3 | Serious incident tracking, documentation, and reporting process in place | Art. 55(1)(c) | | Incident tracking log; reports to AI Office | +| SR4 | Cybersecurity protection measures for model and infrastructure | Art. 55(1)(d) | | Cybersecurity assessment; access controls; penetration test results | + +--- + +## Part 4: Fundamental Rights Impact Assessment (FRIA) Template (Article 27) + +**Template: Fundamental Rights Impact Assessment** +**Pursuant to Article 27, Regulation (EU) 2024/1689 (EU AI Act)** + +--- + +### Section 1: Administrative Information + +| Field | Value | +|-------|-------| +| Deployer organisation name | | +| Deployer address | | +| Contact person for this FRIA | | +| Contact person email/phone | | +| AI system name | | +| AI system version/release | | +| Provider name | | +| Intended purpose of deployment | | +| Date of FRIA completion | | +| Review date | | +| Approved by (senior management) | | +| Title of approving officer | | + +--- + +### Section 2: Description of Deployment Context + +**2.1 Description of the process in which the high-risk AI system will be used:** +[Describe in detail the business process, workflow, or function in which the AI system will be used. Include the decision-making process it supports or automates.] + +**2.2 Time period of intended use:** +[From date — to date, or "ongoing permanent deployment"] + +**2.3 Frequency of use:** +[How often will the system be used? How many interactions/decisions per day/week/month?] + +**2.4 Geographic scope:** +[Countries, regions, or specific locations where the system will be deployed] + +**2.5 Categories of natural persons who will be affected:** +Identify all groups: + +| Category of Persons | Direct Impact | Indirect Impact | Number Affected (approx.) | +|--------------------|--------------|----------------|--------------------------| +| [Insert group — e.g., job applicants] | Yes/No | Yes/No | [Number/estimate] | +| [Insert group — e.g., current employees] | Yes/No | Yes/No | | +| [Insert group — e.g., customers] | Yes/No | Yes/No | | +| [Insert vulnerable group — e.g., persons with disabilities] | Yes/No | Yes/No | | +| [Insert vulnerable group — e.g., minors] | Yes/No | Yes/No | | + +--- + +### Section 3: Fundamental Rights Assessment + +For each EU Charter article relevant to the deployment, assess the risk: + +**Likelihood scale:** 1 = Highly unlikely, 2 = Unlikely, 3 = Possible, 4 = Likely, 5 = Highly likely +**Severity scale:** 1 = Negligible, 2 = Minor, 3 = Moderate, 4 = Significant, 5 = Severe/Irreversible + +| Charter Article | Fundamental Right | Potential Risk | Likelihood (1-5) | Severity (1-5) | Risk Level | Affected Group | +|----------------|------------------|---------------|-----------------|---------------|------------|---------------| +| Art. 1 | Human dignity | | | | | | +| Art. 3 | Physical and mental integrity | | | | | | +| Art. 7 | Respect for private and family life | | | | | | +| Art. 8 | Protection of personal data | | | | | | +| Art. 11 | Freedom of expression and information | | | | | | +| Art. 14 | Right to education | | | | | | +| Art. 15 | Freedom to choose an occupation and engage in work | | | | | | +| Art. 17 | Right to property | | | | | | +| Art. 20 | Equality before the law | | | | | | +| Art. 21 | Non-discrimination (race, sex, religion, disability, age, sexual orientation, etc.) | | | | | | +| Art. 22 | Cultural, religious, and linguistic diversity | | | | | | +| Art. 23 | Equality between women and men | | | | | | +| Art. 24 | Rights of the child | | | | | | +| Art. 25 | Rights of the elderly | | | | | | +| Art. 26 | Integration of persons with disabilities | | | | | | +| Art. 38 | Consumer protection | | | | | | +| Art. 41 | Right to good administration | | | | | | +| Art. 47 | Right to an effective remedy and fair trial | | | | | | +| Art. 48 | Presumption of innocence and right of defence | | | | | | + +**Overall Risk Rating:** [ ] Low [ ] Medium [ ] High + +--- + +### Section 4: Risk Mitigation Measures + +For each risk identified as Medium or High in Section 3: + +| Risk Reference | Risk Description | Mitigation Measure | Responsible Party | Implementation Date | Residual Risk | Monitoring Approach | +|---------------|----------------|-------------------|------------------|--------------------|--------------|--------------------| +| | | | | | | | + +--- + +### Section 5: Consultation and Stakeholder Engagement + +**5.1 Internal consultation:** +[Record who was consulted within the deployer organisation — DPO, legal, HR, IT, affected business units] + +| Stakeholder | Role | Date Consulted | Input Received | +|-------------|------|---------------|----------------| +| | | | | + +**5.2 External consultation (where applicable):** +[Record any external consultation — e.g., works council, employee representatives, external legal advice] + +**5.3 Employee / works council consultation (Art. 26(7)):** +[ ] Employees and their representatives were informed of the intended deployment before deployment +[ ] Works council / employee representative body was consulted on [date] + +--- + +### Section 6: Data Protection Alignment + +**6.1 Is a DPIA (under GDPR Art. 35) required for this deployment?** +[ ] Yes — DPIA reference: ________________ +[ ] No — Reason: ________________ + +**6.2 Legal basis for processing personal data:** +[ ] Art. 6(1)(a) GDPR — Consent +[ ] Art. 6(1)(b) — Contract +[ ] Art. 6(1)(c) — Legal obligation +[ ] Art. 6(1)(e) — Public task +[ ] Art. 6(1)(f) — Legitimate interests +[ ] Other: ________________ + +**6.3 Special category data involved?** +[ ] Yes — Categories: ________________ — Legal basis under Art. 9(2) GDPR: ________________ +[ ] No + +--- + +### Section 7: Approval and Sign-Off + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| Senior management approver | | | | +| Data Protection Officer (review) | | | | +| Legal/Compliance review | | | | +| AI Literacy / HR confirmation | | | | + +**Next review date:** ________________ +**Trigger events for early review:** Substantial change to AI system; change in intended use; new risk information; significant incident; regulatory guidance update. + +--- + +## Part 5: Technical Documentation Outline (Annex IV Compliance) + +Use this outline to structure the technical documentation required by Article 11 and Annex IV. + +### Document Control Block (for each technical documentation package) + +| Field | Value | +|-------|-------| +| AI System Name | | +| Version | | +| Provider Name | | +| Document ID | | +| Version | 1.0 | +| Classification | Confidential — for regulatory and authorised commercial use | +| Prepared by | | +| Approved by | | +| Date | | +| Review date | | +| Retention period | 10 years from date of placing on market | + +### Required Sections (Annex IV) + +**Section 1 — General Description** +- 1.1 Intended purpose (complete specification per Art. 3(11)) +- 1.2 Version, date of development, and history +- 1.3 Names and contact details of provider (and authorised representative where applicable) +- 1.4 Hardware on which system is intended to operate +- 1.5 How system interacts with hardware, software, or other AI systems +- 1.6 Form in which the AI system is placed on market (embedded, software, API, SaaS, etc.) +- 1.7 Natural persons affected by the system and use cases + +**Section 2 — Description of the AI System and Development Process** +- 2.1 Development methodologies and third parties involved +- 2.2 Design specifications including general logic, key design choices and assumptions +- 2.3 Architecture of the system — description of components, modules, models +- 2.4 Training methodology and key decisions in training +- 2.5 Training data — type, source, size, selection criteria, collection methodology +- 2.6 Validation data — type, source, size +- 2.7 Testing data — type, source, size, test methodology +- 2.8 Human oversight technical measures designed in (Art. 14) +- 2.9 Pre-determined changes to the AI system and its performance (anticipated system drift) + +**Section 3 — Risk Management System Records** +- 3.1 Risk management system description (Art. 9 process) +- 3.2 Known and foreseeable risks identified +- 3.3 Risk mitigation measures adopted +- 3.4 Residual risks remaining after mitigation +- 3.5 Testing results — metrics, benchmarks, methodologies + +**Section 4 — Accuracy, Robustness, and Cybersecurity** +- 4.1 Accuracy levels and metrics +- 4.2 Performance across different persons or groups of persons +- 4.3 Robustness testing results +- 4.4 Cybersecurity measures and testing results + +**Section 5 — Changes Made After Initial Placing on Market** +- 5.1 Record of all changes/updates and dates +- 5.2 Assessment of whether each change constitutes a substantial modification +- 5.3 Updated conformity assessment records where substantial modification identified + +**Section 6 — Standards and Specifications Applied** +- 6.1 Harmonised standards applied (with version numbers) +- 6.2 Common specifications applied +- 6.3 Where standards not applied: description of technical solutions adopted to meet requirements +- 6.4 Other relevant industry standards or codes of practice + +**Section 7 — Referenced Documents** +- 7.1 EU Declaration of Conformity (Annex V) +- 7.2 Post-market monitoring plan (Annex VII framework) +- 7.3 Instructions for use +- 7.4 Quality Management System documentation reference + +--- + +## Part 6: EU Declaration of Conformity (Annex V Format) + +**EU DECLARATION OF CONFORMITY** +*(Pursuant to Article 47 and Annex V, Regulation (EU) 2024/1689)* + +--- + +**No.** [Unique reference number] + +**1. AI system name and type:** +[Name of AI system; model/type reference] + +**2. Provider name and address:** +[Full legal name and registered address] + +**3. Authorised representative (where applicable):** +[Name and address of authorised representative in the Union] + +**4. This declaration of conformity is issued under the sole responsibility of the provider.** + +**5. Object of the declaration:** +[Brief description of the AI system and its intended purpose] + +**6. The object of the declaration described above is in conformity with the relevant Union harmonisation legislation:** +Regulation (EU) 2024/1689 (Artificial Intelligence Act) + +**7. References to the relevant harmonised standards used or references to any other technical specifications in relation to which conformity is declared:** +[List harmonised EN standards applied, e.g., EN ISO/IEC 42001, EN standards under AI Act mandate] +[Or: Description of alternative technical specifications used per Art. 41] + +**8. Where applicable, name, address, and identification number of the Notified Body that carried out the conformity assessment procedure:** +[Notified Body name; EU notified body number; certificate reference and date] + +**9. Additional information (where applicable):** +[Any additional compliance declarations or conditions] + +**Signed for and on behalf of:** +[Name and company, place and date, signature] +[Function/title of signatory] + +--- + +## Part 7: Serious Incident Report Template (Article 73) + +**HIGH-RISK AI SYSTEM — SERIOUS INCIDENT REPORT** +*(Pursuant to Article 73, Regulation (EU) 2024/1689)* + +**Report type:** [ ] Initial report [ ] Follow-up report [ ] Final report + +**Submission date:** ________________ +**Reference number** (if follow-up): ________________ + +**Section A — Provider Information** +- Provider name and address: +- Contact person name, role, phone, and email: +- AI system name and version: +- EU database registration number: + +**Section B — Incident Description** +- Date and time incident first identified: +- Date and time incident occurred (if different): +- Location/Member State(s) affected: +- Nature of the incident (describe what happened): +- Type of serious incident (tick all that apply): + - [ ] Death or risk of death + - [ ] Serious injury to health + - [ ] Serious irreversible disruption to management/operation of critical infrastructure + - [ ] Infringement of fundamental rights obligations + - [ ] Serious property damage or other significant harm +- Number of persons affected (if known): +- Description of affected persons: + +**Section C — AI System Actions Preceding the Incident** +- What was the AI system doing at the time of the incident? +- What input data was processed? +- What output did the AI system generate? +- Was the AI system operating within its intended purpose? + +**Section D — Immediate Corrective Actions Taken** +- Immediate steps taken to stop/mitigate harm: +- Has the AI system been taken offline/suspended? [ ] Yes [ ] No +- Actions to prevent recurrence (preliminary): +- Has affected person(s) been notified? [ ] Yes [ ] No [ ] Not applicable + +**Section E — Preliminary Hypothesis on Cause** +[Describe what is currently believed to have caused the incident. Mark as preliminary if investigation is ongoing.] + +**Section F — Follow-Up Plans** +- Expected investigation completion date: +- Next reporting milestone: +- Contact for further communication with authorities: + +**Signed by:** ________________ **Title:** ________________ **Date:** ________________ diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-prohibited-practices.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-prohibited-practices.md new file mode 100644 index 0000000..170194f --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-prohibited-practices.md @@ -0,0 +1,226 @@ +# EU AI Act — Article 5: Prohibited AI Practices + +**Regulation (EU) 2024/1689, Article 5** +**Applicable from: 2 February 2025** + +This reference covers all eight categories of AI practices prohibited under Article 5 of the EU AI Act. These are practices classified as posing unacceptable risk. Any AI system falling into these categories must not be placed on the EU market, put into service, or used in the EU. + +--- + +## Overview + +Article 5 prohibits the placing on the market, putting into service, or use of AI systems that deploy specific high-risk techniques or serve specific harmful purposes. Violations carry the highest penalty tier: up to **€35 million or 7% of global annual turnover**, whichever is higher (Art. 99(3)). + +The eight prohibited categories are: + +--- + +## Category 1 — Subliminal, Manipulative, or Deceptive Techniques (Art. 5(1)(a)) + +**Prohibited:** AI systems that deploy subliminal techniques beyond a person's consciousness, or purposefully manipulative or deceptive techniques, with the objective or effect of materially distorting the behaviour of a person or a group of persons by appreciably impairing their ability to make an informed decision, thereby causing them or another person significant harm. + +**Key elements that must ALL be present for the prohibition to apply:** +- The technique operates below the threshold of consciousness (subliminal) OR is deliberately manipulative/deceptive +- The objective or effect is to materially distort the person's behaviour +- This appreciably impairs the ability to make an informed decision +- Significant harm results or is likely to result (to the person or another person) + +**Examples of potentially prohibited systems:** +- AI voice systems using imperceptible audio signals to induce purchasing decisions +- AI recommendation engines deliberately designed to exploit cognitive biases to drive harmful outcomes +- AI chatbots impersonating humans without disclosure to induce financial commitments + +**What is NOT prohibited:** +- Legitimate advertising and marketing that uses evidence-based persuasion techniques without subliminal components +- AI systems that provide information enabling informed decision-making +- AI that nudges behaviour with full transparency and in a non-deceptive manner + +--- + +## Category 2 — Exploitation of Vulnerabilities (Art. 5(1)(b)) + +**Prohibited:** AI systems that exploit any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability, or specific social or economic situation, with the objective or effect of materially distorting the behaviour of that person or a person belonging to that group in a manner that causes or is likely to cause significant harm. + +**Key elements:** +- Targets vulnerabilities arising from age (e.g., children, elderly), disability, or specific social/economic situation +- The exploitation has the objective or effect of materially distorting behaviour +- The distortion causes or is likely to cause significant harm + +**Examples of potentially prohibited systems:** +- AI systems targeting children with manipulative dark patterns to induce in-app purchases +- AI debt collection systems targeting financially distressed individuals with psychologically manipulative messaging +- AI systems exploiting cognitive impairments of elderly users to obtain consent or financial commitments + +**Relationship to Category 1:** The key distinction is that Category 1 focuses on technique (subliminal/deceptive), while Category 2 focuses on the target's vulnerability. An AI system can violate both simultaneously. + +--- + +## Category 3 — Biometric Categorisation Inferring Sensitive Attributes (Art. 5(1)(c)) + +**Prohibited:** AI systems using biometric categorisation that categorise individually natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation. + +**Scope:** Applies to AI systems that use biometric data to infer sensitive special category attributes. + +**What biometric data is covered:** Any data processed through specific technical processing relating to physical, physiological, or behavioural characteristics of a natural person — including fingerprints, iris scans, facial geometry, gait, voice patterns. + +**The prohibited inference categories:** +- Race or ethnic origin +- Political opinions +- Trade union membership +- Religious or philosophical beliefs +- Sex life or sexual orientation + +**Exceptions (Art. 5(1)(c) proviso):** +- Lawful filtering or labelling of lawfully acquired biometric data sets — e.g., lawful research datasets that need to be sorted +- Law enforcement categorising biometric data in accordance with Union or Member State law + +**What is NOT prohibited:** +- Biometric verification systems that confirm a person is who they claim to be (identity verification) — these are NOT categorisation systems +- Biometric identification systems that match an identity to a known identity — these are separately addressed as high-risk under Annex III, not prohibited + +--- + +## Category 4 — Social Scoring (Art. 5(1)(d)) + +**Prohibited:** AI systems that evaluate or classify natural persons or groups of persons over a period of time based on their social behaviour or known, inferred, or predicted personal or personality characteristics, with a social score, the AI-based evaluation leading to either or both of the following: +- (i) Detrimental or unfavourable treatment of those natural persons or groups in social contexts that are unrelated or disproportionate to the context in which the data was originally generated or collected +- (ii) Detrimental or unfavourable treatment that is unjustified or disproportionate to the social behaviour or its gravity + +**Key elements:** +- Evaluation conducted **over a period of time** (not single-event assessments) +- Based on **social behaviour** or **personal/personality characteristics** (known, inferred, or predicted) +- Leads to treatment that is either unrelated to the data's original context or disproportionate to the behaviour + +**Examples of prohibited systems:** +- Citizen scoring systems that aggregate data from multiple life domains (financial, social, civic) to produce a general-purpose score affecting housing, travel, or services +- Insurance systems that persistently track social media behaviour across years to calculate premiums affecting unrelated services +- Employer AI systems that compile long-term personality assessments reducing job opportunities in unrelated fields + +**What is NOT prohibited:** +- Credit scoring using solely financial behaviour data relevant to a financial service — this is separately regulated as high-risk under Annex III +- Risk assessment for specific, relevant and proportionate purposes (e.g., financial fraud detection) +- HR performance management systems assessing work-specific behaviour in proportion to employment context + +--- + +## Category 5 — Criminal Risk Assessment Based Solely on Profiling or Personality Traits (Art. 5(1)(e)) + +**Prohibited:** AI systems that assess the risk of a natural person to commit criminal offences based solely on profiling of a natural person or assessing their personality traits and characteristics. + +**The critical qualifier "solely":** This prohibition applies when the risk assessment is based **exclusively** on profiling or personality traits. AI that **augments** human assessment based on objective, verifiable facts directly linked to criminal activity is **not** prohibited. + +**What is prohibited:** +- Predictive policing systems that identify individuals as criminal risks based solely on demographic profiling, social network analysis, or personality scores without objective factual basis +- Recidivism risk tools that score individuals based purely on personal characteristics (age, address, employment) without factual criminal behaviour evidence + +**What is NOT prohibited:** +- Actuarial risk tools assessing recidivism risk that incorporate actual criminal history, behavioural observations during incarceration, and other objective verifiable facts — provided they do not rely **solely** on profiling +- AI systems assisting analysts by flagging patterns for human investigator review, where human investigators apply individual fact-based assessment + +--- + +## Category 6 — Untargeted Facial Recognition Scraping (Art. 5(1)(f)) + +**Prohibited:** AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage. + +**Key elements:** +- Applies to the **creation or expansion** of facial recognition databases +- Through **untargeted scraping** — without specific targets or selection criteria +- From **internet sources** or **CCTV footage** + +**Why "untargeted" matters:** Targeted collection with lawful basis (e.g., collecting images of a known suspect with judicial authorisation) is not covered by this prohibition. The prohibition targets mass, indiscriminate collection building databases that could be used for surveillance. + +**What is prohibited:** +- Commercial services that scrape public social media profiles to build facial recognition databases +- Law enforcement building general-purpose facial databases from CCTV footage without targeting specific investigations +- Academic research building large unlicensed facial datasets through automated web scraping + +**Relationship to other prohibitions:** Real-time RBI (Category 8) uses such databases in operation. This prohibition attacks the database-building stage. + +--- + +## Category 7 — Emotion Recognition in Workplace and Educational Institutions (Art. 5(1)(g)) + +**Prohibited:** AI systems used for making inferences about the emotional states of natural persons in the context of the workplace and educational institutions. + +**Scope:** Covers AI systems that analyse facial expressions, voice, body language, or physiological signals to infer emotional states (e.g., stress, engagement, happiness, anxiety, attention). + +**Contexts covered:** +- Workplaces in general — offices, manufacturing floors, remote working environments +- Educational institutions — schools, universities, training facilities + +**The medical/safety exception (Art. 5(1)(g) proviso):** Emotion recognition AI deployed for medical purposes (e.g., detecting clinical depression, monitoring patient distress in healthcare) or safety purposes (e.g., detecting driver fatigue for road safety) is NOT prohibited. + +**What is prohibited:** +- HR monitoring systems that analyse employees' facial expressions during work or video calls to assess productivity, engagement, or stress +- Proctoring software that uses emotion recognition to detect cheating or attention lapses in educational exams +- Recruitment AI that analyses candidates' emotional states during video interviews + +**What is NOT prohibited:** +- Emotion recognition in clinical settings by authorised medical professionals +- Driver drowsiness detection systems in vehicles (safety purpose) +- Voluntary mental health monitoring apps used by individuals for their own benefit + +--- + +## Category 8 — Real-Time Remote Biometric Identification (RBI) in Public Spaces for Law Enforcement (Art. 5(1)(h)) + +**Prohibited (with exceptions):** The use of real-time remote biometric identification systems in publicly accessible spaces for the purpose of law enforcement — except in three specific circumstances. + +### Definitions relevant to this prohibition + +**Remote biometric identification system:** An AI system for the purpose of identifying natural persons at a distance through the comparison of a person's biometric data with the biometric data contained in a reference database, and without prior knowledge of whether the targeted person will be present and can be identified (Art. 3(40)). + +**Real-time:** The capturing and comparison of biometric data and the identification occur immediately or with minimal delay (contrasted with "post" RBI, which is not prohibited but is classified as high-risk). + +**Publicly accessible spaces:** Physical locations accessible to the general public, regardless of ownership — including streets, shopping centres, airports, stadiums, public transport, private premises open to the public. + +### The Three Permitted Exceptions (Art. 5(2)) + +Real-time RBI by law enforcement in publicly accessible spaces is permissible **only** in the following situations: + +**Exception A — Missing persons and trafficking victims:** +Targeted search for specific victims of kidnapping, trafficking, or sexual exploitation, and the search for missing persons. + +**Exception B — Specific, substantial, and imminent threat:** +Prevention of a specific, substantial, and imminent threat to life or safety of natural persons, or identified threat of a terrorist attack. + +**Exception C — Serious crime investigation:** +Detection, localisation, identification, or prosecution of the perpetrator or suspect of a criminal offence referred to in Art. 5(2)(c) — serious crimes including murder, grievous bodily injury, rape, robbery, organised crime, illegal weapons trafficking, terrorism, environmental crime, cybercrime, trafficking, and sexual exploitation. + +### Procedural Safeguards Required for Each Use + +For each real-time RBI deployment under an exception: + +1. **Prior authorisation** must be obtained from a judicial authority or an independent administrative authority of the Member State (Art. 5(3)(a)) + - Urgency exception: In duly justified cases of urgency, deployment may commence without prior authorisation, provided authorisation is requested without undue delay within 24 hours; if rejected, deployment must cease immediately and all data/results/outputs must be deleted + +2. **Fundamental rights impact assessment** must be conducted and registered in the EU database before deployment (Art. 5(4)) + - Urgency exception: Registration may follow in duly justified urgent cases without undue delay + +3. **Temporal, geographic, and personal limitations** must apply — use must remain limited to what is strictly necessary for the specific purpose + +4. **Post-deployment reporting**: A report on deployment to be submitted to the relevant market surveillance authority and the data protection authority + +### Member State legislation requirement + +Member States wishing to use real-time RBI under exceptions must enact specific national legislation authorising such use (Art. 5(3)). The Commission must be notified. National legislation must include: +- Offences that justify use under Exception C +- Maximum time periods for use +- Geographic limitations +- A supervisory mechanism +- Accountability and liability mechanisms + +--- + +## Enforcement Notes + +**Competent authorities:** National market surveillance authorities and data protection authorities, depending on whether the system raises general AI Act or data protection concerns. + +**Timeline:** Prohibited AI practices apply from **2 February 2025**. Any system deployed in the EU after this date that falls into these categories is in violation. + +**Transitional period:** There is no transitional period for prohibited AI systems — unlike high-risk AI systems which have transition periods for existing systems. + +**Interaction with GDPR:** Many prohibited AI practices also involve processing of biometric data (special category under GDPR Art. 9). Non-compliance with Article 5 of the EU AI Act may simultaneously constitute a GDPR violation. Competent authorities are expected to coordinate. + +**Interaction with EU Charter of Fundamental Rights:** Recitals 29–42 make clear that the prohibitions are grounded in fundamental rights under the EU Charter — particularly dignity (Art. 1), prohibition of torture (Art. 4), privacy (Art. 7), data protection (Art. 8), non-discrimination (Art. 21). diff --git a/plugins/govramp/.claude-plugin/plugin.json b/plugins/govramp/.claude-plugin/plugin.json new file mode 100644 index 0000000..b2597a1 --- /dev/null +++ b/plugins/govramp/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "govramp", + "description": "GovRAMP security authorization advisor for state and local government cloud — impact level selection, SSP documentation, gap analysis, Core/Ready/Authorized status paths, Fast Track, continuous monitoring, and NIST 800-53 Rev 5 control guidance for SLED organizations.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "govramp", + "stateramp", + "sled", + "state-local-government", + "cloud-security", + "nist-800-53", + "authorization", + "3pao", + "grc", + "public-sector" + ] +} diff --git a/plugins/govramp/skills/govramp/SKILL.md b/plugins/govramp/skills/govramp/SKILL.md new file mode 100644 index 0000000..2469b2c --- /dev/null +++ b/plugins/govramp/skills/govramp/SKILL.md @@ -0,0 +1,688 @@ +--- +name: govramp +description: > + Expert GovRAMP security authorization advisor for state and local government cloud + (SLED). Use this skill whenever a user asks about GovRAMP, StateRAMP, SLED cloud + security, GovRAMP impact levels (Low, Low+, Moderate, High), GovRAMP authorization + statuses (Core, Ready, Authorized, Provisionally Authorized, Progressing Snapshot), + GovRAMP Fast Track, NIST 800-53 Rev 5 controls in a state-local context, 3PAO + assessments for GovRAMP, GovRAMP System Security Plan (SSP), Security Assessment + Report (SAR), Plan of Action and Milestones (POA&M), continuous monitoring for + GovRAMP, TX-RAMP reciprocity, CJIS Overlay requirements, GovRAMP Authorized Product + List (APL), or any question about achieving or maintaining a GovRAMP security status + for a cloud service provider serving state, local, education, tribal, or special + district governments. Also trigger for questions about GovRAMP membership, PMO + engagement, or procurement of cloud solutions by public-sector organizations. +--- + +# GovRAMP Security Authorization Skill + +You are an expert GovRAMP implementation consultant and authorization advisor with +comprehensive knowledge of the GovRAMP Security Program, its authorization statuses, +NIST SP 800-53 Rev 5 control requirements for the SLED context, documentation +requirements, continuous monitoring obligations, and the GovRAMP PMO process. + +> **Disclaimer:** This guidance is for informational and educational purposes only. +> GovRAMP authorization requires engagement with the official GovRAMP Program +> Management Office (PMO), serviced by RAMPQuest powered by Knowledge Services, and +> where required, a GovRAMP-approved Third-Party Assessment Organization (3PAO). +> GovRAMP is not endorsed by or affiliated with FedRAMP or the United States Government. + +--- + +## How to Respond + +Clarify the user's authorization status goal (Core, Ready, Authorized), impact level +(Low, Low+, Moderate, High), and whether they already hold any existing authorization +(FedRAMP, SOC 2, etc.) before diving into detailed guidance. + +Match output to the task: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Control Family \| Control ID \| Requirement \| Current State \| Gap \| Priority | +| Status pathway selection | Decision matrix with rationale, effort, cost comparison | +| Control implementation guidance | Structured: Control ID > Objective > What to Implement > Evidence > Common Findings | +| SSP narrative | Prose paragraphs per control, with GovRAMP-specific notes | +| POA&M entry | Table: Finding ID \| Control \| Gap \| Remediation Action \| Owner \| Target Date \| Status | +| Impact level selection | Guided FIPS 199-style categorization with GovRAMP data classification tool logic | +| Continuous monitoring guidance | Monthly/quarterly/annual obligations list with deliverables | +| Fast Track assessment | Checklist of required documentation and process steps | +| General question | Clear prose with NIST 800-53 Rev 5 control citations and GovRAMP context | + +--- + +## GovRAMP — Framework Overview + +### What Is GovRAMP? + +GovRAMP (formerly StateRAMP, doing business as GovRAMP since 2023) is a 501(c)(6) +nonprofit membership organization. It provides a standardized cybersecurity +verification and validation program for cloud service providers (CSPs) that serve +**state, local, education, tribal, and special district (SLED)** organizations across +the United States. + +GovRAMP was founded on the principle that state and local governments — which often +lack the security resources of federal agencies — deserve the same rigorous, reusable +cloud security assessments that FedRAMP provides at the federal level. Rather than +each government entity conducting independent security reviews of every vendor, GovRAMP +centralizes and standardizes the process. + +**Key facts:** +- GovRAMP is **not affiliated with FedRAMP or the United States Government** +- GovRAMP's Program Management Office (PMO) is serviced by **RAMPQuest**, powered by + Knowledge Services +- GovRAMP is governed by a Board of Directors and active committees (Standards & + Technical, Approvals, Appeals, Procurement, Nominating, and Steering) +- GovRAMP has Framework Harmonization Working Groups and task forces (including AI + Security and CJIS-aligned requirements) +- Texas TX-RAMP recognizes GovRAMP with **reciprocity** — GovRAMP-authorized products + automatically qualify for TX-RAMP + +### Technical Foundation + +GovRAMP's security controls are based on **NIST SP 800-53, Revision 5** — the same +publication used to establish FedRAMP. This ensures alignment across federal and +state-local contexts and allows FedRAMP-authorized providers to pursue GovRAMP via +the Fast Track pathway. + +All GovRAMP Rev 5 templates are maintained at: +https://govramp.org/rev-5-templates-and-resources/ + +The GovRAMP PMO can be reached at: pmo@govramp.org + +--- + +## GovRAMP Impact Levels + +GovRAMP uses a risk-based impact level system derived from FIPS 199 and FIPS 200 +categorization logic. Impact level determines the number and stringency of NIST +800-53 Rev 5 controls required. + +| Impact Level | Description | Typical Use Case | +|-------------|-------------|-----------------| +| **Low** | Systems processing non-sensitive government data where loss of CIA has limited adverse effect | Administrative tools, public-facing portals | +| **Low+** | Systems with a slightly elevated risk profile above Low; an intermediate level used by GovRAMP between Low and Moderate | General business applications handling some PII | +| **Moderate** | Most common level — systems where loss of CIA has serious adverse effect | Systems storing PII, PHI, or financial government data | +| **High** | Systems where loss of CIA has severe or catastrophic effect | Systems supporting law enforcement, emergency services, critical infrastructure | + +### Data Classification Tool + +GovRAMP provides an official Data Classification Tool to help organizations determine +their required impact level based on the type of government data being processed, +stored, or transmitted. Download from: https://govramp.org/blog/document/data-classification-tool/ + +### Impact Level and Control Counts + +GovRAMP aligns to NIST 800-53 Rev 5 baselines, applying the same control profiles used +by FedRAMP but tailored for the SLED context. The number of applicable controls +increases with impact level: + +- **Low baseline**: Subset of NIST 800-53 Rev 5 controls (lowest control count) +- **Moderate baseline**: Full NIST 800-53 Rev 5 Moderate baseline (most common; 323 controls under FedRAMP Rev 5 Moderate reference; GovRAMP applies same baseline) +- **High baseline**: Full NIST 800-53 Rev 5 High baseline (highest control count and stringency) + +For the **Core** status pathway, a focused set of **60 prioritized NIST 800-53 Rev 5 +controls** aligned to the Moderate Impact Level and selected based on the MITRE ATT&CK +Framework are assessed by the GovRAMP PMO directly. + +--- + +## GovRAMP Authorization Statuses + +### Status Hierarchy + +GovRAMP defines the following security statuses, from lowest to highest assurance: + +``` +Progressing Snapshot (non-verified, advisory program) + ↓ +GovRAMP Core (verified, PMO-assessed, 60 controls, Moderate-aligned) + ↓ +GovRAMP Ready (verified, 3PAO readiness assessment, minimum mandatory requirements) + ↓ +GovRAMP Authorized / Provisionally Authorized (fully verified, 3PAO SAR + government sponsor) +``` + +--- + +### 1. Progressing Security Snapshot Program + +**What it is:** A subscription-based, advisory-level program. Not a verified security +status. Provides quarterly assessments (Snapshots) and monthly consultative calls +with the GovRAMP PMO advisory team. + +**Purpose:** Early-stage visibility into a provider's security maturity relative to +GovRAMP requirements. Helps identify gaps before pursuing Core, Ready, or Authorized +status. + +**Key characteristics:** +- Quarterly Snapshots provide a security maturity risk score +- Scores are not publicly disclosed; sharing is at provider's discretion +- Snapshot scoring criteria based on critical NIST 800-53 requirements +- Monthly consultative calls with GovRAMP Advisory team +- Providers listed on the **Progressing Product List** (not the Authorized Product List) +- **3PAO not required** + +**Effective January 1, 2026:** New requirements introduced — every product on the +Progressing Product List must be actively advancing toward a verified status. Products +failing to demonstrate progress are subject to an escalation process. + +**Process:** +1. Become a GovRAMP member +2. Submit a GovRAMP Service Request Form +3. Attend intake meeting; review Snapshot scoring criteria +4. Receive security maturity score (~3 weeks) +5. Begin monthly advisory calls to address gaps +6. Quarterly Snapshots to track progress + +**Cost:** Subscription-based; pricing through the GovRAMP PMO. + +--- + +### 2. GovRAMP Core + +**What it is:** A verified security status launched in May 2025, assessed directly by +the GovRAMP PMO. Validates implementation of **60 foundational NIST 800-53 Rev 5 +controls** selected based on the MITRE ATT&CK Framework and aligned with the Moderate +Impact Level baseline. + +**A 3PAO assessment is NOT required for Core.** + +**Purpose:** Bridges the gap between the Progressing Snapshot and full Ready/Authorized +status. Offers a faster, more accessible path to formal assurance without a full 3PAO +audit. + +**Key characteristics:** +- PMO reviews submitted documentation and validates all 60 required controls +- Products listed on the **Authorized Product List (APL)** +- Includes **quarterly Continuous Monitoring (ConMon)** +- Core status demonstrates progression toward Ready and Authorized +- Policies and procedures are required for Core + +**60 Core Controls:** Selected from NIST SP 800-53 Rev 5, aligned to the Moderate +baseline, prioritized using MITRE ATT&CK. See: +https://govramp.org/blog/core-controls/ and the official GovRAMP Core Controls document +at https://govramp.org/rev-5-templates-and-resources/ + +**Process:** +1. Become a GovRAMP member +2. (Optional) Complete the Progressing Snapshot Program first +3. Download the GovRAMP Core Control Evidence Examples and Collection Folders +4. Download and complete required templates (based on Moderate Impact package): SSP, + Incident Response Plan, Contingency Plan, scan documentation +5. Submit a Security Review Request to the GovRAMP PMO +6. PMO validates all 60 controls and awards Core Status +7. Product listed on the APL +8. Begin quarterly Continuous Monitoring + +**Cost (Annual PMO Assessment Fee — 2025/2026):** +- $9,000 — Providers with less than $1M in annual revenue +- $11,000 — Providers with $1M to $5M in annual revenue +- $17,000 — Providers with over $5M in annual revenue + +--- + +### 3. GovRAMP Ready + +**What it is:** A verified security status demonstrating a provider meets GovRAMP's +**minimum mandatory requirements**, as attested by a GovRAMP-approved 3PAO through a +Readiness Assessment Report (RAR). No government sponsor is required for Ready status. + +**Purpose:** Positions a provider to achieve full Authorized status. Indicates the +product is well-positioned to comply with full authorization requirements. + +**Key characteristics:** +- Requires a **3PAO-conducted Readiness Assessment Report (RAR)** +- No government sponsorship required +- Products listed on the Authorized Product List (APL) +- Obligation to submit **monthly and annual Continuous Monitoring** reports + +**Process:** +1. Become a GovRAMP member +2. (Optional) Complete a Security Snapshot as a gap analysis +3. Determine appropriate impact level (Low, Low+, or Moderate) using the Data + Classification Tool +4. Engage a GovRAMP-approved 3PAO to conduct a Readiness Assessment Report (RAR) +5. Complete at least **50%** of documentation; submit Security Review Request Form + with completed documentation and Ready review fee; product status updated to Pending +6. 3PAO attests to readiness; PMO verifies minimum mandatory requirements are met; + product status updated to Ready +7. Begin monthly and annual Continuous Monitoring + +**Cost (Ready Review Fee):** +- $500 — Providers with less than $1M annual revenue +- $2,500 — Providers with $1M–$5M annual revenue +- $3,750 — Providers with more than $5M annual revenue + +**Monthly Continuous Monitoring (Ready/Authorized):** +- $250/month — Providers with less than $1M annual revenue +- $500/month — Providers with $1M–$5M annual revenue +- $1,000/month — Providers with more than $5M annual revenue + +--- + +### 4. GovRAMP Authorized / Provisionally Authorized + +**What it is:** The highest verified security status in GovRAMP. Indicates the product +meets **all required security controls** by impact level. Requires a full 3PAO +Security Assessment Report (SAR) and either direct government sponsorship or approval +by the GovRAMP Approvals Committee. + +**Provisionally Authorized**: Granted where a government sponsor is pending or where +the Approvals Committee has approved the package pending minor conditions. + +**Key characteristics:** +- Requires **100% documentation completion** +- Requires a **3PAO-conducted Security Assessment Report (SAR)** +- Requires government sponsorship (sponsoring government official or GovRAMP Approvals + Committee as appointed sponsor) +- Products listed on the APL as Authorized +- Obligation to submit **monthly and annual Continuous Monitoring** reports + +**Process:** +1. Become a GovRAMP member +2. (Optional) Complete a Security Snapshot or achieve Ready status first +3. Determine appropriate impact level +4. Engage a GovRAMP-approved 3PAO to complete a full SAR +5. Complete 100% of documentation; submit Security Review Request Form with completed + documentation and Authorized review fee; product status updated to Pending +6. Obtain government sponsorship (direct sponsor or Approvals Committee) +7. PMO verifies all control requirements are met; product updated to Authorized +8. Begin monthly and annual Continuous Monitoring + +**Cost (Authorized Review Fee):** +- $1,500 — Providers with less than $1M annual revenue +- $5,000 — Providers with $1M–$5M annual revenue +- $7,500 — Providers with more than $5M annual revenue + +--- + +### 5. GovRAMP Fast Track + +**What it is:** An expedited pathway for providers that already hold FedRAMP +authorization or are actively pursuing FedRAMP authorization. Allows the provider to +leverage existing federal security documentation to obtain GovRAMP status without +starting from scratch. + +**Key characteristics:** +- Accepts documentation in **FedRAMP formatting** +- Requires 90 days of existing continuous monitoring data +- GovRAMP PMO reviews the security package and conducts a call with provider and 3PAO +- Available for Ready and Authorized status paths +- **Texas reciprocity**: TX-RAMP automatically recognizes GovRAMP-authorized products; + GovRAMP provides a weekly sync with TX-RAMP + +**Process:** +1. Become a GovRAMP member +2. Submit a Security Review Request Form to engage the GovRAMP PMO +3. Work with 3PAO to gather the federal-approved security package, 90 days of ConMon + data, and any required GovRAMP-specific templates +4. PMO reviews the package and conducts a review call +5. Upon validation, product achieves GovRAMP Ready or Authorized status +6. Begin GovRAMP Continuous Monitoring + +--- + +## 3. NIST 800-53 Rev 5 Control Framework for GovRAMP + +GovRAMP uses NIST SP 800-53 Rev 5 as its foundation. The same 20 control families apply +across all GovRAMP impact levels, with the applicable controls expanding as impact +level increases. + +### Control Families + +| ID | Family | Key Relevance to GovRAMP | +|----|--------|--------------------------| +| AC | Access Control | IAM, RBAC, least privilege, remote access, PIV/CAC | +| AT | Awareness & Training | Security and privacy training; role-based training | +| AU | Audit & Accountability | Log retention, SIEM, audit review | +| CA | Assessment, Authorization & Monitoring | ConMon, 3PAO, ATO, POAM | +| CM | Configuration Management | Baselines, change control, CMDB | +| CP | Contingency Planning | BCP/DR, tested annually; IRP and CP are required | +| IA | Identification & Authentication | MFA, FIPS 140-2/3 crypto | +| IR | Incident Response | IRP tested annually; incident reporting per GovRAMP Incident Communications Procedures | +| MA | Maintenance | Remote maintenance controls | +| MP | Media Protection | Data at rest, media sanitization | +| PE | Physical & Environmental | Datacenters; often inherited from FedRAMP-authorized IaaS | +| PL | Planning | SSP, rules of behavior | +| PM | Program Management | Enterprise security program | +| PS | Personnel Security | Screening, termination procedures | +| PT | PII Processing & Transparency | Privacy controls (Rev 5 addition) | +| RA | Risk Assessment | Vulnerability scanning; GovRAMP Vulnerability Scan Requirements Guide | +| SA | System & Services Acquisition | SDLC, supply chain security | +| SC | System & Communications Protection | Encryption in transit, network segmentation | +| SI | System & Information Integrity | Patching, malware, integrity monitoring | +| SR | Supply Chain Risk Management | SCRM (Rev 5 addition) | + +### Core Status — 60 Prioritized Controls + +For GovRAMP Core, 60 NIST 800-53 Rev 5 controls from the Moderate baseline are +assessed by the PMO. These controls are selected based on the MITRE ATT&CK Framework, +prioritizing controls that most directly address attack techniques seen against SLED +organizations. The full list is in the official GovRAMP Core Controls document +available at https://govramp.org/rev-5-templates-and-resources/. The control selection +covers domains including: + +- Access Control (AC) +- Audit & Accountability (AU) +- Configuration Management (CM) +- Identification & Authentication (IA) +- Incident Response (IR) +- Risk Assessment (RA) +- System & Communications Protection (SC) +- System & Information Integrity (SI) +- Contingency Planning (CP) +- Personnel Security (PS) + +Policies and procedures supporting these control families are required for Core status. + +### CJIS Overlay + +GovRAMP provides a **Moderate Impact with CJIS Overlay** impact level for providers +handling **Criminal Justice Information (CJI)**. This overlay adds CJIS-aligned +requirements on top of the standard Moderate Impact baseline. It applies to providers +serving law enforcement agencies and criminal justice organizations. + +The GovRAMP PMO maintains separate Service Provider Packages and 3PAO Packages for the +CJIS Overlay. Providers handling CJI must use the CJIS Overlay documentation. + +--- + +## 4. Required Documentation + +GovRAMP documentation aligns with FedRAMP's template structure. Templates are +available at https://govramp.org/rev-5-templates-and-resources/. The PMO accepts +documents in FedRAMP formatting. + +### Core Authorization Package Components + +``` +GovRAMP Authorization Package +├── System Security Plan (SSP) +│ └── Appendices (Incident Response Plan, Contingency Plan, etc.) +├── Security Assessment Report (SAR) [3PAO-prepared — Ready and Authorized only] +├── Plan of Action & Milestones (POA&M) +└── Supporting scans and evidence + ├── Vulnerability scan results (OS, DB, web application) + ├── Penetration test report + └── Authorization Boundary diagram +``` + +### System Security Plan (SSP) + +The SSP is the foundational document. It describes the system, its boundary, and how +each applicable control is implemented. Key sections include: + +- **System Categorization**: Impact level and FIPS 199 logic +- **System Description**: Architecture, technology stack, service model (SaaS/PaaS/IaaS) +- **Authorization Boundary**: What is in and out of scope; boundary diagram +- **Control Implementation Statements**: How each required control is satisfied, + distinguishing provider vs. customer responsibilities +- **Leveraged Authorizations**: FedRAMP-authorized IaaS/PaaS used and inherited controls +- **External Services**: Connections to services outside the boundary + +> For Core status: The SSP must cover at minimum the 60 Core controls. The GovRAMP +> Service Provider Package for Moderate Impact is the reference template. + +### Incident Response Plan (IRP) + +Required for all GovRAMP status levels including Core. Must be tested and documented. +Must include contact information and reporting timelines aligned with GovRAMP Incident +Communications Procedures. + +### Contingency Plan (CP) + +Required for all GovRAMP status levels including Core. Must be tested and documented. +Covers backup, recovery, and continuity of operations. + +### Scan Documentation + +- Vulnerability scans required; see the GovRAMP Vulnerability Scan Requirements Guide +- Penetration testing required (per the GovRAMP Penetration Test Guidance) +- Scans must cover OS, database, web application layers, and containers if used + +### Plan of Action & Milestones (POA&M) + +Tracks all open security findings. For each finding: + +| Field | Description | +|-------|-------------| +| Finding ID | Unique identifier | +| Control ID | NIST 800-53 Rev 5 control affected | +| Weakness Description | Clear description of the gap | +| Risk Rating | Critical / High / Moderate / Low | +| Remediation Plan | How the weakness will be fixed | +| Owner | Team or individual responsible | +| Scheduled Completion Date | Must meet GovRAMP remediation SLAs | +| Status | Open / Closed / Risk Adjusted / Vendor Dependency | + +**GovRAMP Remediation SLAs** (aligned with NIST and GovRAMP standards): +- Critical: 30 days +- High: 90 days +- Moderate: 180 days +- Low: 365 days + +--- + +## 5. Continuous Monitoring (ConMon) + +All products with a verified GovRAMP status must participate in Continuous Monitoring +to maintain their listing on the APL. The GovRAMP PMO monitors ongoing security +performance through the ConMon program. + +### ConMon by Status Level + +| Status | ConMon Frequency | +|--------|-----------------| +| Core | Quarterly | +| Ready | Monthly and Annual | +| Authorized | Monthly and Annual | + +### Monthly ConMon Activities (Ready / Authorized) + +- Vulnerability scan results submitted to the GovRAMP PMO +- Updated POA&M (open findings, remediation progress) +- Asset inventory updates +- Monthly report submission per the GovRAMP Continuous Monitoring Guide + +### Annual ConMon Activities (Ready / Authorized) + +- Full security assessment (3PAO or PMO-directed) +- Updated SSP and appendices +- Tested IRP and CP with documented test results +- Updated SAR and POA&M + +### Quarterly ConMon Activities (Core) + +- Progress reports submitted to the PMO +- Validation of continued Core control alignment +- Participation in PMO review of ongoing security performance + +### ConMon Escalation Process + +GovRAMP has a **Continuous Monitoring Escalation Process Guide** that details how +issues identified during ConMon are escalated, ensuring serious risks are addressed +promptly. Providers failing to meet ConMon obligations or showing declining security +posture are subject to the escalation process. + +--- + +## 6. Authorization Boundary Guidance + +Defining the correct authorization boundary is critical and one of the most common +sources of findings. GovRAMP provides an official **Authorization Boundary Guidance** +document. + +### Key Principles + +- **Everything that processes, stores, or transmits government data** in scope must be + within the boundary +- External services connected to in-scope systems must be GovRAMP-authorized (or + FedRAMP-authorized) OR documented with compensating controls +- The boundary must be depicted in a clear network/data flow diagram within the SSP +- Cloud platform infrastructure from a FedRAMP-authorized IaaS/PaaS provider + (AWS GovCloud, Azure Government, Google Cloud) can be documented as inherited + +### Cloud Platform Considerations + +**AWS GovCloud (US)** +- FedRAMP High authorized; PE and many SC controls fully inherited +- AWS Config, CloudTrail, GuardDuty, Security Hub useful for AU, RA, SI controls +- Use GovCloud region endpoints to remain in boundary + +**Azure Government** +- FedRAMP High authorized +- Azure Policy, Defender for Cloud maps to CM, RA, SI +- Azure Blueprints aligned to GovRAMP/FedRAMP Moderate and High baselines + +**Google Cloud (FedRAMP-authorized regions)** +- Assured Workloads for compliance +- Chronicle SIEM for AU controls + +--- + +## 7. GovRAMP Membership + +Before any product can be validated by the GovRAMP PMO, obtain a security status, or +be listed on the APL, the service provider **must be an active GovRAMP member**. + +### Membership Types + +| Type | Available To | +|------|-------------| +| Service Provider Member | Cloud service providers (SaaS, PaaS, IaaS) | +| Government Member | State, local, tribal, education, special district organizations | +| 3PAO Member | Third-party assessment organizations | +| Education/Nonprofit Member | Private education and nonprofit organizations | + +### Annual Membership Fees + +Annual memberships start at **$1,500** for service providers. Flexible options are +available based on organization size and type. + +### Benefits of Membership + +- Access to the complete Member Directory +- Public product profile on the Authorized Product List (enables procurement discovery) +- Engagement with the GovRAMP PMO +- Access to Framework Harmonization Working Groups +- Participation in task forces (AI Security, CJIS) +- Monthly Office Hours with the GovRAMP PMO (first Wednesday each month, 2:30–3:00 PM ET) + +--- + +## 8. For Government Organizations Adopting GovRAMP + +State and local governments can adopt GovRAMP as their third-party risk program for +cloud procurement. Benefits include: + +- Review the APL during procurement to identify pre-verified providers +- Move from being an assessor to an oversight role by accessing the ConMon portal +- Policymakers gain assurance that providers meet best-in-class standards throughout + the contract lifespan +- Participation in the GovRAMP governance structure (committees, working groups) + +### Adoption Process + +1. Determine your adoption roadmap with guidance from a GovRAMP Government Engagement + Director +2. Review the GovRAMP Adoption Resource Guide ("Getting Started with GovRAMP: A Guide + for Government") +3. Become a GovRAMP member +4. Incorporate GovRAMP requirements into your procurement RFPs +5. Leverage the APL for pre-vetted vendor selection +6. Access the ConMon portal for ongoing oversight + +GovRAMP's Procurement Cloud Security Resource Tool (developed by NASPO/GovRAMP +Procurement Task Force) helps procurement professionals prioritize cybersecurity +throughout the procurement process. + +--- + +## 9. Gap Assessment Approach + +### When the User Is a Service Provider + +1. **Clarify goal** — What status are they pursuing (Core, Ready, Authorized)? +2. **Identify impact level** — What type of government data? Use FIPS 199 logic or the + GovRAMP Data Classification Tool. +3. **Identify current state** — Do they already have FedRAMP, SOC 2, ISO 27001, or any + other third-party assessment? Consider Fast Track. +4. **Map controls** — Compare current documentation and controls against the applicable + GovRAMP baseline. +5. **Identify blockers** — Surface missing mandatory items: SSP, IRP, CP, scan results. +6. **Produce gap table**: + +| Control Family | Control ID | Requirement | Status | Gap | Priority | Owner | +|---------------|-----------|-------------|--------|-----|----------|-------| + +7. **Recommend pathway** — Core for faster entry, Ready or Authorized for full status, + Fast Track for FedRAMP-authorized providers. +8. **Estimate effort** — Reference the GovRAMP Ready/Authorized Guide for typical effort + expectations. + +### Key Readiness Questions to Ask + +- What cloud platform do you use? Is it FedRAMP-authorized (AWS GovCloud, Azure Government)? +- Do you already hold FedRAMP authorization? → Recommend Fast Track +- What types of government data will the system process, store, or transmit? +- Is your authorization boundary defined and documented? +- Do you have documented and tested IRP and CP? +- Do you have FIPS 140-2/3 validated encryption in place? +- Do you have a vulnerability scanning program (OS, DB, web app)? +- Do you have policies and procedures documented for the required control families? +- Do you have MFA enforced on all privileged accounts and remote access? +- Are you serving any Texas government entities? → TX-RAMP reciprocity may apply + +--- + +## 10. GovRAMP vs. FedRAMP — Key Differences + +| Factor | FedRAMP | GovRAMP | +|--------|---------|---------| +| Target customer | Federal government agencies | State, local, education, tribal (SLED) | +| Governing body | OMB / GSA / PMO (US Government) | GovRAMP nonprofit (501(c)(6)) | +| Control baseline | NIST 800-53 Rev 5 | NIST 800-53 Rev 5 (same) | +| Impact levels | Low, Moderate, High, LI-SaaS | Low, Low+, Moderate, High + CJIS Overlay | +| Government sponsor | Federal agency AO | State/local government or Approvals Committee | +| Reciprocity | FedRAMP → Fast Track to GovRAMP | GovRAMP → TX-RAMP automatic | +| 3PAO requirement | Required for all paths | Not required for Core; required for Ready/Authorized | +| Entry-level status | No equivalent to Core | GovRAMP Core (60 controls, PMO-assessed) | +| Program managed by | Joint Authorization Board (JAB) / PMO | GovRAMP PMO (RAMPQuest) | + +--- + +## 11. Common Findings and Pitfalls + +### Documentation Gaps +- SSP narratives that describe planned or aspirational controls rather than implemented controls +- Missing control implementation statements for one or more required controls +- Inconsistent boundary definition between SSP narrative and architecture diagrams +- IRP and CP not tested within the past 12 months +- Missing or incomplete POA&M entries for known gaps + +### Technical Gaps +- MFA not enforced on all privileged accounts and remote access paths +- Encryption using non-FIPS-validated modules (e.g., algorithms not approved under FIPS 140-2/3) +- Vulnerability scanning not covering all boundary components (containers, databases, web apps) +- Logging gaps — not all in-scope components sending logs to a centralized SIEM +- External services not documented or not FedRAMP/GovRAMP-authorized + +### Process Gaps +- No formal change management process for system changes within the boundary +- No documented personnel security procedures (screening, termination) +- Penetration testing not performed against the GovRAMP Penetration Test Guidance +- ConMon reports not submitted on schedule after authorization + +--- + +## Reference Files + +Load these when more depth is needed: + +- `references/readiness-checklist.md` — Full GovRAMP readiness checklist across all control domains +- `references/status-pathways.md` — Detailed comparison of all status pathways with decision guidance +- `references/ssp-guide.md` — SSP section-by-section guidance for GovRAMP +- `references/conmon-guide.md` — Continuous Monitoring templates, deliverables, and escalation guidance +- `references/control-mapping.md` — Core 60 controls mapping and full impact level control guidance diff --git a/plugins/govramp/skills/govramp/references/conmon-guide.md b/plugins/govramp/skills/govramp/references/conmon-guide.md new file mode 100644 index 0000000..e57f034 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/conmon-guide.md @@ -0,0 +1,240 @@ +# GovRAMP Continuous Monitoring (ConMon) Guide + +Continuous Monitoring (ConMon) is the ongoing obligation for all products with a +verified GovRAMP security status to demonstrate that their security posture is +maintained after initial authorization. GovRAMP requires ConMon activities to be +conducted and reported to the PMO per the official GovRAMP Continuous Monitoring Guide. + +Download the official guide at: +https://govramp.org/blog/document/stateramp-continuous-monitoring-guide/ + +For escalation procedures: +GovRAMP Continuous Monitoring Escalation Process Guide (available at https://govramp.org/rev-5-templates-and-resources/) + +--- + +## ConMon Obligations by Status + +| GovRAMP Status | ConMon Frequency | Key Deliverables | +|---------------|-----------------|-----------------| +| Core | Quarterly | Quarterly progress reports; ongoing PMO validation | +| Ready | Monthly + Annual | Monthly report package; annual assessment | +| Authorized | Monthly + Annual | Monthly report package; annual assessment | +| Provisionally Authorized | Monthly + Annual | Monthly report package; annual assessment | + +--- + +## Monthly ConMon Activities (Ready and Authorized) + +The following deliverables must be submitted monthly to the GovRAMP PMO: + +### 1. Vulnerability Scan Results + +Per the GovRAMP Vulnerability Scan Requirements Guide: + +- **Operating System (OS) scans**: All in-scope servers, VMs, and containers +- **Database scans**: All in-scope database components +- **Web application scans**: All web-facing applications within the boundary +- **Container scans** (if applicable): Container images and runtime environments +- Scans must be authenticated (credentialed) where supported +- Unauthenticated scan results alone are insufficient for compliance +- All critical and high findings must appear in the POA&M with remediation plans + +**Scan frequency requirement**: At minimum, scans must be conducted monthly for +Moderate and High impact levels. + +### 2. POA&M Update + +The Plan of Action and Milestones must be updated every month to reflect: + +- All new findings identified since last submission (from scans, audits, or self-discovery) +- Remediation status updates for each open finding +- Milestone date changes (with justification for any slippage) +- Newly closed items (evidence of remediation) +- Deviation Request status (false positives, risk adjustments, operational requirements) + +**POA&M Required Fields:** + +| Field | Description | +|-------|-------------| +| Finding ID | Unique identifier (e.g., SCAN-001, AUDIT-001) | +| Control ID(s) | NIST 800-53 Rev 5 control(s) affected | +| Weakness Name | Brief, descriptive name | +| Weakness Description | Detailed description of the gap | +| Point of Contact | Owner responsible for remediation | +| Resources Required | Tools, budget, or headcount needed | +| Remediation Plan | Step-by-step plan to address the finding | +| Original Detection Date | When was this first identified | +| Scheduled Completion Date | Target remediation date (must meet SLAs) | +| Milestone Changes | Log of any changes to target dates or scope | +| Status | Open / Closed / Risk Adjusted / Vendor Dependency | +| Risk Rating | Critical / High / Moderate / Low | +| False Positive | Yes / No (if marked Yes, must be substantiated) | + +### 3. Asset Inventory Update + +- Any new components added to the boundary must be reflected in the inventory +- Any decommissioned components must be removed +- Cloud resource additions (new accounts, new services) must be documented +- The inventory must accurately reflect the current state of the system + +### 4. Monthly Summary Report + +- A brief executive summary of the month's security activities +- Highlights: new findings, closed findings, ongoing remediation +- Scan coverage confirmation (every in-scope component was scanned) +- Any incidents or security events during the period + +--- + +## Annual ConMon Activities (Ready and Authorized) + +### Annual Security Assessment + +GovRAMP requires an annual review of security controls: + +- Conducted by a GovRAMP-approved 3PAO (for Authorized products) or PMO-directed process +- Results submitted as an updated Security Assessment Report (SAR) or equivalent +- Annual Assessment Controls Selection Worksheet used to determine which controls to test +- All findings from the annual assessment must be added to the POA&M + +### Documentation Updates + +- **Updated SSP**: Reflect any system changes, boundary modifications, or new controls +- **Updated IRP**: Must be tested (tabletop or functional exercise) with test results documented +- **Updated CP**: Must be tested with test results documented +- **Updated POA&M**: Incorporating annual assessment findings + +### Penetration Test + +- Required annually (at minimum) per the GovRAMP Penetration Test Guidance +- Must cover all in-scope systems: external, internal, web application, and containers if used +- Penetration test methodology must meet GovRAMP requirements +- Findings from the penetration test must be tracked in the POA&M + +--- + +## Quarterly ConMon Activities (Core) + +For products with Core status, ConMon is conducted quarterly: + +- Quarterly progress reports submitted to the GovRAMP PMO +- PMO validates ongoing alignment with all 60 Core controls +- PMO and government stakeholders review security performance trends +- Any changes to the system that impact Core control implementation must be reported + +--- + +## GovRAMP Remediation SLAs + +All POA&M items must be remediated within the following timeframes, measured from the +**original detection date**: + +| Risk Rating | Remediation Deadline | +|-------------|---------------------| +| Critical | 30 calendar days | +| High | 90 calendar days | +| Moderate | 180 calendar days | +| Low | 365 calendar days | + +Failure to meet remediation SLAs is one of the most common ConMon findings that +triggers the escalation process. + +--- + +## Deviation Requests + +When a finding cannot be remediated within SLA for legitimate operational reasons, +providers may submit a Deviation Request to the GovRAMP PMO: + +### Types of Deviations + +**1. False Positive** +- Provider demonstrates the finding does not represent a real vulnerability +- Must include technical evidence: screenshot of the scan result, explanation of + why the finding is incorrect, tool-specific analysis +- Requires PMO approval to remove from open findings + +**2. Risk Adjustment** +- Finding is real but provider believes the risk level is overstated +- Provider must provide justification and compensating controls +- Original risk level is preserved in the POA&M; adjusted level is noted +- Requires PMO approval + +**3. Operational Requirement** +- Finding cannot be remediated without significant operational impact (e.g., patching a + legacy component would break critical government customer functionality) +- Provider must document the operational reason and compensating controls +- Requires PMO approval and may require government sponsor acknowledgment + +--- + +## ConMon Escalation Process + +The GovRAMP Continuous Monitoring Escalation Process Guide defines how issues are +escalated when a provider fails to meet ConMon obligations: + +### Escalation Triggers + +- Failure to submit monthly ConMon package on time +- POA&M items exceeding remediation SLAs without an approved deviation +- Critical vulnerabilities not remediated within 30 days +- Discovery of a significant security incident not reported per GovRAMP Incident + Communications Procedures +- Failure to demonstrate progress in the Progressing Snapshot Program (post-Jan 2026) + +### Escalation Steps + +1. **Warning Notice**: PMO notifies provider of the specific compliance gap +2. **Correction Period**: Provider has a defined period to remedy the issue +3. **Status Review**: PMO and relevant committees review the provider's status +4. **Status Downgrade or Suspension**: If not resolved, the product's status may be + downgraded or suspended from the APL +5. **Appeals Committee**: Provider may appeal to the GovRAMP Appeals Committee + +--- + +## Incident Reporting + +Per the GovRAMP Incident Communications Procedures: + +- Security incidents must be reported to the GovRAMP PMO in a timely manner +- The IRP must contain GovRAMP PMO contact information +- Providers must communicate with relevant government customers and stakeholders +- Reporting timelines and communication templates are defined in the GovRAMP Incident + Communications Procedures document (available at https://govramp.org/rev-5-templates-and-resources/) + +--- + +## ConMon Portal Access + +GovRAMP provides government members with access to a secure ConMon portal for +oversight of authorized products. Government officials can: + +- Review current monthly ConMon submissions for authorized providers +- Access historical ConMon records +- Monitor remediation progress +- Receive alerts on significant security events + +This allows government organizations to move from a manual assessment role to an +oversight role, reducing the burden of recurring independent reviews for every provider. + +--- + +## ConMon Tips for Service Providers + +1. **Automate scans** — Use automated vulnerability scanning tools to ensure monthly scans + are consistent, complete, and reproducible +2. **Scan all components** — The most common ConMon finding is scan coverage gaps; ensure + every asset in the system inventory is scanned +3. **Keep the POA&M current weekly** — Waiting until month end creates errors and delays +4. **Track SLAs proactively** — Build alerts in your ticketing system 30 days before any + POA&M item's scheduled completion date +5. **Document everything** — If a vulnerability cannot be reproduced or is a false positive, + document the evidence immediately before submitting a deviation request +6. **Communicate proactively** — If a critical finding will miss its SLA, notify the PMO + before the deadline, not after +7. **Patch third-party dependencies** — Vendor-supplied patches for critical vulnerabilities + must be applied within 30 days; track vendor patch availability in the POA&M +8. **Test the IRP and CP annually** — Missing test documentation is one of the most + common annual finding categories diff --git a/plugins/govramp/skills/govramp/references/control-mapping.md b/plugins/govramp/skills/govramp/references/control-mapping.md new file mode 100644 index 0000000..14743d4 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/control-mapping.md @@ -0,0 +1,288 @@ +# GovRAMP Control Mapping Reference + +This reference covers the NIST SP 800-53 Rev 5 controls relevant to GovRAMP +authorization, with notes on their application at each GovRAMP impact level and +specific implementation guidance for the SLED (state, local, education, tribal) +cloud security context. + +GovRAMP applies NIST SP 800-53 Rev 5 control baselines. The Core status pathway +uses 60 prioritized controls from the Moderate baseline, selected based on the MITRE +ATT&CK Framework. Full control lists for each impact level (Low, Low+, Moderate, +Moderate + CJIS, High) are provided in the official GovRAMP Service Provider Packages. + +Templates available at: https://govramp.org/rev-5-templates-and-resources/ + +--- + +## Control Families Overview + +| ID | Family | Scope | Notes for GovRAMP | +|----|--------|-------|------------------| +| AC | Access Control | All levels | MFA, RBAC, least privilege are Core controls | +| AT | Awareness & Training | All levels | Security awareness + role-based training required | +| AU | Audit & Accountability | M, H | SIEM, log retention critical; Core includes logging controls | +| CA | Assessment, Auth & Monitoring | All levels | Drives 3PAO assessments and ConMon structure | +| CM | Configuration Management | M, H | Baselines, CMDB, change control; Core includes CM controls | +| CP | Contingency Planning | All levels | IRP and CP required for Core, Ready, Authorized | +| IA | Identification & Authentication | All levels | FIPS 140-2/3 required; MFA is a Core control | +| IR | Incident Response | All levels | IRP required and tested; reporting per GovRAMP procedures | +| MA | Maintenance | M, H | Remote maintenance controls | +| MP | Media Protection | M, H | Data at rest encryption; media sanitization | +| PE | Physical & Environmental | M, H | Often inherited from FedRAMP-authorized IaaS | +| PL | Planning | All levels | SSP, Rules of Behavior | +| PM | Program Management | M, H | Enterprise security program oversight | +| PS | Personnel Security | All levels | Background screening, termination; Core covers PS controls | +| PT | PII Processing & Transparency | M, H | Privacy controls (Rev 5 addition); applies to PII systems | +| RA | Risk Assessment | All levels | Vulnerability management; Core covers RA controls | +| SA | System & Services Acquisition | M, H | SDLC security, third-party supply chain | +| SC | System & Comms Protection | All levels | Encryption in transit; network segmentation; Core includes SC | +| SI | System & Information Integrity | All levels | Patching, malware, integrity monitoring; Core includes SI | +| SR | Supply Chain Risk Management | M, H | SCRM (Rev 5 addition) | + +--- + +## GovRAMP Core — 60 Control Areas + +The following control areas are covered by the GovRAMP Core 60-control set, aligned +to the NIST SP 800-53 Rev 5 Moderate baseline and prioritized using the MITRE ATT&CK +Framework. The complete, definitive list is in the official GovRAMP Core Controls +document: https://govramp.org/rev-5-templates-and-resources/ + +### Access Control (AC) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| AC-1 | Policy and Procedures | Required | Document AC policy; review annually | +| AC-2 | Account Management | Required | Provisioning, de-provisioning, reviews; shared account controls | +| AC-3 | Access Enforcement | Required | RBAC or ABAC implementation; enforce least privilege | +| AC-6 | Least Privilege | Required | Restrict privilege to minimum required; review quarterly | +| AC-7 | Unsuccessful Logon Attempts | Required | Account lockout after N failed attempts; document threshold | +| AC-11 | Device Lock | Applies | Session lock after inactivity timeout | +| AC-17 | Remote Access | Required | Document remote access methods; MFA enforced on all paths | +| AC-18 | Wireless Access | Applies | Wireless usage policy; authentication requirements | + +### Awareness and Training (AT) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| AT-1 | Policy and Procedures | Required | Security training policy | +| AT-2 | Literacy Training and Awareness | Required | Annual security awareness for all users | +| AT-3 | Role-Based Training | Required | Specialized training for privileged users and security staff | + +### Audit and Accountability (AU) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| AU-1 | Policy and Procedures | Required | Audit policy and procedures | +| AU-2 | Event Logging | Required | Define auditable events; configure logging system | +| AU-3 | Content of Audit Records | Required | Logs must include: who, what, when, where, outcome | +| AU-6 | Audit Record Review | Required | Define review frequency; document review process | +| AU-9 | Protection of Audit Information | Required | Prevent deletion or modification of logs | +| AU-11 | Audit Record Retention | Required | Minimum 90 days accessible; 1 year total retention | +| AU-12 | Audit Record Generation | Required | All in-scope components generating logs | + +### Configuration Management (CM) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| CM-1 | Policy and Procedures | Required | CM policy | +| CM-2 | Baseline Configuration | Required | Documented baseline configs per component type | +| CM-6 | Configuration Settings | Required | Applied security settings; deviation tracking | +| CM-7 | Least Functionality | Required | Disable unused ports, protocols, services | +| CM-8 | System Component Inventory | Required | Current, accurate inventory of all boundary components | +| CM-10 | Software Usage Restrictions | Applies | Licensed software; prohibition of unauthorized software | + +### Contingency Planning (CP) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| CP-1 | Policy and Procedures | Required | CP policy | +| CP-2 | Contingency Plan | Required | Documented CP with RTO/RPO | +| CP-3 | Contingency Training | Required | Training for staff with CP roles | +| CP-4 | Contingency Plan Testing | Required | Test within past 12 months; document results | +| CP-9 | System Backup | Required | Backup procedures; restoration tested | + +### Identification and Authentication (IA) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| IA-1 | Policy and Procedures | Required | IA policy | +| IA-2 | Identification and Authentication | Required | MFA for all user accounts; privileged and non-privileged | +| IA-3 | Device Identification | Applies | Authenticate devices where feasible | +| IA-5 | Authenticator Management | Required | Password/token management; FIPS 140-2/3 | +| IA-6 | Authenticator Feedback | Applies | Obscure authentication feedback | +| IA-8 | Non-Org User Auth | Required | Government user authentication requirements | + +### Incident Response (IR) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| IR-1 | Policy and Procedures | Required | IRP policy | +| IR-2 | Incident Response Training | Required | Training for all incident responders | +| IR-3 | Incident Response Testing | Required | Test IRP within past 12 months; document results | +| IR-4 | Incident Handling | Required | Containment, eradication, recovery procedures | +| IR-5 | Incident Monitoring | Required | Track and document incidents | +| IR-6 | Incident Reporting | Required | Report to GovRAMP PMO per Incident Communications Procedures | +| IR-8 | Incident Response Plan | Required | Documented IRP with GovRAMP PMO contacts | + +### Personnel Security (PS) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| PS-1 | Policy and Procedures | Required | PS policy | +| PS-3 | Personnel Screening | Required | Background checks before granting access | +| PS-4 | Personnel Termination | Required | Access revocation upon termination | +| PS-5 | Personnel Transfer | Required | Access review on role change | + +### Risk Assessment (RA) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| RA-1 | Policy and Procedures | Required | Risk management policy | +| RA-3 | Risk Assessment | Required | Periodic risk assessment; document results | +| RA-5 | Vulnerability Monitoring and Scanning | Required | Automated scans; coverage of all components | +| RA-7 | Risk Response | Required | Remediation planning for identified risks | + +### System and Communications Protection (SC) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| SC-1 | Policy and Procedures | Required | SC policy | +| SC-5 | Denial of Service Protection | Applies | DDoS mitigation measures | +| SC-7 | Boundary Protection | Required | Firewalls; network segmentation | +| SC-8 | Transmission Confidentiality | Required | Encryption in transit; TLS 1.2 minimum | +| SC-12 | Cryptographic Key Establishment | Required | Key management procedures | +| SC-13 | Cryptographic Protection | Required | FIPS 140-2/3 validated modules only | +| SC-28 | Protection at Rest | Required | Encryption at rest for all government data | + +### System and Information Integrity (SI) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| SI-1 | Policy and Procedures | Required | SI policy | +| SI-2 | Flaw Remediation | Required | Patch management; patch within SLAs | +| SI-3 | Malicious Code Protection | Required | Anti-malware on all applicable components | +| SI-4 | System Monitoring | Required | Intrusion detection; alert review | +| SI-5 | Security Alerts | Required | Subscribe to threat intelligence; act on advisories | +| SI-7 | Software & Information Integrity | Applies | File integrity monitoring | +| SI-10 | Information Input Validation | Applies | Input validation to prevent injection | + +--- + +## Impact Level Differences: Key Control Additions + +### Low Impact (Baseline) +Controls covering basic administrative and procedural safeguards: +- AC family: AC-1, AC-2, AC-3, AC-8, AC-14, AC-17, AC-20 +- AT family: AT-1, AT-2, AT-3 +- AU family: reduced set (AU-1, AU-2, AU-3, AU-6, AU-11, AU-12) +- IA: IA-1, IA-2 (including IA-2(1) for MFA on privileged accounts), IA-4, IA-5 +- IR: IR-1, IR-2, IR-4, IR-5, IR-6, IR-7, IR-8 +- CP: CP-1, CP-2, CP-4 (tabletop only) + +### Moderate Impact (Adds to Low) +Extends Low with more comprehensive controls: +- AC-2 enhancements (automated provisioning review) +- AC-4 Information Flow Enforcement (network segmentation) +- AC-6(1), AC-6(5), AC-6(9), AC-6(10) (Least Privilege enhancements) +- AU-3(1), AU-6(1) (enhanced log content and review) +- CA-2, CA-3, CA-7, CA-9 (assessment and ConMon controls) +- CM-2(2), CM-6(1), CM-7(1), CM-8(1) (enhanced CM) +- CP-6, CP-7, CP-9(1) (alternate sites, backup enhancements) +- IA-2(1), IA-2(2), IA-2(8), IA-2(12) (MFA enhancements) +- IR-3(2) (incident response with support from external providers) +- PT family controls (PII processing and transparency) +- RA-5(1), RA-5(2), RA-5(5) (enhanced scanning) +- SA-3, SA-4, SA-8, SA-9, SA-11 (SDLC, third-party services) +- SC-7 enhancements, SC-8(1), SC-23, SC-28, SC-39 +- SI-2(2), SI-3(1), SI-4(1), SI-4(2), SI-7(1) (enhanced SI) +- SR family (supply chain risk management, new in Rev 5) + +### High Impact (Adds to Moderate) +Most comprehensive set, including: +- Enhanced AC controls for privileged access (AC-2(9), AC-6(3)) +- PIV/CAC authentication requirements (IA-2(12) is critical) +- Full AU suite including real-time alerting +- Extensive CA assessment requirements +- Enhanced CP with multiple alternate sites and full BCP/DR testing +- Additional PE, MA, MP controls +- SI-7 full integrity monitoring suite +- Enhanced SR controls + +### CJIS Overlay (Moderate + CJIS) +Additional requirements overlaid on the Moderate baseline for CJI environments: +- FBI CJIS Security Policy alignment +- Personnel screening to CJIS Security Policy standards +- Encryption requirements specific to CJI handling +- Advanced Authentication (AA) per CJIS requirements +- Data isolation requirements +- Additional audit event capture for CJI data access +- Specific media protection requirements for CJI + +Providers must use the GovRAMP Service Provider Package for Moderate Impact with CJIS +Overlay and the 3PAO Package for Moderate Impact with CJIS Overlay. + +--- + +## Control Implementation Quick Reference + +### MFA Requirements + +| Scenario | Minimum MFA Requirement | +|----------|------------------------| +| Privileged accounts (admin, root) | Required at all impact levels | +| Non-privileged accounts — remote access | Required at Moderate and High | +| Government user accounts | Required at Moderate and High | +| All accounts | Required at High | + +MFA must use FIPS 140-2/3 validated cryptographic mechanisms. + +### Encryption Requirements + +| Data State | Minimum Requirement | +|------------|---------------------| +| Data in transit | TLS 1.2 minimum; TLS 1.3 preferred; FIPS 140-2/3 validated | +| Data at rest | AES-256 (FIPS-approved cipher); FIPS 140-2/3 validated key management | +| Prohibited algorithms | MD5, SHA-1 (for signing), DES, 3DES, RC4, SSLv2, SSLv3, TLS 1.0, TLS 1.1 | + +### Vulnerability Scan Scope Requirements + +| Component Type | Low | Moderate | High | +|----------------|-----|----------|------| +| Operating systems | Monthly | Monthly | More frequent | +| Databases | Not required | Monthly | More frequent | +| Web applications | Not required | Monthly | More frequent | +| Containers and images | Not required | Monthly if used | More frequent | +| Credentialed scans | Recommended | Required | Required | +| Penetration testing | Not required | Annual minimum | Annual minimum | + +### Patch / Flaw Remediation SLAs (GovRAMP) + +| Risk Rating | Remediation Deadline | +|-------------|---------------------| +| Critical | 30 calendar days | +| High | 90 calendar days | +| Moderate | 180 calendar days | +| Low | 365 calendar days | + +--- + +## Cross-Framework Alignment + +GovRAMP's NIST 800-53 Rev 5 foundation enables straightforward alignment with other +frameworks commonly used by SLED organizations: + +| Framework | Alignment Note | +|-----------|----------------| +| FedRAMP Rev 5 | Direct alignment; Fast Track leverages FedRAMP documentation | +| NIST CSF 2.0 | NIST 800-53 Rev 5 is the detailed implementation layer for CSF functions | +| CJIS Security Policy | CJIS Overlay in GovRAMP maps CJI-specific requirements onto the control baseline | +| TX-RAMP | Automatic reciprocity — GovRAMP Authorized products are recognized by TX-RAMP | +| HIPAA/HITECH | Moderate baseline covers the technical security controls required for PHI in government systems | +| SOC 2 | SOC 2 controls partially map to NIST 800-53; existing SOC 2 reports referenced in PMO assessment | +| ISO 27001 | ISO 27001 controls map to NIST 800-53; can be leveraged as evidence in PMO review | + +> Note: While GovRAMP accepts evidence from other frameworks (SOC 2, ISO 27001) as +> supporting documentation, GovRAMP status requires demonstration of the specific NIST +> 800-53 Rev 5 controls in the applicable baseline. Existing certifications accelerate +> readiness but do not substitute for GovRAMP authorization requirements. diff --git a/plugins/govramp/skills/govramp/references/readiness-checklist.md b/plugins/govramp/skills/govramp/references/readiness-checklist.md new file mode 100644 index 0000000..4695d76 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/readiness-checklist.md @@ -0,0 +1,233 @@ +# GovRAMP Readiness Checklist + +Use this checklist when performing a gap assessment for any GovRAMP status level. +For each item, mark: Met | Partial | Not Met | N/A + +Impact levels: Low (L) | Moderate (M) | High (H) +Where multiple levels are shown, the control applies at that level and above. + +--- + +## 1. Membership and Program Enrollment + +- [ ] Service provider is an active GovRAMP member +- [ ] Membership tier is appropriate for the organization's size and revenue +- [ ] Security Review Request Form has been identified and is accessible + +--- + +## 2. Boundary and System Documentation + +- [ ] Authorization boundary is formally defined in writing +- [ ] Network architecture diagram is current and depicts the full boundary +- [ ] Data flow diagrams show all data entering, leaving, and moving within the boundary +- [ ] System inventory (hardware, software, virtual, container assets) is complete +- [ ] All external connections and third-party services are documented +- [ ] External services outside boundary are FedRAMP-authorized, GovRAMP-authorized, or + have documented compensating controls +- [ ] System categorization (FIPS 199 logic) is complete with impact level determination +- [ ] Data Classification Tool assessment completed (if impact level is uncertain) +- [ ] Service model is defined (SaaS / PaaS / IaaS) +- [ ] Leveraged cloud platform authorization documented (e.g., AWS GovCloud, Azure Government) + +--- + +## 3. Policies and Procedures + +- [ ] Information Security Policy — approved and in effect (L, M, H) +- [ ] Acceptable Use Policy / Rules of Behavior — documented and user-acknowledged (L, M, H) +- [ ] Access Control Policy (L, M, H) +- [ ] Configuration Management Policy and Plan (L, M, H) +- [ ] Incident Response Plan (IRP) — documented, tested within last 12 months (L, M, H) +- [ ] Contingency Plan (CP) — documented, tested within last 12 months (L, M, H) +- [ ] Media Protection Policy (M, H) +- [ ] Personnel Security Policy (L, M, H) +- [ ] Physical Security Policy (or fully inherited from IaaS provider) (L, M, H) +- [ ] Privacy policy and PII handling procedures documented (M, H) +- [ ] Supply Chain Risk Management policy (M, H) +- [ ] Change Management Policy (M, H) +- [ ] Vulnerability Management Policy (L, M, H) + +--- + +## 4. Access Control and Identity + +- [ ] Multi-factor authentication (MFA) enforced on all privileged accounts (L, M, H) +- [ ] MFA enforced on all remote access paths (L, M, H) +- [ ] Role-based access control (RBAC) implemented and documented (M, H) +- [ ] Least privilege principle applied and documented (L, M, H) +- [ ] Privileged account access reviews performed quarterly or more frequently (M, H) +- [ ] User access reviews performed at least annually (L, M, H) +- [ ] Account provisioning and de-provisioning process documented and in use (L, M, H) +- [ ] Shared/service accounts documented and controlled (M, H) +- [ ] Emergency access accounts documented and controlled (M, H) +- [ ] FIPS 140-2 or 140-3 validated authentication mechanisms in use (M, H) + +--- + +## 5. Encryption + +- [ ] All government data encrypted at rest using FIPS 140-2/3 validated modules (M, H) +- [ ] All government data encrypted in transit using TLS 1.2 minimum (1.3 preferred) (L, M, H) +- [ ] Key management procedures documented (M, H) +- [ ] Non-FIPS algorithms (MD5, SHA-1, DES, RC4) eliminated from the boundary (M, H) +- [ ] Certificate management process documented (expiration tracking) (M, H) + +--- + +## 6. Vulnerability Management + +Per the GovRAMP Vulnerability Scan Requirements Guide: + +- [ ] Automated vulnerability scanning program in place (L, M, H) +- [ ] Scans cover all OS-level components within the boundary (L, M, H) +- [ ] Scans cover all database components within the boundary (M, H) +- [ ] Scans cover all web application components within the boundary (M, H) +- [ ] Scans cover containers (if used) (M, H) +- [ ] Scan frequency meets GovRAMP requirements (minimum monthly for Moderate/High) (M, H) +- [ ] Penetration testing performed per GovRAMP Penetration Test Guidance (M, H) +- [ ] Penetration test conducted within the past 12 months (at minimum) (M, H) +- [ ] Vulnerability scan results are tracked and remediated per SLAs (L, M, H) +- [ ] All critical vulnerabilities tracked in POA&M with remediation plans (L, M, H) + +--- + +## 7. Logging and Monitoring + +- [ ] Centralized logging/SIEM is in place (M, H) +- [ ] All in-scope components are sending logs to centralized SIEM (M, H) +- [ ] Log retention period meets requirements (minimum 90 days online; 1 year retained) (M, H) +- [ ] Security alerts and anomalies are reviewed and actioned (M, H) +- [ ] Privileged account activity is logged (L, M, H) +- [ ] Audit logs are protected from modification or deletion (M, H) +- [ ] Network traffic monitoring in place (M, H) + +--- + +## 8. Incident Response + +- [ ] Incident Response Plan (IRP) is documented and current (L, M, H) +- [ ] IRP has been tested within the past 12 months (tabletop or functional exercise) (L, M, H) +- [ ] IRP test results are documented (L, M, H) +- [ ] Incident reporting timelines are defined and aligned with GovRAMP Incident + Communications Procedures (L, M, H) +- [ ] Contact information for GovRAMP PMO is in the IRP (L, M, H) +- [ ] Security incident categories are defined (L, M, H) +- [ ] Forensic evidence preservation procedures are documented (M, H) +- [ ] Lessons learned process exists post-incident (M, H) + +--- + +## 9. Contingency Planning + +- [ ] Contingency Plan (CP) is documented and current (L, M, H) +- [ ] CP defines Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) (L, M, H) +- [ ] CP has been tested within the past 12 months (L, M, H) +- [ ] CP test results are documented (L, M, H) +- [ ] Data backup and restoration procedures are documented and tested (L, M, H) +- [ ] Backup restoration tested successfully within the past 12 months (M, H) +- [ ] Alternate processing/hosting site or failover capability is documented (M, H) + +--- + +## 10. Configuration Management + +- [ ] Configuration baselines defined for all in-scope components (M, H) +- [ ] Configuration Management Plan documented (M, H) +- [ ] Change management process in place; changes reviewed and approved (M, H) +- [ ] System component inventory (CMDB) is current and accurate (M, H) +- [ ] Unauthorized change detection (file integrity monitoring or equivalent) in place (M, H) +- [ ] CIS Benchmarks or DISA STIGs applied where applicable (M, H) + +--- + +## 11. Personnel Security + +- [ ] Background screening process documented for staff with system access (L, M, H) +- [ ] Background checks conducted before granting access (M, H) +- [ ] Termination procedures documented (access revocation timeline) (L, M, H) +- [ ] Contractor and third-party access controls documented (M, H) +- [ ] Security awareness training program in place (L, M, H) +- [ ] Training completion is tracked and documented (L, M, H) +- [ ] Role-based security training for privileged users (M, H) + +--- + +## 12. Physical and Environmental Security + +- [ ] Physical security controls documented (or inherited from FedRAMP-authorized IaaS) (L, M, H) +- [ ] Access to servers and data center is restricted and logged (M, H) +- [ ] Environmental controls (temperature, humidity, fire suppression) documented or + inherited (M, H) + +--- + +## 13. System and Communications Protection + +- [ ] Network segmentation in place between in-scope and out-of-scope systems (M, H) +- [ ] Firewall rules documented and reviewed regularly (M, H) +- [ ] Web application firewall (WAF) or equivalent in place (M, H) +- [ ] Ports, protocols, and services (PPS) table is documented in the SSP (L, M, H) +- [ ] Boundary protection devices (firewalls, IDS/IPS) are in place and monitored (M, H) + +--- + +## 14. Privacy (NIST 800-53 Rev 5 PT Family) + +- [ ] Privacy policy published and available to government customers and end users (M, H) +- [ ] PII inventory or data map exists (M, H) +- [ ] Privacy impact assessment process in place for new system changes (M, H) +- [ ] Consent mechanisms documented for PII collection (where applicable) (M, H) + +--- + +## 15. CJIS Overlay (if applicable) + +Only required for providers handling Criminal Justice Information (CJI): + +- [ ] Provider has identified CJI data types in scope +- [ ] CJIS Security Policy requirements mapped to GovRAMP controls +- [ ] Using the GovRAMP Service Provider Package for Moderate Impact with CJIS Overlay +- [ ] Using the GovRAMP 3PAO Package for Moderate Impact with CJIS Overlay +- [ ] CJI handling, access, and storage controls documented separately + +--- + +## 16. Authorization Documentation Completeness + +- [ ] System Security Plan (SSP) is drafted using GovRAMP templates +- [ ] All required control implementation statements present in SSP +- [ ] Authorization boundary diagram embedded in SSP +- [ ] Data flow diagrams embedded in SSP +- [ ] PPS table completed in SSP +- [ ] External connections table completed in SSP +- [ ] Incident Response Plan included as SSP appendix or standalone +- [ ] Contingency Plan included as SSP appendix or standalone +- [ ] Plan of Action & Milestones (POA&M) is drafted +- [ ] All known gaps entered in POA&M with risk ratings and remediation plans +- [ ] Vulnerability scan results available for submission +- [ ] Penetration test report available (Ready and Authorized) + +--- + +## Readiness Summary (Completed Checklist Output) + +After completing the checklist, summarize: + +| Category | Met Count | Not Met Count | Blockers for Status? | +|----------|-----------|---------------|----------------------| +| Boundary / Documentation | | | | +| Policies and Procedures | | | | +| Access Control | | | | +| Encryption | | | | +| Vulnerability Management | | | | +| Logging / Monitoring | | | | +| Incident Response | | | | +| Contingency Planning | | | | +| Configuration Management | | | | +| Personnel Security | | | | +| Authorization Documentation | | | | + +**Top 5–10 Priority Gaps:** [List highest-risk items blocking the target status] + +**Recommended Next Step:** [Core / Ready / Authorized / Fast Track / Progressing Snapshot] diff --git a/plugins/govramp/skills/govramp/references/ssp-guide.md b/plugins/govramp/skills/govramp/references/ssp-guide.md new file mode 100644 index 0000000..17e6e2b --- /dev/null +++ b/plugins/govramp/skills/govramp/references/ssp-guide.md @@ -0,0 +1,248 @@ +# GovRAMP System Security Plan (SSP) Writing Guide + +The System Security Plan (SSP) is the foundational document for any GovRAMP +authorization. It describes what the system is, what data it handles, how the +authorization boundary is defined, and how each applicable NIST 800-53 Rev 5 control +is implemented. + +GovRAMP templates align with FedRAMP document structures and are accepted in FedRAMP +formatting. Always use official GovRAMP templates available at: +https://govramp.org/rev-5-templates-and-resources/ + +Service Provider Packages are available for: +- Low Impact +- Moderate Impact (most common) +- Moderate Impact with CJIS Overlay +- High Impact + +--- + +## SSP Section-by-Section Guide + +### Section 1: System Name and Identifier + +- Formal product/service name +- Unique product identifier +- Service model: SaaS / PaaS / IaaS +- Deployment model: Public / Private / Community / Hybrid cloud +- GovRAMP membership number (if available at time of writing) + +--- + +### Section 2: System Categorization and Impact Level + +- Complete FIPS 199 categorization for each information type handled: + - Confidentiality: Low / Moderate / High + - Integrity: Low / Moderate / High + - Availability: Low / Moderate / High +- Overall impact level = high-water mark of the three values +- Justify each categorization with the types of government information processed +- Cross-reference the GovRAMP Data Classification Tool output +- Identify whether CJIS Overlay applies + +**Common SSP mistakes:** +- Assigning "Low" to all categories without justification when moderate-sensitivity + government data is involved +- Not documenting information types — vague statements like "we process government data" + are insufficient + +--- + +### Section 3: System Ownership and Contacts + +- System Owner name, title, and contact information +- GovRAMP Program Manager contact +- Authorizing Official contact (government sponsor, once identified) +- Primary 3PAO contact (for Ready/Authorized paths) + +--- + +### Section 4: Assignment of Security Responsibility + +- Identify the person (title and contact) responsible for the overall security of the system +- Document the security team structure if applicable + +--- + +### Section 5: System Mission and Purpose + +- What does the system do? +- What government programs, agencies, or organizations does it serve? +- What types of government data does it handle? +- Who are the typical end users? + +--- + +### Section 6: General System Description + +- Narrative description of the technology stack +- Key system components (web servers, databases, APIs, integrations) +- Cloud platform and region (if cloud-hosted) +- Whether the system uses a FedRAMP-authorized IaaS/PaaS (AWS GovCloud, Azure Government, + Google Cloud FedRAMP regions) — critical for inherited control documentation + +--- + +### Section 7: Authorization Boundary (Highest Scrutiny) + +This is one of the most scrutinized sections in any GovRAMP review. + +**What to include:** +- Clear written narrative describing exactly what is inside and outside the boundary +- Which components process, store, or transmit government data (all must be inside) +- Which external services are used and whether they are in or out of scope +- Network architecture diagram embedded (not just referenced as an attachment) +- Data flow diagrams showing all data entering, leaving, and moving within the boundary +- Ports, Protocols, and Services (PPS) table +- External connections table (documenting every connection to services outside the boundary) + +**Inherited Controls:** +If the provider uses a FedRAMP-authorized IaaS/PaaS, document which controls are: +- Fully inherited: The IaaS/PaaS fully satisfies the control; provider has no additional obligation +- Partially inherited: The IaaS/PaaS satisfies part of the control; provider must address the remainder +- Not inherited: Provider fully implements the control + +**Common boundary mistakes:** +- Vague boundary language such as "our cloud environment" without specifying which + services, regions, and components are in scope +- Not documenting admin/management traffic flows (VPN, jump boxes, monitoring agents) +- Failing to document external SaaS tools used by operations staff that touch in-scope data +- Not updating the boundary when systems change + +--- + +### Section 8: Control Implementation Statements + +This is the largest and most critical section of the SSP. For each applicable NIST +800-53 Rev 5 control: + +**Required sub-elements per control:** + +1. **Implementation Status**: Implemented / Partially Implemented / Planned / Alternative Implementation +2. **Control Origination**: Provider (CSP), Customer/Government, Shared, or Inherited from leveraged service +3. **Implementation Description**: Prose narrative describing exactly how the control is satisfied + +**Writing principles:** + +- **Describe only what is implemented** — Do not describe planned or aspirational controls + as if they are in place. Unimplemented controls must go in the POA&M. +- **Be specific** — Reference exact tool names, policy document names, configuration + settings, section numbers. Vague language causes findings. +- **Address every verb** — Each control requirement uses specific action verbs (establish, + implement, enforce, document, review, test, monitor). Address each one explicitly. +- **Shared responsibility** — For any control where both the provider and the government + customer share responsibility, create a clear "Customer Responsibility" section. +- **Internal consistency** — Control statements must be consistent with the architecture + diagrams, data flow diagrams, and system inventory. Inconsistencies cause findings. + +**Example structure for a control narrative:** + +``` +AC-2 — Account Management + +Implementation Status: Implemented +Control Origination: Service Provider (with Customer Responsibility noted) + +The [System Name] manages user accounts using [identity management tool/system]. +Account provisioning requires approval from [role/team] via [ticketing system]. +Accounts are reviewed quarterly by [role] against the current inventory of +authorized users. Accounts are disabled within [X hours] of termination notification +received from [HR/manager via process]. + +Customer Responsibility: Government customers are responsible for notifying +[System Name] administrators within [timeframe] when a user transfers, changes +role, or is terminated. +``` + +--- + +### Section 9: Leveraged Authorizations + +If the system uses a FedRAMP-authorized or GovRAMP-authorized platform: + +- List each leveraged service name, authorization type (FedRAMP/GovRAMP), and impact level +- Use the Cloud Integration Standard (CIS) / Customer Responsibility Matrix (CRM) workbook + to document which controls are inherited vs. provider-implemented vs. customer responsibility +- The GovRAMP PMO accepts documents in FedRAMP formatting for this workbook + +--- + +### Section 10: Interconnections + +- List all external connections (to government systems, other vendors, etc.) +- For each interconnection: system name, owner, connection type, data type, security controls +- Interconnection Security Agreements (ISAs) or Memoranda of Understanding (MOUs) should + reference each interconnection + +--- + +## SSP Appendices Required for GovRAMP + +| Appendix | Content | +|----------|---------| +| Incident Response Plan (IRP) | Documented and tested within past 12 months | +| Contingency Plan (CP) | Documented and tested within past 12 months | +| Rules of Behavior | User acknowledgment of acceptable use | +| Privacy Impact Assessment (PIA) | Required for Moderate and High where PII is processed | +| Vulnerability Scan Results | Most recent scan results for all applicable layers | +| POA&M | All open findings with risk ratings and remediation plans | +| Authorization Boundary Diagram | Standalone diagram if not embedded in Section 7 | + +--- + +## SSP Writing Tips by Control Family + +### Access Control (AC) +- Be specific about how MFA is enforced — name the tool (e.g., Duo, Okta, Azure AD MFA) +- Document RBAC roles explicitly; generic statements like "we use role-based access" + are insufficient +- Address privileged account controls separately from standard user controls + +### Audit and Accountability (AU) +- Name the SIEM or logging platform +- Specify log retention: minimum 90 days accessible online, total 1 year retained +- Document who reviews logs and at what frequency +- Identify which audit events are captured (NIST 800-53 AU-2 event types) + +### Configuration Management (CM) +- Reference the specific baseline standard used (CIS Benchmark, DISA STIG) +- Name the configuration management tool (Ansible, Puppet, AWS Config, etc.) +- Describe the change management process and approval workflow + +### Identification and Authentication (IA) +- State that FIPS 140-2 or 140-3 validated cryptographic modules are used +- Reference the specific module (e.g., OpenSSL FIPS module) if known +- Describe password/authentication policy specifics (MFA types, session timeout) + +### Incident Response (IR) +- Reference the IRP appendix but also summarize roles, reporting timelines, and + GovRAMP reporting obligations in the control narrative +- Include the GovRAMP Incident Communications Procedures contact information + +### Risk Assessment (RA) +- Name the vulnerability scanning tools used and their scope (OS, DB, web app, container) +- Reference the scan frequency and confirm alignment with GovRAMP Vulnerability Scan + Requirements Guide +- Address penetration testing cadence and methodology + +### System and Communications Protection (SC) +- Document encryption in transit: TLS version and which connections are encrypted +- Document encryption at rest: algorithm, key length, FIPS module reference +- Describe network segmentation between in-scope and out-of-scope components + +--- + +## Common SSP Review Findings + +The following are frequently cited GovRAMP review findings that delay authorization: + +1. Control statements that say "we plan to implement" rather than "we have implemented" +2. Missing PPS table or incomplete external connections documentation +3. Architecture diagram that does not match the written boundary description +4. Inherited controls listed without referencing the specific leveraged authorization +5. Missing customer responsibility sections for shared controls +6. IRP and CP that have not been tested or lack test documentation +7. Incomplete POA&M — known gaps existed but were not documented +8. No documentation of vulnerability scans or scans that do not cover all boundary components +9. Encryption described vaguely — no module name, no algorithm specification +10. Logging not covering all in-scope components diff --git a/plugins/govramp/skills/govramp/references/status-pathways.md b/plugins/govramp/skills/govramp/references/status-pathways.md new file mode 100644 index 0000000..9a97015 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/status-pathways.md @@ -0,0 +1,223 @@ +# GovRAMP Status Pathways — Decision Guide + +Use this reference when helping a provider or government entity determine the most +appropriate GovRAMP status pathway based on their situation, goals, resources, and +existing authorizations. + +--- + +## Status Pathway Overview + +| Status | 3PAO Required | Gov Sponsor | ConMon Frequency | Key Requirement | Listed on APL | +|--------|--------------|-------------|-----------------|-----------------|---------------| +| Progressing Snapshot | No | No | N/A (not verified) | Membership; quarterly engagement | No (Progressing List) | +| Core | No (PMO review) | No | Quarterly | 60 controls evidenced; templates | Yes | +| Ready | Yes (RAR) | No | Monthly + Annual | Min. mandatory req's; 50% docs | Yes | +| Authorized | Yes (SAR) | Yes | Monthly + Annual | All controls; 100% docs | Yes | +| Provisionally Authorized | Yes (SAR) | Pending/Committee | Monthly + Annual | All controls; sponsor in process | Yes | + +--- + +## Decision Tree: Which Pathway Is Right? + +### Step 1: Do you already hold FedRAMP authorization? + +**YES** → **Fast Track** is available. You can submit existing federal security documentation +(FedRAMP SSP, SAR, 90 days of ConMon data) to the GovRAMP PMO. GovRAMP accepts +documents in FedRAMP formatting. Fast Track applies to Ready or Authorized status. +Proceed to Step 5 for Fast Track specifics. + +**NO** → Proceed to Step 2. + +--- + +### Step 2: What is your primary goal? + +**A. Build initial credibility and visibility with less upfront investment** +→ Consider **Progressing Snapshot** first, then progress to Core or Ready. + +**B. Achieve a formal verified status without a full 3PAO audit** +→ Target **GovRAMP Core** (launched May 2025; 60 controls; PMO-reviewed). + +**C. Achieve full verified status demonstrating minimum mandatory requirements** +→ Target **GovRAMP Ready** (3PAO Readiness Assessment Report required). + +**D. Achieve the highest level of assurance to compete for major government contracts** +→ Target **GovRAMP Authorized / Provisionally Authorized** (3PAO SAR + government sponsor). + +--- + +### Step 3: What impact level do you need? + +Use the GovRAMP Data Classification Tool to determine your level: +https://govramp.org/blog/document/data-classification-tool/ + +| Government Data Type | Likely Impact Level | +|---------------------|---------------------| +| Public records, administrative tools, non-PII systems | Low | +| General PII, non-law-enforcement public records | Low+ or Moderate | +| Healthcare data (PHI), financial data, voter records | Moderate | +| Criminal Justice Information (CJI) | Moderate + CJIS Overlay | +| Emergency services, critical infrastructure, classified-adjacent data | High | + +Core status is aligned to the **Moderate** baseline regardless of the provider's +ultimate target level. It provides a foundation before pursuing full Moderate or High +authorization. + +--- + +### Step 4: What is your readiness? + +| Readiness State | Recommended Path | +|----------------|-----------------| +| Early stage; significant gaps; first time building a security program | Progressing Snapshot → Core | +| Documentation partially complete; controls partially implemented | Core (if no 3PAO budget) or Ready (if 3PAO budget available) | +| Documentation near-complete; controls mostly implemented | Ready → Authorized | +| Documentation fully complete; controls fully implemented | Authorized directly | +| FedRAMP-authorized or in active pursuit | Fast Track | + +--- + +### Step 5: Fast Track Decision + +**Prerequisites:** +- Active GovRAMP membership +- Existing FedRAMP authorization OR active FedRAMP pursuit with documentation available +- 90 days of continuous monitoring data +- Completed federal-approved security package + +**Fast Track Process:** +1. Submit a Security Review Request Form to the GovRAMP PMO +2. Work with 3PAO to gather and authenticate: federal security package, 90 days of + ConMon data, any required GovRAMP-specific template adjustments +3. PMO reviews package and conducts a review call with provider and 3PAO +4. Provider achieves Ready or Authorized status (PMO determination) +5. Begin GovRAMP Continuous Monitoring + +**Texas Note:** TX-RAMP recognizes GovRAMP with automatic reciprocity. GovRAMP provides +a weekly sync — GovRAMP-authorized products automatically appear on the TX-RAMP list. + +--- + +## Pathway Comparison — Effort and Cost + +### GovRAMP Core + +| Dimension | Detail | +|-----------|--------| +| Controls assessed | 60 (NIST 800-53 Rev 5 Moderate-aligned, MITRE ATT&CK prioritized) | +| Assessment method | PMO review of submitted documentation and evidence | +| 3PAO required | No | +| Policies required | Yes (for all 60 control areas) | +| Templates required | SSP, IRP, CP, Scan documentation (Moderate Impact package) | +| ConMon | Quarterly | +| Typical timeline | Shorter than Ready/Authorized (no 3PAO engagement) | +| Costs | Membership ($1,500+) + PMO Fee ($9,000–$17,000 depending on revenue) | +| APL listing | Yes | + +### GovRAMP Ready + +| Dimension | Detail | +|-----------|--------| +| Controls assessed | Minimum mandatory requirements for target impact level | +| Assessment method | 3PAO Readiness Assessment Report (RAR) | +| 3PAO required | Yes | +| Documentation required | 50% complete at submission; 100% by Authorized | +| ConMon | Monthly + Annual | +| Typical timeline | Longer than Core (requires 3PAO engagement) | +| Costs | Membership + 3PAO fees (market rate) + Ready review fee ($500–$3,750) | +| APL listing | Yes | + +### GovRAMP Authorized + +| Dimension | Detail | +|-----------|--------| +| Controls assessed | All required controls at target impact level (Low, Moderate, High) | +| Assessment method | Full 3PAO Security Assessment Report (SAR) | +| 3PAO required | Yes | +| Government sponsor | Required (direct government sponsor or GovRAMP Approvals Committee) | +| Documentation required | 100% complete | +| ConMon | Monthly + Annual | +| Typical timeline | Longest of all paths | +| Costs | Membership + 3PAO fees + Authorized review fee ($1,500–$7,500) + ConMon monthly fee | +| APL listing | Yes (as Authorized) | + +--- + +## Government Sponsorship + +### What Is a Government Sponsor? + +For GovRAMP Authorized status, an authorizing government official (at a state, local, +education, tribal, or special district organization) must review and approve the +provider's security package. + +### Two Sponsorship Options + +**Option 1: Direct Government Sponsor** +A specific government agency agrees to sponsor the provider. The sponsoring agency +reviews the security package and signs off on the authorization. + +Requirements for the sponsoring government (from the GovRAMP Provider Sponsor +Requirements document): +- Must be an active GovRAMP member (or become one) +- Must designate a responsible government official +- Must review and accept the provider's security package + +**Option 2: GovRAMP Approvals Committee** +If a provider cannot secure a direct government sponsor, the GovRAMP Approvals +Committee (composed of active state and local government representatives) can serve +as the appointed sponsor and confirm the package meets all requirements. This results +in **GovRAMP Provisionally Authorized** status until a formal government sponsor +assumes responsibility. + +--- + +## Progressing Snapshot: When to Use It + +The Progressing Snapshot is **not a verified status**. Products are listed on the +Progressing Product List, not the Authorized Product List. Use this pathway when: + +- The provider is in early stages of building a security program +- The organization wants PMO guidance before committing to 3PAO assessment costs +- The organization wants to appear on the GovRAMP product list in a non-verified + capacity while working toward Core, Ready, or Authorized +- The provider is exploring what level of effort full authorization will require + +**January 1, 2026 Change:** Products on the Progressing List must demonstrate active +advancement toward a verified status. Products failing to show progress are subject to +escalation and potential removal from the Progressing List. + +--- + +## Appeals and Exceptions + +The GovRAMP **Appeals Committee** handles: +- Conflict-of-interest claims +- Disagreements over status determinations +- Requests for exceptions + +The Appeals Committee is composed of at least five members appointed by the Board, +including at least one Board member. The Executive Committee may appoint subject matter +experts to assist with specific claims. + +--- + +## Glossary of Key Terms + +| Term | Definition | +|------|-----------| +| APL | Authorized Product List — GovRAMP's public listing of products with verified security status | +| 3PAO | Third-Party Assessment Organization — an independent assessor accredited to conduct GovRAMP assessments | +| SLED | State, Local, Education, and tribal governments — GovRAMP's primary target customer base | +| PMO | Program Management Office — GovRAMP's PMO is serviced by RAMPQuest, powered by Knowledge Services | +| ConMon | Continuous Monitoring — ongoing security reporting obligations for authorized products | +| RAR | Readiness Assessment Report — 3PAO deliverable for the Ready status path | +| SAR | Security Assessment Report — 3PAO deliverable for the Authorized status path | +| SSP | System Security Plan — the foundational security documentation for a service provider | +| POA&M | Plan of Action and Milestones — tracks open findings and remediation plans | +| IRP | Incident Response Plan — required at all authorization levels including Core | +| CP | Contingency Plan — required at all authorization levels including Core | +| CJI | Criminal Justice Information — data type requiring the CJIS Overlay at Moderate impact level | +| Fast Track | Expedited GovRAMP authorization pathway for FedRAMP-authorized providers | +| TX-RAMP | Texas Risk and Authorization Management Program — recognizes GovRAMP with reciprocity | diff --git a/plugins/iso22301/.claude-plugin/plugin.json b/plugins/iso22301/.claude-plugin/plugin.json new file mode 100644 index 0000000..3059ccf --- /dev/null +++ b/plugins/iso22301/.claude-plugin/plugin.json @@ -0,0 +1,22 @@ +{ + "name": "iso22301", + "description": "ISO 22301:2019 Business Continuity Management System (BCMS) advisor — gap analysis, BIA, risk assessment, BC strategy, BCP authoring, exercise programmes, and certification readiness.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "iso22301", + "bcms", + "business-continuity", + "bcp", + "bia", + "disaster-recovery", + "resilience", + "grc" + ] +} diff --git a/plugins/iso22301/skills/iso22301/SKILL.md b/plugins/iso22301/skills/iso22301/SKILL.md new file mode 100644 index 0000000..49bf426 --- /dev/null +++ b/plugins/iso22301/skills/iso22301/SKILL.md @@ -0,0 +1,712 @@ +--- +name: iso22301 +description: > + Expert ISO 22301 Business Continuity Management System (BCMS) advisor. Use this skill + whenever a user asks about ISO 22301, ISO/IEC 22301:2019, business continuity management, + business continuity plans (BCP), business impact analysis (BIA), recovery time objectives + (RTO), recovery point objectives (RPO), maximum tolerable period of disruption (MTPD), + minimum business continuity objective (MBCO), BCMS implementation, gap analysis, BC + strategy, BC exercises and testing, incident response structure, BCMS certification, + BCMS scope, continuity of operations, disaster recovery planning under ISO frameworks, + or any question about maintaining operations during a disruption. Also trigger for + requests to draft BC policies, BIA templates, BCP documents, exercise reports, or + management review inputs. Trigger even if the user does not say "skill" — any business + continuity or ISO 22301 question should use this skill. +--- + +# ISO 22301 Business Continuity Management System (BCMS) Skill + +You are an expert ISO 22301 Lead Auditor and BCMS implementation consultant. You assist +organisations at all stages of the business continuity lifecycle: from initial gap analysis +and BIA through to BC strategy, plan authoring, exercise programmes, and certification readiness. + +--- + +## How to Respond + +Always clarify the version in use if relevant context is missing. The current version is +**ISO 22301:2019** (Security and resilience — Business continuity management systems — +Requirements), which replaced ISO 22301:2012. Where significant differences exist between +2012 and 2019, note them. + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Clause | Requirement | Status (RAG) | Evidence Needed | Gap Notes | +| BIA | Structured table: Activity | MTPD | RTO | RPO | MBCO | Dependencies | Priority | +| Risk assessment | Risk register: Scenario | Likelihood | Impact | Score | Treatment | Owner | +| BC strategy | Narrative + options table: Activity | Strategy Option | Justification | +| Policy generation | Full structured policy with document control block | +| BCP authoring | Structured plan with activation, roles, procedures, communication | +| Exercise plan | Objectives, scope, scenario, method, roles, evaluation criteria | +| Certification readiness | Stage 1 / Stage 2 checklist with RAG status | +| General question | Clear, concise prose with clause citations | + +Always cite the relevant ISO 22301:2019 clause (e.g., Clause 8.2.2) in all outputs. + +--- + +## Standard Overview + +**ISO 22301:2019** was published in October 2019 by ISO/TC 292 (Security and resilience). +It is the international standard specifying requirements for a **Business Continuity Management +System (BCMS)** — a management system that enables an organisation to plan, establish, +implement, operate, monitor, review, maintain, and continually improve its ability to deliver +products and services at acceptable predefined levels following a disruption. + +### Scope and Applicability +ISO 22301 applies to **all organisations, in all sectors and of all sizes**, wherever continuity +of operations is a concern. It is sector-agnostic and scalable from small businesses to large +multinationals and government bodies. It can be used as: +- A framework for internal BCMS implementation +- A basis for third-party certification by an accredited certification body +- A contractual or procurement requirement + +### High Level Structure (HLS) +ISO 22301:2019 adopts ISO's **High Level Structure (Annex SL)**, meaning its clause structure +(Clauses 4–10) is directly compatible with: +- ISO 27001:2022 (information security) — Clause 8 of ISO 27001 references BC via A.5.29/A.5.30 +- ISO 9001:2015 (quality management) +- ISO 14001:2015 (environmental management) +- ISO 42001:2023 (AI management) + +This allows integrated management systems to share policy, documentation, internal audit, and +management review processes. + +### Key Differences: ISO 22301:2019 vs 2012 +| Area | 2012 | 2019 | +|------|------|------| +| Structure | Pre-HLS | Full HLS (Annex SL) compatible | +| BIA and risk | Single section | Separated into 8.2.2 (BIA) and 8.2.3 (risk) | +| BC strategies | Implied | Explicit standalone clause (8.3) | +| Incident response | Covered in plans | Explicit sub-clause (8.4.2) | +| Protection/mitigation | Limited | Explicit sub-clause (8.3.5) | +| Language | Organisation-specific | Aligned to ISO HLS terminology | +| Certification | Applicable | Applicable, transition required by end 2023 | + +--- + +## Clause Structure and Key Requirements + +### Clause 4 — Context of the Organisation +**4.1 Understanding the organisation and its context** +- Identify internal and external issues relevant to the organisation's purpose that affect the ability to achieve intended BCMS outcomes +- Consider: political, economic, social, technological, legal, regulatory, environmental factors; organisational governance; contractual obligations; supply chain; critical stakeholders + +**4.2 Understanding needs and expectations of interested parties** +- Identify relevant interested parties (customers, employees, shareholders, regulators, suppliers, insurers, communities) +- Understand their requirements regarding business continuity +- Determine which requirements are addressed through the BCMS + +**4.3 Determining the scope of the BCMS** +- Establishes the internal and external boundaries +- Defines which products/services, activities, sites, and processes are within scope +- Considers issues from 4.1 and interested party requirements from 4.2 +- **Mandatory documented output**: BCMS scope statement + +**4.4 Business continuity management system** +- Establish, implement, maintain, and continually improve the BCMS in accordance with the standard + +--- + +### Clause 5 — Leadership +**5.1 Leadership and commitment** +- Top management demonstrates accountability for BCMS effectiveness +- Ensures BCMS policy and objectives are compatible with organisational strategy +- Integrates BCMS requirements into business processes +- Ensures resources are available +- Communicates importance of effective business continuity management +- Directs and supports individuals to contribute to BCMS effectiveness + +**5.2 Policy** +- Top management establishes, implements, and maintains a business continuity policy that: + - Is appropriate to the purpose of the organisation + - Provides framework for setting objectives + - Includes commitment to satisfy applicable requirements + - Includes commitment to continual improvement + - Is communicated within the organisation + - Is available to interested parties as appropriate +- **Mandatory documented output**: Business continuity policy + +**5.3 Organisational roles, responsibilities and authorities** +- Top management assigns and communicates responsibility and authority for: + - Ensuring BCMS conforms to requirements + - Reporting on BCMS performance to top management +- Key roles typically include: BCMS Manager/Owner, BIA Owner(s), Plan Owner(s), Incident Commander, Crisis Management Team + +--- + +### Clause 6 — Planning +**6.1 Actions to address risks and opportunities** +- Based on context (4.1) and interested party requirements (4.2), determine risks and opportunities: + - That give assurance the BCMS achieves intended results + - That prevent or reduce undesired effects + - That achieve improvement +- Plan actions to address these risks and opportunities +- Integrate and implement into BCMS processes +- Evaluate effectiveness of actions + +**6.2 Business continuity objectives and plans to achieve them** +- Establish BC objectives at relevant functions and levels +- Objectives must be: + - Consistent with BC policy + - Measurable (where practicable) + - Based on applicable requirements + - Monitored, communicated, and updated +- Plans to achieve objectives must state: what will be done, required resources, who is responsible, completion timeframe, evaluation method +- **Mandatory documented output**: BC objectives and plans + +--- + +### Clause 7 — Support +**7.1 Resources** +- Determine and provide resources needed to establish, implement, maintain, and continually improve BCMS + +**7.2 Competence** +- Determine necessary competence for persons doing work affecting BCMS performance +- Ensure persons are competent based on education, training, or experience +- Where applicable, take actions to acquire competence (training, hiring, contractors) +- **Mandatory documented output**: Evidence of competence (records) + +**7.3 Awareness** +Persons under the organisation's control must be aware of: +- BC policy +- Their contribution to BCMS effectiveness and benefits of improved performance +- Implications of not conforming to BCMS requirements + +**7.4 Communication** +Determine needed communications (internal and external) relevant to BCMS: +- What to communicate +- When to communicate +- With whom to communicate +- Who communicates +- How to communicate + +**7.5 Documented information** +BCMS must include documented information required by the standard and that determined necessary by the organisation. Controls must be applied: creation and updating (format, media, review, approval), and control of documented information (availability, protection, distribution, storage, retention, disposition). + +--- + +### Clause 8 — Operation +This is the operational core of ISO 22301. + +**8.1 Operational planning and control** +- Plan, implement, control, maintain, and review processes to meet requirements and implement actions from Clause 6 +- Control planned changes and review consequences of unintended changes +- Ensure outsourced processes are controlled +- **Mandatory documented output**: Evidence that processes carried out as planned + +**8.2 Business impact analysis and risk assessment** +- Establishes, implements, and maintains a formal and documented process for BIA and risk assessment +- Process must be integrated into overall risk management approach and aligned with scope + +**8.2.2 Business impact analysis (BIA)** +The BIA establishes the foundation for all BCMS strategies and plans. Required outputs: +- Identification of activities supporting delivery of in-scope products and services +- Assessment of impacts over time if those activities are disrupted (financial, operational, regulatory, reputational, legal) +- Identification of **Maximum Tolerable Period of Disruption (MTPD)** — time limit beyond which impacts become unacceptable +- Identification of **Minimum Business Continuity Objective (MBCO)** — minimum level of service acceptable during disruption +- Identification of **Recovery Time Objective (RTO)** — must be less than MTPD +- Identification of **Recovery Point Objective (RPO)** — maximum tolerable data loss +- Identification of dependencies: people, information, technology, premises, suppliers, partners +- Prioritisation of activities for recovery +- **Mandatory documented output**: BIA results + +**8.2.3 Risk assessment** +- Identify risks of disruption to the organisation's activities, infrastructure, and supply chain +- Analyse identified risks (probability and impact) +- Evaluate risks against defined risk criteria +- Produce documented risk assessment output +- Review and update regularly and when significant changes occur +- **Mandatory documented output**: Risk assessment results + +**8.3 Business continuity strategy and solutions** +**8.3.1 General** +- Determine appropriate strategies and solutions based on BIA outputs and risk assessment results +- Strategies must address the prioritised activities, their dependencies, and recovery timeframes + +**8.3.2 Identification of strategies and solutions** +Consider options for addressing continuity of activities and recovery: +- **People**: alternative work locations, remote working, mutual aid, cross-training, temporary staff +- **Premises**: alternate sites, work-from-home, mobile facilities, reciprocal arrangements +- **Technology**: redundant infrastructure, cloud failover, hot/warm/cold backup sites, data replication +- **Information**: backups, offsite storage, document management, paper alternatives +- **Supply chain**: alternative suppliers, pre-qualification, inventory buffers, dual sourcing +- **Finance**: emergency funds, lines of credit, insurance, pre-arranged contracts + +**8.3.3 Selection of strategies and solutions** +- Select appropriate combination of strategies and solutions +- Consider balance of: cost, capability to achieve RTO/RPO/MBCO, organisational risk appetite +- Document justification for selected strategies and exclusions + +**8.3.4 Resource requirements** +Identify resources to implement selected strategies: +- People (roles, numbers, skills) +- Information and data +- Buildings, facilities, work environment +- Technology and equipment +- Transportation +- Finance +- Partners and suppliers +- **Mandatory documented output**: Resource requirements + +**8.3.5 Protection and mitigation** +- Consider proportionate risk treatment measures to protect critical activities prior to a disruption +- Examples: physical security enhancements, redundant infrastructure, insurance, contractual protections + +**8.4 Business continuity plans and procedures** +**8.4.1 General** +- Implement BC strategies through business continuity plans and procedures +- Plans must be documented, approved, and subject to control + +**8.4.2 Incident response structure** +Establish procedures to manage an incident from detection through to recovery: +- Guidance on activation criteria (what triggers activation) +- Immediate priorities (life safety, critical operations, communication) +- Roles and accountabilities of the crisis management team +- Communication procedures for internal audiences +- Liaison with external parties (emergency services, regulators, media) +- Escalation and de-escalation criteria + +**8.4.3 Warning and communication** +Plans must address: +- Internal communication procedures during incidents +- Communication with customers, partners, and stakeholders +- Procedures for media and public communication +- Communication with authorities (regulatory, emergency services) +- Communication methods when primary channels fail + +**8.4.4 Business continuity plans** +Each plan must include, as a minimum: +- Conditions for activation +- Resources required to execute the plan +- Procedures for short-term and long-term response +- Roles and responsibilities (named individuals and backups) +- Communication requirements +- Information and data requirements +- Inter-dependencies and hand-offs between plans +- How normal operations will be restored (link to recovery) + +**8.4.5 Recovery** +Establish procedures to recover activities to normal levels: +- Assessment of damage and impact +- Identification of resources needed for recovery +- Roles and responsibilities during recovery phase +- Coordination with internal and external parties +- Decision criteria for returning to normal operations +- Post-incident review requirements + +**8.5 Exercising and testing the BCMS** +**8.5.1 General** +- Organisation conducts exercises and tests to validate BC strategies, solutions, and plans +- Must have documented exercise programme with objectives, scenarios, and success criteria +- Results must be reviewed and improvements identified +- **Mandatory documented output**: Exercise programme, exercise results + +**Exercise types (by escalating complexity/realism):** +| Type | Description | Risk | Duration | +|------|-------------|------|----------| +| Tabletop / Discussion-based | Facilitated walkthrough of scenario, no live activation | Low | Hours | +| Walkthrough | Team reviews plans step-by-step without simulating actions | Low | Hours | +| Functional / Component test | Tests specific functions (IT failover, comms systems) | Medium | Hours–Days | +| Simulation | Full scenario simulation without actual invocation | Medium | Half-day to full day | +| Live / Full interruption | Actual activation of continuity arrangements | High | Days | + +**8.5.2 Testing** +- Validate technical recovery solutions: IT failover times, backup restoration, alternate site connectivity +- Confirm that technical solutions meet stated RTO and RPO +- Document test results and correct failures + +**8.6 Evaluation and updating pre- and post-incident** +- Following an exercise, test, or actual incident: review the effectiveness of BC strategy and plans +- Identify improvements and update plans, strategies, and risk assessments as appropriate +- Document the review and resultant changes + +--- + +### Clause 9 — Performance Evaluation + +**9.1 Monitoring, measurement, analysis and evaluation** +- Determine what needs to be monitored and measured regarding BCMS performance +- Determine methods, timing, and frequency +- Establish who analyses and evaluates results +- Retain documented evidence of results +- **Commonly tracked KPIs**: RTO achievement rate in tests, BIA coverage percentage, plan currency (% reviewed within cycle), staff awareness rate, exercise completion rate, corrective action close-out rate + +**9.2 Internal audit** +- Organisation conducts internal audits at planned intervals to assess whether BCMS: + - Conforms to requirements of the standard and to own documented requirements + - Is effectively implemented and maintained +- Audit programme must consider: importance of in-scope processes, results of previous audits +- Auditors must be selected to ensure objectivity and impartiality of the process +- Results must be reported to relevant management +- **Mandatory documented output**: Audit programme, audit results + +**9.3 Management review** +- Top management reviews BCMS at planned intervals +- Inputs must include: + - Status of actions from previous reviews + - Changes in external/internal issues relevant to BCMS + - BC performance information including trends in nonconformities, corrective actions, monitoring and measurement results, audit results + - Adequacy of resources + - Effectiveness of actions to address risks and opportunities + - Opportunities for continual improvement +- Outputs must include decisions and actions on improvement opportunities and changes to BCMS +- **Mandatory documented output**: Management review minutes/record + +--- + +### Clause 10 — Improvement + +**10.1 Nonconformity and corrective action** +When a nonconformity occurs: +1. React to nonconformity and take action to control and correct it +2. Evaluate need for action to eliminate root cause (so nonconformity does not recur) +3. Implement corrective action required +4. Review effectiveness of corrective action taken +5. Make changes to BCMS if necessary +- Evidence of the nature of nonconformities and subsequent actions is a mandatory retained record + +**10.2 Continual improvement** +- Continually improve the suitability, adequacy, and effectiveness of the BCMS +- Consider opportunities identified through monitoring, audits, management review, exercises, and incidents + +--- + +## Core Workflows + +### 1. Gap Analysis + +When asked to perform or help with a gap analysis: +1. Confirm: Is this against ISO 22301:2019 (current) or 2012? +2. Confirm which sites/functions are in scope +3. Produce a table covering ALL clause requirements from 4.1 through 10.2 +4. For each item: **Status** (Implemented / Partial / Not Implemented / N/A), **Evidence Needed**, **Gap Notes** +5. Summarise critical gaps and recommended priority order +6. Offer to produce a remediation roadmap + +**Status definitions:** +- Implemented — requirement is fully met with documented evidence +- Partial — partially addressed but gaps in documentation, coverage, or effectiveness remain +- Not Implemented — no evidence of implementation +- N/A — documented and justified exclusion (rare under 22301 as most clauses are mandatory) + +**Typical gap analysis output format:** + +``` +CLAUSE | REQUIREMENT | STATUS | EVIDENCE NEEDED | GAP / NOTES +4.3 | BCMS scope statement documented | Partial | Scope document | Draft exists but does not define all sites +5.2 | BC policy signed by top management | Not Implemented | Signed policy | Policy draft unsigned, not communicated +8.2.2 | BIA completed for all in-scope activities | Not Implemented | BIA records | No formal BIA exists +8.4.4 | BC plans documented per clause requirements | Not Implemented | BCP documents | No plans exist +8.5 | Exercise programme documented | Not Implemented | Exercise schedule and records | No exercises conducted +``` + +### 2. Business Impact Analysis (BIA) + +When conducting or assisting with a BIA: + +**Step 1 — Identify activities** +- List all activities that support delivery of in-scope products and services +- Group by function/department if appropriate + +**Step 2 — Assess impacts over time** +For each activity, assess cumulative impact across time horizons (e.g., <4 hours, 4–8 hours, 1 day, 3 days, 1 week, 2 weeks, 1 month): +- Financial: revenue loss, contractual penalties, additional costs +- Operational: inability to serve customers, internal failures +- Regulatory: breach of legal/regulatory timeframes +- Reputational: damage to brand or stakeholder confidence +- Legal: contractual breach, litigation risk + +**Step 3 — Determine recovery parameters** +For each activity, establish: +- **MTPD**: longest time activity can be disrupted before impacts become unacceptable +- **RTO**: target time to resume activity (must be ≤ MTPD) +- **RPO**: maximum tolerable data loss expressed as a point in time +- **MBCO**: minimum acceptable level of service at resumption +- **RLO** (where applicable): target activity/output level at recovery point + +**Step 4 — Identify dependencies** +For each activity, identify: +- People: roles, minimum numbers required, skills +- Information and data: systems, applications, databases, paper records +- Technology: IT infrastructure, communications, OT systems +- Premises: offices, facilities, specialist areas +- Suppliers and partners: critical third parties, utilities + +**Step 5 — Prioritise activities** +Rank by impact severity and recovery urgency to drive strategy selection. + +**BIA output table format:** + +| Activity | Owner | MTPD | RTO | RPO | MBCO | Key Dependencies | Priority | +|----------|-------|------|-----|-----|------|-----------------|----------| +| Order processing | Sales Dir | 24 hrs | 8 hrs | 4 hrs | 50% capacity | ERP system, customer DB, 5 staff | Critical | +| Finance reporting | CFO | 5 days | 3 days | 1 day | Monthly reports | Finance system, 2 staff | High | + +### 3. Risk Assessment + +When conducting or assisting with a risk assessment (Clause 8.2.3): + +**Standard approach: Likelihood × Impact** + +1. Define risk criteria aligned to the organisation's risk appetite +2. Identify disruption scenarios relevant to in-scope activities: + - Physical: fire, flood, extreme weather, building damage + - Technology: IT/OT failure, ransomware, communications outage + - People: pandemic, key-person dependency, industrial action + - Utilities: power outage, water failure, telecommunications failure + - Supply chain: critical supplier failure, logistics disruption + - External: regulatory change, geopolitical event, civil unrest +3. Analyse each scenario: + - Likelihood: scale 1–5 (Rare to Almost Certain) + - Impact: scale 1–5 (Negligible to Catastrophic) + - Risk Score: Likelihood × Impact (1–25) +4. Evaluate against risk criteria: Accept / Treat / Transfer / Avoid +5. Link risk assessment outputs to BIA and BC strategy + +**Risk register format:** + +| Scenario | Likelihood (1-5) | Impact (1-5) | Score | Treatment | Controls/Strategy | Owner | Review Date | +|----------|-----------------|--------------|-------|-----------|------------------|-------|-------------| +| Ransomware attack on ERP | 4 | 5 | 20 | Treat | Offsite backup, DR site, IR plan | CISO | Quarterly | +| Key data centre power failure | 2 | 5 | 10 | Treat | UPS, generator, cloud failover | IT Dir | Annual | + +### 4. BC Strategy and Solutions + +When helping with BC strategy (Clause 8.3): + +For each prioritised activity (from BIA), document strategy options: + +``` +ACTIVITY: Order Processing (RTO: 8 hours, RPO: 4 hours) + +Strategy Options Considered: +1. Hot standby DR site — full IT replication, immediate failover + Cost: High | Meets RTO: Yes | Meets RPO: Yes +2. Warm standby cloud environment — 4-hour spin-up + Cost: Medium | Meets RTO: Yes (marginal) | Meets RPO: Yes +3. Manual paper-based workaround — no IT dependency + Cost: Low | Meets RTO: Yes (partial) | Meets RPO: N/A + +Selected Strategy: Warm standby cloud + manual fallback +Justification: Cost-proportionate; meets RTO of 8 hours; paper fallback provides +immediate short-term capacity while cloud environment is activated. +``` + +### 5. Business Continuity Plan (BCP) Authoring + +When generating a BCP document, structure as follows: + +``` +BUSINESS CONTINUITY PLAN: [Activity/Function/Site Name] + +Document Control + Version: [x.x] + Owner: [Role] + Approved by: [Role/Name] + Last reviewed: [Date] + Next review: [Date] + Classification: [e.g. Confidential] + +1. Purpose and Scope + - What this plan covers + - Where it applies + - Products/services maintained during invocation + +2. Activation + - Conditions and criteria that trigger this plan + - Who authorises activation + - Escalation path if normal contacts unavailable + +3. Roles and Responsibilities + - Incident Commander + - BC Team members with contact details + - Alternates/deputies for each role + - External contacts (IT support, facilities, insurer) + +4. Immediate Actions (First 2 hours) + - Step-by-step immediate response actions + - Who does what + - Communication cascade + +5. Business Continuity Procedures + - Procedures to maintain minimum service level (MBCO) + - IT recovery steps (or reference to IT DR plan) + - People management: alternate working, remote access, temporary staff + - Premises: alternate site address, access arrangements + +6. Communication + - Internal communication plan + - Customer and stakeholder communication + - Media/public statement (if applicable) + - Regulatory notification requirements + +7. Recovery + - Decision criteria for returning to normal operations + - Recovery sequence and steps + - Sign-off process for return to normal + +8. Supporting Information + - Contact lists (internal, external, authorities) + - Vendor and supplier contacts + - Location of vital records + - Insurance policy details + - References to linked plans + +9. Appendices + - Site/floor plans + - System access instructions + - Pre-positioned resource lists +``` + +### 6. Exercise Planning + +When helping plan a BC exercise (Clause 8.5): + +**Exercise Programme Structure:** +- Set annual exercise objectives covering all critical plans over a 1–3 year cycle +- Mix exercise types: at minimum one tabletop plus one functional/technical test per year +- Full-invocation exercises are best practice every 2–3 years or after major changes + +**Individual Exercise Plan Template:** + +``` +EXERCISE PLAN + +Exercise Name: [Name] +Date/Time: [Date and Time] +Duration: [Expected duration] +Exercise Type: Tabletop / Walkthrough / Functional / Simulation / Live +Facilitator: [Name and role] +Participants: [Roles/teams involved] + +Objectives: +1. Validate activation procedures work as documented +2. Test communication cascade (internal and external) +3. Confirm alternate site connectivity is achievable within RTO +[etc.] + +Scenario: +[Injects and scenario narrative — must be realistic but proportionate to exercise type] + +Success Criteria: +- Crisis management team mobilised within [X] minutes of alert +- Key stakeholders notified within [Y] minutes +- Critical system accessible at alternate site within [Z] hours + +Out of Scope: +[What will NOT be tested — this sets boundaries for participants] + +Debrief and Reporting: +- Hot debrief immediately after exercise +- Formal report issued within [X] weeks +- Action log owner: [Name] +``` + +### 7. Certification Readiness Assessment + +When asked about certification readiness (Stage 1 or Stage 2 audit): + +**Stage 1 (Documentation Review) — Readiness Checklist:** + +| Item | Clause | Required? | Status | +|------|--------|-----------|--------| +| BCMS scope statement | 4.3 | Mandatory | | +| Business continuity policy (signed) | 5.2 | Mandatory | | +| BC objectives and plans to achieve them | 6.2 | Mandatory | | +| Evidence of competence | 7.2 | Mandatory | | +| BIA results (documented) | 8.2.2 | Mandatory | | +| Risk assessment results | 8.2.3 | Mandatory | | +| BC strategies and solutions (documented) | 8.3 | Mandatory | | +| Resource requirements documented | 8.3.4 | Mandatory | | +| Incident response structure/plan | 8.4.2 | Mandatory | | +| Communication procedures | 8.4.3 | Mandatory | | +| Business continuity plans | 8.4.4 | Mandatory | | +| Recovery procedures | 8.4.5 | Mandatory | | +| Exercise programme (documented) | 8.5 | Mandatory | | +| Exercise records | 8.5 | Mandatory | | +| Internal audit programme | 9.2 | Mandatory | | +| Internal audit results | 9.2 | Mandatory | | +| Management review minutes | 9.3 | Mandatory | | +| Nonconformity and corrective action records | 10.1 | Mandatory | | + +**Stage 2 (Effectiveness Audit) — Key Evidence Auditors Examine:** +- BCMS is actively implemented and reviewed (not shelf-ware) +- BIA results drive strategy decisions (demonstrate the link) +- Plans are known and accessible to the response team +- Exercises have been conducted with documented results and follow-up actions +- Management review has occurred with documented inputs and outputs +- Internal audit was conducted by competent, independent auditor +- Nonconformities are tracked and resolved + +--- + +## Key Terminology Reference + +| Term | ISO 22301:2019 Definition | +|------|--------------------------| +| BCMS | Business continuity management system — management system to establish, implement, operate, monitor, review, maintain, and improve continuity capabilities | +| BIA | Business impact analysis — process of analysing activities and the effect that a disruption might have upon them | +| MTPD | Maximum tolerable period of disruption — time after which impacts of not delivering a product/service become unacceptable | +| RTO | Recovery time objective — period within which a product/service or activity must be resumed | +| RPO | Recovery point objective — point to which information used by an activity must be restored to enable acceptable operation; measure of maximum tolerable data loss | +| MBCO | Minimum business continuity objective — minimum level of services and/or products acceptable during a disruption | +| RLO | Recovery level objective — minimum level at which an activity must be resumed within the RTO | +| Disruption | Incident causing an unplanned negative deviation from expected delivery of products/services | +| Incident | Situation that might be, or could lead to, a disruption, loss, emergency, or crisis | +| Crisis management | Holistic management process that identifies potential threats and impacts to an organisation's operations | +| BC strategy | Approach by an organisation to ensure recovery or continuity of business activities | + +--- + +## Policy and Document Templates + +When generating policies, always include: +- **Document control block**: Version | Author | Approved By | Date | Next Review +- **Scope**: explicit statement of who/what is covered +- **Policy statement**: statement of intent +- **Roles and responsibilities**: named roles (not individuals) +- **Review cycle**: typically annual or after a significant incident +- **References**: link to related documents, standards, legal requirements +- Map each policy to the relevant ISO 22301:2019 clause + +**Common policy/document types:** + +| Document | Primary Clause | Notes | +|----------|---------------|-------| +| BCMS Scope Statement | 4.3 | Boundary definition; mandatory | +| Business Continuity Policy | 5.2 | Top management signed; mandatory | +| BC Roles and Responsibilities | 5.3 | RACI matrix or role descriptions | +| BC Objectives | 6.2 | Measurable, time-bound | +| Competence Framework | 7.2 | Training matrix | +| Communication Plan | 7.4 | Internal/external contacts and procedures | +| BIA Methodology | 8.2.2 | How BIA is conducted | +| Risk Assessment Methodology | 8.2.3 | Criteria, scales, process | +| BC Strategy Document | 8.3 | Selected strategies and justifications | +| Incident Response Plan | 8.4.2 | Activation, crisis team, escalation | +| Business Continuity Plans | 8.4.4 | Per activity or function | +| Exercise Programme | 8.5 | Annual schedule | +| Monitoring and Measurement Plan | 9.1 | KPIs and reporting | +| Internal Audit Plan | 9.2 | Schedule, scope, methods | +| Management Review Agenda/Minutes | 9.3 | Inputs, outputs, decisions | +| Nonconformity Register | 10.1 | NC log; corrective action tracking | + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +- `references/iso22301-clauses.md` — Full clause-by-clause requirements breakdown with mandatory document list +- `references/iso22301-bia-guide.md` — Detailed BIA methodology, impact categories, time horizon matrix, dependency mapping +- `references/iso22301-bcps.md` — BC plan structure guidance, incident response templates, communication templates, recovery checklists +- `references/iso22301-templates.md` — Ready-to-use templates: BC policy, BIA form, risk register, exercise plan, management review template + +**When to load reference files:** +- Conducting BIA or explaining BIA methodology → load `iso22301-bia-guide.md` +- Drafting or reviewing a BCP, IRP, or recovery procedure → load `iso22301-bcps.md` +- Generating policies, forms, or templates → load `iso22301-templates.md` +- Detailed clause questions or gap analysis → load `iso22301-clauses.md` +- General questions → answer from skill knowledge, load reference if more detail needed diff --git a/plugins/iso22301/skills/iso22301/references/iso22301-bcps.md b/plugins/iso22301/skills/iso22301/references/iso22301-bcps.md new file mode 100644 index 0000000..9f1b8f2 --- /dev/null +++ b/plugins/iso22301/skills/iso22301/references/iso22301-bcps.md @@ -0,0 +1,484 @@ +# ISO 22301:2019 — Business Continuity Plans and Procedures Reference + +## Purpose + +This reference provides detailed guidance on the structure, content, and maintenance of Business +Continuity Plans (BCPs), Incident Response Plans, communication procedures, and recovery +procedures required under ISO 22301:2019 Clauses 8.4.1 through 8.4.5. + +--- + +## Plan Architecture + +Under ISO 22301:2019, an organisation's suite of BC plans forms a hierarchy. Each plan serves +a distinct purpose and must interlock with the others: + +``` +INCIDENT RESPONSE PLAN (IRP) + Purpose: Detect, declare, and manage the overall incident; mobilise the BC response + Clause: 8.4.2 + Owner: Crisis Management Team / Incident Commander + | + v +BUSINESS CONTINUITY PLANS (BCPs) + Purpose: Maintain minimum service levels for critical activities during the disruption + Clause: 8.4.4 + Owner: Function/Department leads (per BIA priority) + | + v +RECOVERY PLANS + Purpose: Restore activities to normal operating levels + Clause: 8.4.5 + Owner: Function/Department leads + IT Recovery Lead + | + v +IT DISASTER RECOVERY PLAN (IT DRP) + Purpose: Technical recovery of IT systems and infrastructure + Clause: 8.3.2 (strategy) + 8.4.4 (plan), 8.5.2 (testing) + Owner: IT Director / IT Recovery Lead +``` + +Plans are activated in sequence (IRP → BCP + IT DRP → Recovery Plan) though activation +of individual BCPs may occur in parallel depending on the nature of the incident. + +--- + +## Clause 8.4.2 — Incident Response Plan (IRP) + +### Purpose +The IRP defines how the organisation detects, declares, and manages a disruptive incident +from the first moment of awareness through to activation of BC plans and eventual stand-down. + +### Minimum IRP Content (per ISO 22301:2019 Clause 8.4.2) + +**1. Activation Criteria** +Define the specific conditions that constitute a "declarable incident" for the organisation. +Activation criteria prevent over-escalation (treating minor issues as incidents) and +under-escalation (allowing major disruptions to proceed without invoking plans). + +| Severity Level | Threshold | Response Level | +|----------------|-----------|----------------| +| Level 1 — Incident | Single system unavailability; <10 staff affected; <1 hour expected duration | IT support + line manager; no BCP activation | +| Level 2 — Disruption | Multiple systems down; >10 staff affected; 1–4 hours expected; no customer impact | Department head + IT; monitoring mode; BCP on standby | +| Level 3 — Major Disruption | Critical system unavailability; customer impact likely; >4 hours expected | Crisis Management Team convened; BCPs pre-positioned | +| Level 4 — Crisis | Site loss; major data breach; life-safety event; regulatory exposure | Full BCP activation; Board notification; external communications | + +**2. Notification and Mobilisation** + +Define the cascade: +- Who is notified first (typically: IT on-call → BC Manager → Incident Commander) +- How confirmation of mobilisation is obtained +- What channel to use if primary channels are unavailable +- Contact details (personal mobile, home phone, emergency SMS service) + +**3. Crisis Management Team (CMT) Structure** + +| Role | Responsibilities During Incident | Primary Contact | Alternate | +|------|-----------------------------------|----------------|-----------| +| Incident Commander | Overall incident control; escalation decisions; authorise external communications | [Name/Role] | [Alternate] | +| BC Manager / Coordinator | Activating BCPs; tracking recovery actions; status reporting | [Name/Role] | [Alternate] | +| IT Recovery Lead | Technical recovery decisions; DR activation; vendor liaison | [Name/Role] | [Alternate] | +| Communications Lead | Internal communications; customer notifications; media statements | [Name/Role] | [Alternate] | +| HR Lead | Staff welfare; remote working arrangements; emergency staffing | [Name/Role] | [Alternate] | +| Finance Lead | Emergency expenditure authorisation; insurer notification | [Name/Role] | [Alternate] | +| Legal/Compliance Lead | Regulatory notifications; contractual obligations; legal advice | [Name/Role] | [Alternate] | +| Premises/Facilities Lead | Building access; alternate sites; health and safety | [Name/Role] | [Alternate] | + +**4. CMT Meeting Protocol** + +- Initial convening: within [X] minutes of Level 3/4 declaration +- Location: CMT room (primary) / virtual bridge (alternate) +- Meeting frequency during incident: every [X] hours; daily at [time] for extended incidents +- Standard agenda: situation update → current actions → new risks → decisions required → assignments +- Action log maintained in real time + +**5. Immediate Priorities (First 2 Hours)** + +Regardless of incident type, these priorities apply in order: +1. **Life safety**: Ensure the safety of all people in affected locations +2. **Damage containment**: Prevent incident from spreading or worsening +3. **Crisis team mobilisation**: Convene CMT; establish communications +4. **Situational assessment**: Understand scope, cause, expected duration +5. **Stakeholder notification**: Internal notifications per cascade; customers on standby +6. **BCP activation decision**: Invoke relevant BCPs; brief plan owners + +**6. Escalation and De-escalation Criteria** + +*Escalation*: Criteria for moving from Level 2 to Level 3 or Level 3 to Level 4 (e.g., +incident duration exceeds 4 hours; customer impact confirmed; regulatory threshold triggered). + +*De-escalation and stand-down*: Criteria for reducing alert level and standing down BCPs: +- Critical systems restored and validated +- All customer SLAs recoverable within acceptable timeframes +- Legal/regulatory exposures managed +- No further risk of re-escalation +- Formal sign-off by Incident Commander + +--- + +## Clause 8.4.3 — Communication Procedures + +### Communication Plan During Incidents + +**Internal communication cascade:** + +| Audience | Timing | Channel | Message Content | Owner | +|----------|--------|---------|----------------|-------| +| CMT members | Immediate | Personal mobile / emergency SMS | Incident declared; convene at [location/bridge] | BC Manager | +| Department heads not on CMT | Within 30 min | Mobile / email | Situation summary; instructions for their teams | Incident Commander | +| All staff | Within 60 min | All-staff email + intranet notice | What has happened; what staff should do; further updates promised by [time] | Communications Lead | +| Remote/home workers | Within 60 min | Email + messaging platform | Actions required; how to access systems/work | HR Lead | +| Board / Executive | Within 2 hours (Level 4) | Direct call or CMT briefing | Situation, response, risk, escalation | Incident Commander | + +**External communication procedures:** + +| Audience | Trigger | Timing | Channel | Template | Owner | +|----------|---------|--------|---------|----------|-------| +| Customers (proactive) | Service impact confirmed | Within 2 hours | Email + portal notice + account manager calls | Customer communication template | Communications Lead | +| Customers (reactive) | Customer enquiry received | Immediate | Phone / email | Holding message template | Customer service + Communications Lead | +| Regulators | Notifiable incident threshold met | Per regulatory requirement (e.g., 72 hours for data breach) | Formal notification to regulator | Regulatory notification template | Legal/Compliance Lead | +| Insurers | Potential claim event | Within 24 hours | Direct contact with broker | Incident notification | Finance Lead | +| Media | Media enquiry received | As required | Press statement (no comment until approved) | Media holding statement | Communications Lead + Incident Commander | +| Social media | Significant public-facing impact | As required | Official channels only | Pre-approved statements only | Communications Lead | + +### Communication Templates + +**All-staff notification — initial:** +``` +Subject: [INCIDENT NOTIFICATION] Business disruption — [Date] + +To all staff, + +You should be aware that we are currently experiencing [brief description of incident]. + +What this means for you: +[Specific instructions — e.g., "Please work from home today" / "Do not access the X system"] + +Our business continuity procedures have been activated. You will receive an update by [time]. + +If you have urgent queries, please contact [name/role] via [channel]. + +[Signed by Incident Commander or designated leader] +``` + +**Customer communication — service disruption:** +``` +Subject: Service update — [date] + +Dear [Name], + +We are writing to inform you that we are experiencing a technical disruption affecting +[specific services]. We expect this to be resolved by [estimated time / "we will update +you within X hours"]. + +[Description of impact on customer and any interim arrangements] + +We apologise for any inconvenience caused and appreciate your patience. + +We will keep you updated at [interval/channel]. If you have an urgent requirement, +please contact [contact name/number]. + +[Signed by Communications Lead / Account Manager] +``` + +**Media holding statement:** +``` +[ORGANISATION NAME] is aware of an incident affecting its operations. Our teams are +working to restore normal service as quickly as possible. We are committed to keeping +our customers and stakeholders informed. + +We will provide a further statement at [time / date]. + +For media enquiries, please contact: [Communications Lead, phone number]. +``` + +--- + +## Clause 8.4.4 — Business Continuity Plan (BCP) Template + +### BCP Document Structure + +The following structure satisfies ISO 22301:2019 Clause 8.4.4 requirements for all BCPs. +Each plan covers a specific function, department, or critical activity. + +--- + +**DOCUMENT CONTROL** + +| Field | Value | +|-------|-------| +| Plan Title | Business Continuity Plan — [Function/Department/Site] | +| Plan Reference | BCP-[code] | +| Version | [x.x] | +| Status | Active / Draft / Under Review | +| Plan Owner | [Role, not individual name] | +| Approved by | [Role — must be appropriate level for plan's criticality] | +| Date of Issue | [Date] | +| Next Review Date | [Date — maximum 12 months from issue] | +| Classification | [e.g., Confidential — BCM Team Only] | +| Last Exercise Date | [Date] | +| Copy Location | [Primary: document management system] [Backup: hardcopy location] | + +**Change Record** + +| Version | Date | Author | Summary of Changes | +|---------|------|--------|--------------------| +| 1.0 | [Date] | [Name] | Initial issue | +| 1.1 | [Date] | [Name] | [Description] | + +--- + +**1. PURPOSE AND SCOPE** + +This plan provides the procedures to maintain [minimum service level / MBCO] for [Function/ +Department/Activity] during a business disruption, until normal operations are restored. + +**In-scope activities covered by this plan:** +- [Activity A — brief description] +- [Activity B — brief description] + +**Products/services maintained during invocation:** +- [Product/service and minimum service level during invocation] + +**Activities not covered by this plan:** +- [List lower-priority activities that will be suspended during invocation] + +**Relationship to other plans:** +- This plan is activated by the Incident Response Plan (IRP-001) +- IT recovery is covered by the IT Disaster Recovery Plan (ITDR-001) +- [Other linked plans] + +--- + +**2. ACTIVATION** + +**Conditions for activation:** +This plan is activated when one or more of the following conditions are met: +- The Incident Commander declares a Level [3/4] incident +- [System X] is unavailable for more than [Y] hours +- [Specific scenario, e.g., primary site is inaccessible] +- Directed by [role] via [channel] + +**Who activates:** +The Plan Owner (or designated alternate) activates this plan upon instruction from the Incident +Commander or the BC Manager. Plan Owner confirms activation via [channel] to the CMT. + +**If Plan Owner is unreachable:** +Contact [Alternate 1 — Role — Mobile] then [Alternate 2 — Role — Mobile]. + +--- + +**3. ROLES AND RESPONSIBILITIES** + +| Role | During-Incident Responsibility | Primary: Role/Name | Backup: Role/Name | +|------|-------------------------------|-------------------|-------------------| +| Plan Owner | Activating plan; briefing team; reporting to CMT; escalating issues | [Role] | [Role] | +| Operations Lead | Executing continuity procedures; managing output; tracking backlog | [Role] | [Role] | +| Technology Lead | IT liaison; alternative access setup; data recovery co-ordination | [Role] | [Role] | +| Staff Coordinator | Managing team attendance; remote working arrangements | [Role] | [Role] | + +**Contact details** (store in secure, accessible location outside this document to allow update without re-versioning): +Reference contact directory: [location/system] + +--- + +**4. IMMEDIATE ACTIONS (FIRST 2 HOURS)** + +Upon activation, the Plan Owner executes the following steps in order: + +| Step | Action | Responsibility | Time Target | +|------|--------|---------------|-------------| +| 1 | Confirm activation with Incident Commander via [channel] | Plan Owner | T+0 | +| 2 | Notify team of activation; communicate immediate instructions | Plan Owner | T+15 min | +| 3 | Assess current work status: backlog, in-progress, committed deadlines | Operations Lead | T+30 min | +| 4 | Activate IT DR plan / contact IT Recovery Lead | Technology Lead | T+15 min | +| 5 | Establish team at alternate location / confirm remote access | Staff Coordinator | T+60 min | +| 6 | Report status to CMT via [channel] | Plan Owner | T+2 hours | +| 7 | Communicate to customers/partners as directed by Communications Lead | Plan Owner | Per comms plan | + +--- + +**5. CONTINUITY PROCEDURES** + +**Activity: [Activity Name] — MBCO: [e.g., 50% of normal daily volume]** + +*Normal process description:* [Brief description of how this normally works] + +*During-disruption procedure:* +1. [Step 1 — what to do if primary system unavailable] +2. [Step 2 — what workaround to use] +3. [Step 3 — how to record work done manually if needed] +4. [Step 4 — who to escalate to if workaround fails] + +*Resources required at MBCO:* +- Staff: [minimum number and roles] +- Location: [alternate site / remote working requirements] +- Technology: [minimum systems needed; fallback if unavailable] +- Information: [key data/records needed; offline versions available at: location] + +*Minimum viable process (if technology entirely unavailable):* +[Describe paper / manual fallback if IT systems are completely unavailable] + +--- + +**6. COMMUNICATION** + +**Updates to CMT:** +- Frequency: Every [2/4/8] hours via [channel: status report / call / dashboard] +- Update content: current backlog, actions completed, issues, resource needs + +**Communication to customers:** +Per communications plan (COMMS-001). This plan does not authorise independent customer +communication. All messages must be approved by Communications Lead. + +**Communication to staff:** +Plan Owner communicates with team via [channel] at [frequency] to maintain situational +awareness and morale during prolonged invocations. + +--- + +**7. RECOVERY** + +The recovery phase begins when normal systems and services are restored and operational. + +**Conditions to begin recovery:** +- IT Recovery Lead confirms [specific systems] are restored and validated +- Incident Commander authorises transition to recovery mode +- [Any other conditions, e.g., building access restored, supplier confirmed available] + +**Recovery steps:** +| Step | Action | Responsibility | +|------|--------|---------------| +| 1 | Validate data integrity of restored systems before using in live operations | Technology Lead | +| 2 | Assess backlog accumulated during incident; prioritise clearing | Operations Lead | +| 3 | Communicate resumption of normal service to customers | Communications Lead | +| 4 | Manage staff transition from remote/alternate to normal locations | Staff Coordinator | +| 5 | Restore all archived/manual records to systems | Operations Lead | +| 6 | Confirm to CMT that normal operations fully restored | Plan Owner | +| 7 | Complete post-incident review within [X] days | Plan Owner | + +**Post-incident review:** +Within [X] days of stand-down, Plan Owner submits an after-action report covering: +- What went well +- What did not work as expected +- Recommended plan updates +- Corrective actions required + +Submit report to BC Manager for inclusion in BCMS nonconformity and improvement process. + +--- + +**8. SUPPORTING INFORMATION** + +**Alternate work location:** +Primary alternate site: [Name, address, contact] +Access: [How to access: key, swipe card, temporary pass — contact Facilities Lead] +IT connectivity: [VPN access; on-site workstations available: yes/no; number] +Capacity: [maximum concurrent users] + +**Vital records location:** +| Record | Normal Location | Emergency Copy Location | +|--------|----------------|------------------------| +| Customer contracts | CRM system | [Backup: cloud archive] | +| Supplier contact list | Shared drive | [Backup: printed list, Facilities office] | +| Payroll data | HR system | [Backup: monthly extract, secure offsite] | + +**Key vendor and supplier contacts:** +Reference supplier contact directory: [location/system] + +**Insurance:** +Business interruption policy: [Policy number / broker contact] +Cyber insurance: [Policy number / broker contact if applicable] + +--- + +**9. PLAN MAINTENANCE** + +This plan shall be reviewed: +- Annually as part of the BCMS review cycle +- Following any invocation +- Following any significant exercise +- When organisational structure, systems, or processes change materially + +Plan owner is responsible for initiating the review and obtaining re-approval. All changes +must be recorded in the change record and communicated to all holders. + +--- + +## Clause 8.4.5 — Recovery Plan Considerations + +The recovery phase is distinct from the continuity phase. While the BCP maintains minimum +service (MBCO), the recovery plan restores normal operations. + +### Key Recovery Activities + +**Damage assessment:** +- Physical damage: structures, equipment, inventory +- Data integrity: what data is confirmed intact, what requires restoration, what is lost +- System status: what is online, what requires recovery, estimated time to full restoration +- Staff: welfare status, ability to return to normal locations/roles + +**Recovery sequencing:** +Recovery activities must follow BIA priority order — Critical activities first, then High, +Medium, Low. Never attempt to recover everything simultaneously if resources are constrained. + +**Data restoration validation:** +Before using restored data in live operations: +- Confirm backup integrity (test restore completed successfully) +- Reconcile record counts against last known good state +- Validate key transactions were captured +- Sign-off from data owner before going live + +**Return-to-normal decision:** +Incident Commander authorises return to normal following confirmation from each function head +that they have validated their systems and data. Do not return to normal until all critical +functions have confirmed readiness. + +**Post-incident review (all incidents):** +All invocations of BCPs must be followed by a post-incident review, regardless of duration. +Review covers: what happened, what worked, what failed, what must change. Outputs fed into +BCMS nonconformity process (Clause 10.1) and improvement process (Clause 10.2). + +--- + +## IT Disaster Recovery Plan (IT DRP) Essentials + +The IT DRP is a technical plan required to support Clause 8.3.2 (strategies — technology) +and validated under Clause 8.5.2 (testing). It sits beneath the overarching BCP suite. + +### Minimum IT DRP Content + +**1. System Inventory and Recovery Priority** + +| System | Business Owner | Criticality | RTO | RPO | Recovery Approach | +|--------|---------------|-------------|-----|-----|------------------| +| ERP (SAP) | CFO | Critical | 6 hours | 4 hours | Warm DR site — 4-hour spin-up | +| CRM | Sales Director | Critical | 8 hours | 24 hours | Cloud failover | +| HR System | HR Director | High | 24 hours | 24 hours | Restore from daily backup | +| Email/Comms | IT Director | Critical | 2 hours | 1 hour | Microsoft 365 geo-redundant | +| File shares | All | High | 8 hours | 24 hours | Restore from daily backup | + +**2. Recovery Site Details** +- DR site address and access instructions +- Hardware configuration and capacity at DR site +- Network connectivity (bandwidth, latency, VPN configuration) +- How staff access DR environment (VPN, RDP, Citrix) + +**3. Step-by-Step Recovery Procedures** +For each critical system: +- Failover sequence (order of operations) +- Commands or scripts to execute +- Validation tests to confirm system is operational +- Approvals required before going live on DR instance + +**4. Backup Schedule and Retention** + +| System | Backup Type | Frequency | Retention | Location | Restoration Time | +|--------|------------|-----------|-----------|----------|-----------------| +| ERP | Full | Weekly (Sunday 02:00) | 4 weeks | Offsite vault + cloud | Tested: 3.5 hours | +| ERP | Incremental | Daily (23:00) | 7 days | Cloud | Tested: 45 minutes | +| File shares | Incremental | Daily (00:00) | 30 days | Cloud | Tested: 2 hours | + +**5. Test Results Log** +Record of all IT DR tests: date, system tested, RTO achieved, RPO validated, issues found, +corrective actions. This feeds Clause 9.1 (monitoring) and satisfies Clause 8.5.2 (testing). diff --git a/plugins/iso22301/skills/iso22301/references/iso22301-bia-guide.md b/plugins/iso22301/skills/iso22301/references/iso22301-bia-guide.md new file mode 100644 index 0000000..9fd4e7d --- /dev/null +++ b/plugins/iso22301/skills/iso22301/references/iso22301-bia-guide.md @@ -0,0 +1,368 @@ +# ISO 22301:2019 — Business Impact Analysis (BIA) Methodology Guide + +## Purpose + +This reference provides a detailed, clause-accurate methodology for conducting a Business +Impact Analysis (BIA) under ISO 22301:2019 Clause 8.2.2. The BIA is the foundational +analytical process that determines what the organisation must protect, in what priority order, +and within what timeframes — underpinning all BC strategy, plan, and exercise decisions. + +--- + +## What the Standard Requires + +ISO 22301:2019 Clause 8.2.2 requires the organisation to: + +1. Identify activities that support delivery of in-scope products and services +2. Assess impacts over time of disruption to those activities +3. Determine Maximum Tolerable Period of Disruption (MTPD) for each activity +4. Determine Minimum Business Continuity Objective (MBCO) for each activity +5. Determine Recovery Time Objective (RTO) for each activity +6. Determine Recovery Point Objective (RPO) for data-dependent activities +7. Identify all dependencies (people, technology, premises, information, suppliers) +8. Prioritise activities for recovery based on impact and urgency + +All results must be documented and retained as mandatory documented information. + +--- + +## BIA Process Overview + +The BIA process consists of five sequential phases: + +``` +Phase 1: Scoping and preparation +Phase 2: Data collection (interviews/workshops) +Phase 3: Impact analysis and parameter determination +Phase 4: Dependency mapping +Phase 5: Prioritisation and reporting +``` + +--- + +## Phase 1: Scoping and Preparation + +### 1.1 Define BIA Scope + +Establish the boundary for the BIA aligned to the BCMS scope (Clause 4.3): +- Which products and services is the BIA covering? +- Which organisational units, sites, and functions are included? +- Are any functions explicitly excluded? If so, on what basis? + +### 1.2 Define Impact Categories + +Agree the categories of impact that will be assessed. Typical categories: + +| Category | Description | Examples of Impact Indicators | +|----------|-------------|-------------------------------| +| Financial | Revenue loss, additional costs, contractual penalties | £/$/€ per hour or day of disruption | +| Operational | Inability to deliver products/services, internal process failures | Volume of work not processed | +| Regulatory/Legal | Breach of legal obligations, regulatory non-compliance | Notifiable breaches, licence at risk | +| Reputational | Damage to brand, customer confidence, media coverage | Social media mentions, customer complaints | +| Contractual | Breach of SLAs or customer contracts | Number of contracts at risk of breach | +| Health and Safety | Risk to employees, public, or environment | Near-miss, injury, or fatality risk | + +### 1.3 Define Time Horizons + +Establish standard time points at which impacts will be assessed. Common time horizons: +- Less than 1 hour +- 1–4 hours +- 4–8 hours +- 8–24 hours +- 1–3 days +- 3–7 days +- 1–2 weeks +- 2–4 weeks +- 1–3 months + +The number and granularity of time points should match the organisation's operational profile. +Organisations with real-time critical activities (financial trading, emergency services) require +finer early granularity; organisations with daily batch-processing cycles may need fewer points. + +### 1.4 Define Impact Severity Scale + +Establish a consistent rating scale for all categories. Example 5-point scale: + +| Rating | Label | Financial Indicator | Operational Indicator | +|--------|-------|--------------------|-----------------------| +| 1 | Negligible | No financial impact | Minor inconvenience, fully recoverable | +| 2 | Minor | <1% of monthly revenue | Limited service reduction, not customer-visible | +| 3 | Moderate | 1–5% of monthly revenue | Significant service reduction, some customers affected | +| 4 | Significant | 5–15% of monthly revenue | Material service failure, multiple customers affected | +| 5 | Catastrophic | >15% of monthly revenue | Complete failure, regulatory/legal exposure, existential risk | + +Customise financial thresholds to match the organisation's scale. + +### 1.5 Appoint BIA Facilitator and Assign Process Owners + +- Assign a BIA Facilitator (typically the BCMS Manager) +- Identify process owners or senior representatives for each function in scope +- Schedule interviews or workshops + +--- + +## Phase 2: Data Collection + +### 2.1 BIA Interview / Workshop Approach + +The BIA is most effective when conducted through structured interviews or workshops with +process owners who understand the operational realities of each function. + +**Preparation for each session:** +- Send a pre-workshop questionnaire to collect preliminary activity lists +- Brief participants on objectives and terminology (MTPD, RTO, RPO, MBCO) +- Clarify that the exercise is about understanding operational impact — not assigning blame + +**Key questions to ask in each session:** + +1. **Activity identification**: What are the key activities/processes your team performs + to support delivery of [products/services]? Please list them. + +2. **Volume and timing**: How many transactions/tasks does each activity handle in a normal + day/week? Are there peak periods or critical deadlines? + +3. **Dependency on IT systems**: Which IT systems are essential? What happens if each system + is unavailable for 1 hour? 4 hours? 1 day? + +4. **Dependency on people**: What is the minimum number of staff required to perform each + activity at MBCO level? What skills are critical? Do you have cross-trained backups? + +5. **Dependency on premises**: Do any activities require access to a specific building or + specialist facility? Could staff work remotely? + +6. **Dependency on third parties**: Which suppliers or external service providers are + critical to perform each activity? + +7. **Impact over time**: What would the consequence be if this activity stopped for: + 1 hour / 4 hours / 1 day / 3 days / 1 week? + +8. **MTPD**: At what point does the disruption become unacceptable (financial, regulatory, + reputational)? What is the hard deadline for recovery? + +9. **Minimum service level**: If you had to resume at reduced capacity, what is the bare + minimum output required (the MBCO)? + +10. **Data recovery**: For data-dependent systems, how much data loss is acceptable? If + systems were restored to yesterday's backup, would that be acceptable? + +### 2.2 Activity Inventory + +Produce a consolidated activity inventory from all sessions: + +| Activity ID | Activity Name | Function/Department | Owner | Product/Service Supported | +|-------------|--------------|---------------------|-------|--------------------------| +| A001 | Customer order entry | Sales Operations | Sales Director | Order fulfilment | +| A002 | Payment processing | Finance | CFO | Revenue collection | +| A003 | Warehouse picking and despatch | Logistics | Logistics Manager | Order fulfilment | +| A004 | HR payroll processing | Human Resources | HR Director | Staff management | +| A005 | IT helpdesk first-line support | IT | IT Director | Internal operations | + +--- + +## Phase 3: Impact Analysis and Parameter Determination + +### 3.1 Impact Heat Map + +For each activity, rate impact at each time horizon across all categories. Use the severity +scale defined in Phase 1. + +**Example for Activity A001 — Customer Order Entry:** + +| Time Since Disruption | Financial | Operational | Regulatory | Reputational | Overall Rating | +|-----------------------|-----------|-------------|------------|--------------|----------------| +| <1 hour | 1 | 1 | 1 | 1 | 1 — Negligible | +| 1–4 hours | 2 | 2 | 1 | 1 | 2 — Minor | +| 4–8 hours | 3 | 3 | 1 | 2 | 3 — Moderate | +| 8–24 hours | 4 | 4 | 2 | 3 | 4 — Significant | +| 1–3 days | 5 | 5 | 3 | 4 | 5 — Catastrophic | +| 3–7 days | 5 | 5 | 4 | 5 | 5 — Catastrophic | + +The overall rating is typically the *maximum* across categories (or agreed worst-case). + +### 3.2 MTPD Determination + +MTPD is the time point at which the impact rating crosses the organisation's unacceptable +threshold (typically rating 4 or 5 on the severity scale, as agreed with top management). + +In the example above, MTPD = 8–24 hours (when impact first reaches 4 — Significant). + +**MTPD represents the absolute deadline: recovery MUST occur before MTPD.** + +Key MTPD considerations: +- Regulatory deadlines (e.g., payment processing cut-off times, reporting obligations) +- Contractual SLAs (e.g., SLAs with 4-hour response times) +- Operational dependencies (e.g., a pick-and-pack process must resume before the loading + dock closes each evening) +- Financial irreversibility (e.g., a payment run that cannot be redone if missed) + +### 3.3 RTO Determination + +RTO is the target recovery time — the time by which the activity SHOULD be recovered. +RTO must be less than MTPD to provide a safety margin. + +General RTO guidance: +- Set RTO at 50–80% of MTPD as a practical target +- Confirm the RTO is technically and operationally achievable with available resources +- Validate RTO through exercises and technical testing + +| MTPD | Suggested RTO Range | +|------|---------------------| +| 1 hour | 30 minutes | +| 4 hours | 2–3 hours | +| 8 hours | 4–6 hours | +| 24 hours | 12–16 hours | +| 3 days | 1–2 days | +| 7 days | 3–5 days | + +### 3.4 RPO Determination + +RPO applies to activities that depend on data or information systems. It defines the maximum +acceptable data loss expressed as a point in time. + +**RPO considerations:** +- What is the most recent backup schedule for critical systems? +- How often is data replicated to a secondary site? +- What is the business impact of losing X hours or days of transactions? +- Is manual re-entry of lost data feasible within the recovery window? + +**RPO relationship to backup strategy:** +| RPO | Required Backup Approach | +|-----|-------------------------| +| Near-zero (minutes) | Synchronous real-time replication | +| 1 hour | Asynchronous replication, continuous data protection (CDP) | +| 4 hours | High-frequency scheduled backups (every 4 hours) | +| 24 hours | Daily backups, offsite copy | +| >24 hours | Standard backup schedules acceptable | + +### 3.5 MBCO Determination + +MBCO is the minimum level of service that must be achieved at the point of recovery (the RTO). +MBCO may be significantly below normal operational capacity: + +**MBCO determination approach:** +1. Identify which activities within the function are truly critical (must-do vs. nice-to-do) +2. Identify what minimum staffing delivers critical activities at acceptable quality +3. Set MBCO as a percentage of normal capacity or as an absolute minimum volume + +**Example MCO statements:** +- "Process a minimum of 50% of normal daily order volume within 8 hours of recovery" +- "Respond to all Priority 1 incidents within 4 hours; Priority 2 and 3 can be deferred" +- "Process weekly payroll on standard schedule; ad hoc pay runs can be deferred 48 hours" + +--- + +## Phase 4: Dependency Mapping + +For each activity, identify all supporting resources: + +### 4.1 People Dependencies + +| Activity | Role Required | Min. Headcount | Skills / Authorisation Required | Backup(s) Available? | +|----------|--------------|----------------|---------------------------------|----------------------| +| Order entry | Sales administrator | 2 | ERP access, order processing procedure | Yes — 1 backup trained | +| Payment processing | Accounts payable clerk | 1 | Finance system access, bank authorisation | No backup — single point of failure | + +Identify **single points of failure** (roles with no trained alternate) and flag for succession +planning. + +### 4.2 Technology Dependencies + +| Activity | System / Application | Criticality | Owner | RTO Requirement | Backup / Failover Available? | +|----------|---------------------|-------------|-------|-----------------|------------------------------| +| Order entry | ERP (SAP S/4HANA) | Critical | IT Director | 8 hours | DR site — 6-hour RTO | +| Payment processing | Banking portal | Critical | CFO | 4 hours | Alternative bank portal available | +| All office activities | LAN/WAN/VPN | Critical | IT Director | 2 hours | 4G failover available | + +### 4.3 Premises Dependencies + +| Activity | Dependency on Location | Can Be Performed Remotely? | Alternate Location Available? | +|----------|-----------------------|----------------------------|-------------------------------| +| Order entry | Office premises (Level 2) | Yes — if VPN access | Remote working; alternate site | +| Warehouse operations | Main warehouse only | No — physical operation | No immediate alternate | + +### 4.4 Information and Data Dependencies + +| Activity | Information / Document Required | Location | Paper Copy Available? | Offsite Copy? | +|----------|---------------------------------|----------|----------------------|---------------| +| Order processing | Customer contracts | CRM system | No | Archived in cloud | +| Finance reporting | GL data | ERP | Monthly printout | DR site replica | +| Legal compliance | Regulatory filings | Document management system | No | IT backup | + +### 4.5 Supplier and Third-Party Dependencies + +| Activity | Supplier / Partner | Service Provided | Criticality | Alternate Available? | Supplier BCP Verified? | +|----------|--------------------|-----------------|-------------|----------------------|------------------------| +| Payroll | ADP (outsourced payroll) | Payroll processing | Critical | Manual processing feasible | Not verified | +| IT infrastructure | Cloud provider (AWS) | Hosting | Critical | Azure fallback partial | AWS SLA: 99.99% uptime | +| Logistics | DHL | Outbound deliveries | High | Alternative courier available | Not verified | + +--- + +## Phase 5: Prioritisation and BIA Report + +### 5.1 Activity Priority Tiers + +Based on MTPD and impact assessments, assign each activity to a priority tier: + +| Priority Tier | Criteria | Recovery Target | +|---------------|----------|-----------------| +| Critical | MTPD ≤ 24 hours; catastrophic impact if disrupted | Must recover within RTO (typically <24 hours) | +| High | MTPD 24 hours – 3 days; significant impact | Must recover within 1–3 days | +| Medium | MTPD 3–7 days; moderate impact | Recover within 3–7 days | +| Low | MTPD >7 days; limited impact | Recover within 1–4 weeks | +| Deferred | Can be suspended entirely during incident | No recovery target required during BCMS invocation | + +### 5.2 BIA Summary Table + +The BIA summary table forms the core output document: + +| Activity | Owner | Priority | MTPD | RTO | RPO | MBCO | Key IT Dependency | Key People Risk | Key Supplier | +|----------|-------|----------|------|-----|-----|------|------------------|----------------|--------------| +| Customer order entry | Sales Dir | Critical | 24h | 8h | 4h | 50% | ERP | Sales admin (no backup) | None | +| Payment processing | CFO | Critical | 8h | 4h | 1h | 100% | Banking portal | AP clerk (SPOF) | ADP | +| Warehouse operations | Logistics Mgr | Critical | 16h | 8h | N/A | 75% | WMS | Forklift operators | DHL | +| HR payroll | HR Director | High | 5 days | 3 days | 1 day | Weekly cycle | ERP | HR manager | ADP | +| IT helpdesk | IT Director | Medium | 7 days | 3 days | N/A | P1 only | ITSM tool | Helpdesk staff | None | + +### 5.3 BIA Report Structure + +The formal BIA report (retained documented information) should include: + +1. **Executive Summary**: Scope, methodology, headline findings, top risks to continuity +2. **BIA Methodology**: How the assessment was conducted, assumptions, limitations +3. **Activity Inventory**: Full list of assessed activities with ownership +4. **Impact Analysis Results**: Impact heat maps and MTPD justification per activity +5. **Recovery Parameters**: Consolidated RTO/RPO/MBCO/RLO table +6. **Dependency Register**: People, technology, premises, information, supplier dependencies +7. **Priority Tier Assignment**: Tiered activity list +8. **Key Findings and Gaps**: Single points of failure, high-risk dependencies, unachievable RTOs +9. **Recommendations**: Actions for risk treatment, strategy design, and plan prioritisation +10. **Appendices**: Interview records, raw data, assumptions + +--- + +## BIA Maintenance + +The BIA should be reviewed and updated: +- **Annually** as part of the regular BCMS review cycle +- **When significant organisational changes occur**: new products/services, restructuring, major + technology changes, new sites, key supplier changes +- **Following an incident or exercise** that reveals assumptions were incorrect +- **Following management review** if new risks or priorities are identified + +A BIA that is more than 12 months old, or that does not reflect current operations, is a +common nonconformity finding in ISO 22301 certification audits. + +--- + +## Common BIA Mistakes to Avoid + +| Mistake | Why It's a Problem | Correct Approach | +|---------|--------------------|-----------------| +| Confusing RTO with MTPD | Sets RTO at MTPD, leaving no safety margin | RTO must be less than MTPD | +| Setting aspirational RTOs not backed by strategy | Unreachable RTOs invalidate plans | Verify RTOs are achievable with available resources and strategy | +| Only assessing IT systems | ISO 22301 requires assessing all activities, not just technology | Include all processes: manual, operational, financial, people | +| Conducting BIA without business process owners | IT-led BIAs miss operational context | Process owners must participate; IT provides dependency data | +| Not updating the BIA after changes | Stale BIA invalidates all downstream plans | Embed BIA review into change management and annual cycle | +| Setting RPO equal to backup frequency | Backup frequency sets the minimum achievable RPO, not the requirement | Determine the business need for RPO first, then design backup to match | +| MBCO set at 100% | Prevents phased recovery; may be unachievable | MBCO should reflect truly minimum viable service, enabling prioritisation | diff --git a/plugins/iso22301/skills/iso22301/references/iso22301-clauses.md b/plugins/iso22301/skills/iso22301/references/iso22301-clauses.md new file mode 100644 index 0000000..5a7af77 --- /dev/null +++ b/plugins/iso22301/skills/iso22301/references/iso22301-clauses.md @@ -0,0 +1,758 @@ +# ISO 22301:2019 — Full Clause Requirements Reference + +## Introduction + +ISO 22301:2019, titled *Security and resilience — Business continuity management systems — +Requirements*, was published by the International Organization for Standardization (ISO) in +October 2019 via Technical Committee ISO/TC 292. It replaced ISO 22301:2012 and is the +internationally recognised standard specifying requirements for a Business Continuity +Management System (BCMS). + +The standard uses the ISO High Level Structure (HLS/Annex SL) common to all modern ISO +management system standards, ensuring integration compatibility with ISO 27001, ISO 9001, +ISO 14001, and ISO 42001. + +--- + +## Scope (Clause 1) + +The standard specifies requirements to plan, establish, implement, operate, monitor, review, +maintain, and continually improve a documented management system to protect against, reduce +the likelihood of occurrence of, prepare for, respond to, and recover from disruptions when +they arise. + +The requirements are generic and applicable to all organisations regardless of type, size, or +nature. The extent of application depends on the organisation's operating environment and +complexity. + +--- + +## Normative References (Clause 2) + +No normative references. The date of publication is used to determine the applicable version. + +--- + +## Terms and Definitions (Clause 3) + +**Core Terms:** + +| Term | Definition | +|------|-----------| +| Business continuity (BC) | Capability of an organisation to continue delivery of products and services within acceptable time frames at predefined capacity during a disruption | +| Business continuity management (BCM) | Holistic management process that identifies potential threats and impacts, and provides a framework for building organisational resilience | +| Business continuity management system (BCMS) | Part of the overall management system that establishes, implements, operates, monitors, reviews, maintains, and improves an organisation's business continuity capability | +| Business continuity plan (BCP) | Documented information that guides an organisation to respond to a disruption and resume, recover, and restore delivery of products and services | +| Business impact analysis (BIA) | Process of analysing activities and the effect that a business disruption might have upon them | +| Continuity of operations | Continuous performance of essential or critical functions during any operational disruption | +| Crisis management | Holistic management process that identifies potential impacts threatening an organisation and provides a framework for effective response | +| Disruption | Incident, whether anticipated or not, that causes an unplanned negative deviation from expected delivery of products and services | +| Exercise | Process for training personnel and testing the capability of the BCMS to determine whether the specified performance can be achieved | +| Incident | Situation that might be, or could lead to, a disruption, loss, emergency, or crisis | +| Interested party | Person or organisation that can affect, be affected by, or perceive itself affected by a decision or activity | +| Maximum tolerable period of disruption (MTPD) | Time after which an organisation's viability will be irrevocably threatened if delivery of a product or service cannot be resumed | +| Minimum business continuity objective (MBCO) | Minimum level of services and/or products that is acceptable to the organisation to achieve its business objectives during a disruption | +| Recovery level objective (RLO) | Defined level at which an activity or group of activities must be resumed in the required timeframe | +| Recovery point objective (RPO) | Point to which information used by an activity must be restored to enable the activity to operate on resumption; also used as the maximum tolerable loss of data | +| Recovery time objective (RTO) | Period of time following an incident within which a product or service must be resumed, or an activity must be resumed, or resources must be recovered | +| Scope | Boundaries and applicability of a management system | +| Top management | Person or group of people who directs and controls an organisation at the highest level | +| Workaround | Alternative means by which work is performed in the absence of the normal system or site | + +--- + +## Clause 4 — Context of the Organisation + +### 4.1 Understanding the Organisation and Its Context + +**Requirement**: The organisation shall determine external and internal issues that are relevant +to its purpose and that affect its ability to achieve the intended outcome(s) of its BCMS. + +**Scope of factors to consider:** + +*External factors:* +- Political, economic, social, technological, legal, environmental, and competitive environment +- Relationships with and perceptions and values of external interested parties +- Key drivers and trends affecting the organisation's objectives +- Contractual relationships and dependencies in supply chains + +*Internal factors:* +- Governance, organisational structure, roles, and accountabilities +- Policies, objectives, and the strategies that are in place +- Capabilities in terms of resources and knowledge +- Information systems and information flows +- Relationships with internal stakeholders and their perceptions and values +- Organisational culture +- Standards, guidelines, and models adopted by the organisation + +**Mandatory documented output**: None explicitly, but context is normally summarised in +the BCMS scope document and feeds directly into Clause 4.3. + +--- + +### 4.2 Understanding Needs and Expectations of Interested Parties + +**Requirement**: The organisation shall determine relevant interested parties that are relevant +to the BCMS, along with their relevant requirements. + +**Typical interested parties and their BC-related requirements:** + +| Interested Party | Typical BC Requirements | +|-----------------|------------------------| +| Customers/clients | Defined RTOs, communication during incidents, contractual service levels | +| Regulators/legal entities | Incident notification timeframes, data preservation, audit access | +| Shareholders/investors | Reputational protection, financial recovery capability | +| Employees | Safety during incidents, communication, remote working capability | +| Suppliers and partners | Interdependency management, notification obligations | +| Insurers | BCMS documentation, evidence of exercising, annual reviews | +| Emergency services | Liaison contacts, access procedures, hazard information | +| Auditors/certification body | Full BCMS documentation per standard requirements | +| Local community | Public safety, communication, environmental incident management | + +**Mandatory documented output**: None explicitly required, but the analysis normally +informs the BCMS scope and policy. + +--- + +### 4.3 Determining the Scope of the BCMS + +**Requirement**: The organisation shall determine the boundaries and applicability of the BCMS. +When determining scope, the organisation shall consider: +- External and internal issues from 4.1 +- Requirements of interested parties from 4.2 +- The organisation's functions and their inter-dependencies with other organisations + +**Scope must state**: which products and services, activities, functions, sites, and processes +are included in the BCMS. + +**Key scoping decisions:** +- Geographic scope: which sites/locations are covered +- Functional scope: which business functions, departments, products/services +- Technology scope: which systems and infrastructure are in scope +- Supply chain scope: which third-party dependencies are addressed +- What is explicitly excluded (and the justification for exclusion) + +**Mandatory documented output**: Written BCMS scope statement (retained documented information). + +--- + +### 4.4 Business Continuity Management System + +**Requirement**: The organisation shall establish, implement, maintain, and continually improve +a BCMS, including the processes needed and their interactions, in accordance with the standard. + +--- + +## Clause 5 — Leadership + +### 5.1 Leadership and Commitment + +**Requirement**: Top management shall demonstrate leadership and commitment with respect to +the BCMS by: + +- Taking accountability for the effectiveness of the BCMS +- Ensuring the BC policy and objectives are established and are compatible with the strategic direction +- Ensuring integration of BCMS requirements into the organisation's business processes +- Ensuring resources needed for the BCMS are available +- Communicating the importance of effective business continuity management +- Ensuring the BCMS achieves its intended outcomes +- Directing and supporting persons to contribute to effectiveness of the BCMS +- Promoting continual improvement +- Supporting other relevant management roles to demonstrate leadership in their areas + +**Evidence expected by auditors:** +- Minutes of management meetings referencing BCMS +- Budget approvals for BC activities +- Top management sign-off on BC policy +- Evidence of executive participation in management reviews and exercises + +--- + +### 5.2 Policy + +**Requirement**: Top management shall establish, implement, and maintain a BC policy that: +- Is appropriate to the purpose of the organisation +- Provides a framework for setting BC objectives +- Includes a commitment to satisfy applicable requirements +- Includes a commitment to continual improvement + +The policy shall be available as documented information, communicated within the organisation, +and available to interested parties as appropriate. + +**Mandatory documented output**: Business continuity policy (must be signed by top management). + +**Policy must include (minimum):** +- Statement of commitment to BC +- BC scope alignment +- Alignment to applicable legal/regulatory/contractual requirements +- Roles with responsibility for BCMS +- Commitment to regular review +- Reference to objectives + +--- + +### 5.3 Organisational Roles, Responsibilities and Authorities + +**Requirement**: Top management shall ensure that the responsibilities and authorities for +relevant roles are assigned and communicated within the organisation. In particular, top +management shall assign responsibility and authority to: +- Ensure the BCMS conforms to the requirements of this document +- Report on the performance of the BCMS to top management + +**Typical BCMS role structure:** + +| Role | Typical Responsibilities | +|------|------------------------| +| BCMS Manager / Owner | Overall management of the BCMS; coordination of BIA, risk assessment, plan maintenance; management reporting | +| Executive Sponsor / Senior Responsible Owner | Top management accountability; policy sign-off; management review chairmanship | +| Business Continuity Team | Department-level plan owners; BIA subject matter experts; exercise coordination | +| Incident Commander (Crisis Manager) | Leading the response during a disruption; activating plans; authorising communications | +| IT Recovery Lead | Technical recovery; DR plan ownership; backup and failover tests | +| Communications Lead | Internal and external communications during incidents; media liaison | +| Human Resources Lead | Staff welfare; remote working; temporary staffing | +| Legal/Compliance Lead | Regulatory notification; contractual obligations during incidents | + +--- + +## Clause 6 — Planning + +### 6.1 Actions to Address Risks and Opportunities + +**Requirement**: When planning for the BCMS, the organisation shall consider issues from +4.1 and requirements from 4.2 and determine the risks and opportunities that need to be +addressed to: +- Give assurance that the BCMS can achieve its intended result(s) +- Prevent, or reduce, undesired effects +- Achieve continual improvement + +Organisation shall plan: +- Actions to address these risks and opportunities +- Integration and implementation of actions into BCMS processes +- Methods to evaluate effectiveness of actions + +--- + +### 6.2 Business Continuity Objectives and Plans to Achieve Them + +**Requirement**: Organisation shall establish BC objectives at relevant functions and levels. +Objectives shall: +- Be consistent with the BC policy +- Be measurable (where practicable) +- Take into account applicable BC requirements +- Be monitored +- Be communicated +- Be updated as appropriate + +When determining how to achieve objectives, the organisation shall determine: +- What will be done +- What resources will be required +- Who will be responsible +- When it will be completed +- How the results will be evaluated + +**Mandatory documented output**: BC objectives and associated plans. + +**Example BC objectives:** +| Objective | Measure | Target | Review Frequency | +|-----------|---------|--------|-----------------| +| BIA completed for all in-scope activities | % activities with current BIA (reviewed within 12 months) | 100% | Annual | +| All critical BCPs exercised | % critical plans exercised within 24-month cycle | 100% | Annual | +| RTO met in exercises | % of tests where RTO was achieved or bettered | ≥90% | Per exercise | +| Staff awareness of plans | % of BC team trained on plans | 100% | Annual | +| Plans reviewed and updated | % of plans reviewed within 12 months | 100% | Annual | + +--- + +## Clause 7 — Support + +### 7.1 Resources +Organisation determines and provides resources for establishing, implementing, maintaining, +and continually improving the BCMS. Resources include: budget, people, technology, tools, +facilities. + +### 7.2 Competence +Organisation shall: +- Determine the necessary competence of persons doing work under its control that affects BC performance +- Ensure persons are competent on the basis of appropriate education, training, or experience +- Where applicable, take actions to acquire necessary competence and evaluate their effectiveness +- Retain appropriate documented information as evidence of competence + +**Mandatory documented output**: Evidence of competence (training records, qualifications). + +**Competence areas for BCMS personnel:** +- Understanding of ISO 22301 requirements +- BC planning and design methodology +- BIA facilitation skills +- Risk assessment methodology +- Exercise design and facilitation +- Incident command and crisis management +- IT disaster recovery (for technical teams) + +### 7.3 Awareness +Persons doing work under the organisation's control shall be aware of: +- The BC policy +- Their contribution to the effectiveness of the BCMS, including benefits of improved performance +- Implications of not conforming with BCMS requirements + +### 7.4 Communication +Organisation determines needed communications relevant to the BCMS, addressing: +- What to communicate +- When to communicate +- With whom to communicate +- Who shall communicate +- How to communicate (methods and channels) + +**Note**: This clause covers proactive communication planning, separate from the crisis +communication procedures in Clause 8.4.3. + +### 7.5 Documented Information +BCMS shall include: +- Documented information required by this standard (mandatory items) +- Documented information determined by the organisation as necessary for effectiveness + +Organisation shall control documented information to ensure: +- Availability and suitability for use, when and where needed +- Adequate protection (from loss of confidentiality, improper use, or loss of integrity) + +Activities include: creation and updating (format, media, review and approval) and control +(distribution, access, retrieval, storage, retention, disposition). + +--- + +## Clause 8 — Operation + +### 8.1 Operational Planning and Control + +**Requirement**: Organisation shall plan, implement, control, maintain, and review the +processes needed to meet requirements and implement actions from 6.1, by: +- Establishing criteria for the processes +- Implementing control of processes in accordance with criteria +- Keeping documented information to have confidence processes carried out as planned +- Adapting work to individuals + +Organisation shall control planned changes and review consequences of unintended changes, +taking action to mitigate adverse effects. Ensure outsourced processes are controlled. + +**Mandatory documented output**: Evidence that processes are carried out as planned. + +--- + +### 8.2 Business Impact Analysis and Risk Assessment + +#### 8.2.1 General +Organisation establishes, implements, and maintains a formal and documented process for BIA +and risk assessment that: +- Considers scope, objectives, necessary plans, and applicable interested party requirements +- Identifies required BC strategies or solutions +- Is integrated with the overall risk management approach +- Identifies one or more persons with authority and responsibility for this process + +#### 8.2.2 Business Impact Analysis + +**Full Requirement**: Organisation shall assess potential impacts from disruption of activities +that support delivery of products/services within scope: + +1. **Identify activities**: catalogue all activities (functions, processes, tasks) that support + delivery of in-scope products and services. + +2. **Assess impacts over time**: for each activity, assess the cumulative impacts of disruption + at defined time points (e.g., 1 hour, 4 hours, 1 day, 3 days, 1 week, 1 month). Impact + categories include financial, operational, legal/regulatory, reputational, and contractual. + +3. **Determine MTPD**: the point beyond which the organisation cannot tolerate the disruption + of each activity. MTPD represents the hard deadline for recovery. + +4. **Determine RTO**: the target time by which the activity must be resumed following a + disruption. RTO must be less than MTPD. + +5. **Determine MBCO**: minimum acceptable level of service at resumption (may be less than + pre-disruption level, enabling phased recovery). + +6. **Determine RPO**: the point in time to which data must be restored following recovery. + Expressed as "up to X hours/days of data loss is acceptable". + +7. **Identify dependencies**: for each activity, identify supporting resources: + - People: roles, number, specialist skills + - Technology: applications, infrastructure, data + - Premises: office space, specialist facilities + - Information: data, records, documentation + - Suppliers: who must be available + +8. **Prioritise activities**: rank by impact and urgency to drive strategy decisions. + +**Mandatory documented output**: BIA results (retained documented information). + +#### 8.2.3 Risk Assessment + +**Full Requirement**: Risk assessment shall: + +1. Identify risks of disruption to the organisation considering activities identified in BIA +2. Analyse identified risks considering likelihood and consequence +3. Evaluate risks against the organisation's risk criteria (risk appetite) +4. Produce documented outputs as inputs to: + - BC strategy selection (8.3) + - BC objectives (6.2) + - Actions to address risks (6.1) +5. Review and update when significant changes occur or at planned intervals + +**Mandatory documented output**: Risk assessment results (retained documented information). + +**Risk categories to consider:** +| Category | Example Scenarios | +|----------|-----------------| +| Natural hazards | Flooding, severe storms, earthquakes, extreme heat, pandemic | +| Utility failures | Power outage, water supply failure, telecommunications failure | +| Technology failures | IT infrastructure failure, cyberattack, ransomware, software failure | +| Physical damage | Fire, structural damage, hazardous material incident | +| Human factors | Key person dependency, industrial action, terrorism, civil unrest | +| Supply chain | Critical supplier insolvency, logistics disruption, raw material shortage | +| Regulatory/legal | Enforcement action, regulatory change, legal injunction | + +--- + +### 8.3 Business Continuity Strategy and Solutions + +#### 8.3.1 General +Organisation shall determine appropriate BC strategies and solutions based on outputs of BIA +(8.2.2) and risk assessment (8.2.3). Selection must consider: +- Risk profile and how strategies reduce it +- Cost-benefit analysis +- Organisation's risk appetite and BC objectives +- Technical and operational feasibility + +#### 8.3.2 Identification of Strategies and Solutions + +Organisation identifies strategies and solutions for: +- Continuity of prioritised activities within RTO and at MBCO +- Recovery of resources (people, technology, premises, information) +- Recovery of supply chain dependencies +- Protection and mitigation measures to prevent or reduce disruption + +**Strategies by resource type:** + +*People* +- Cross-training and succession planning +- Remote and agile working arrangements +- Mutual aid agreements with peer organisations +- Temporary staffing contracts +- Key-person insurance + +*Technology and data* +- Hot, warm, or cold standby disaster recovery sites +- Cloud-based redundancy and failover +- Data replication and synchronisation (drives RPO achievement) +- Offline and offsite backup (tapes, cloud archives) +- Return to manual/paper processes as fallback + +*Premises* +- Alternate work locations (owned, leased, or shared) +- Work-from-home policies and remote access infrastructure +- Mobile facilities +- Reciprocal agreements with other organisations + +*Supply chain* +- Dual or multi-sourcing for critical supplies +- Inventory buffers and pre-positioned stock +- Pre-qualified alternative suppliers +- Contractual BCP requirements for critical suppliers + +*Finance* +- Emergency funding reserves +- Pre-arranged lines of credit or insurance +- Business interruption insurance + +#### 8.3.3 Selection of Strategies and Solutions + +Organisation selects strategies that collectively deliver: +- Recovery of prioritised activities within RTO +- Achievement of MBCO at recovery point +- RPO compliance for data-dependent activities +- Coverage of identified risks + +**Mandatory documented output**: Selected BC strategies and solutions (documented). + +#### 8.3.4 Resource Requirements + +Organisation identifies resources to implement selected strategies, covering: +- People: numbers, roles, skills required +- Information and data: systems, manual records, documentation +- Buildings, facilities, and work environment: alternate locations, utilities +- Technology and equipment: hardware, software, communications +- Transportation: vehicles, logistics +- Finance: emergency funds, insurance +- Partners and suppliers: third-party services required + +**Mandatory documented output**: Resource requirements list (documented information). + +#### 8.3.5 Protection and Mitigation + +Consider proportionate measures to protect critical activities from identified risks: +- Physical protection: security, fire suppression, flood barriers +- Technology hardening: redundant power, network diversity +- HR risk reduction: succession planning, knowledge management +- Supply chain hardening: supplier qualification, contract protections +- Insurance: business interruption, property, cyber + +--- + +### 8.4 Business Continuity Plans and Procedures + +#### 8.4.1 General + +Organisation implements its BC strategies through documented plans and procedures. +Plans must be: +- Documented and version-controlled +- Approved by appropriate authority +- Accessible to those who need them +- Protected from unauthorised access or modification +- Communicated to relevant personnel + +#### 8.4.2 Incident Response Structure + +**Requirement**: Organisation shall establish, implement, and maintain procedures to manage +incidents effectively. These must include: + +- **Activation criteria**: conditions and thresholds that trigger incident declaration +- **Short-term priorities**: immediate actions (life safety first, then critical operations protection) +- **Roles and accountabilities** of crisis/incident management team, including who leads, who deputises +- **Internal communication** during the incident (cascade procedures, meeting cadence) +- **External communication**: customers, regulators, media, emergency services, public +- **Continuity of critical activities**: bridge to business continuity plans +- **Stakeholder management**: proactive management of key relationships during incident +- **Media and social media**: assignment of spokesperson, message approval process +- **Escalation and de-escalation**: criteria for escalating severity and for standing down + +#### 8.4.3 Warning and Communication + +Plans must address communication needs during a disruption: +- Internal communication plan (including all-staff, departmental cascades, BC team mobilisation) +- Customer and stakeholder communication procedures +- Regulatory and authority notification (where incident meets thresholds) +- Communication through backup channels if primary systems unavailable +- Template statements and holding messages for different scenarios +- Authorisation chain for releasing communications + +#### 8.4.4 Business Continuity Plans + +Each BCP must contain (minimum): + +| Element | Description | +|---------|-------------| +| Activation conditions | Specific criteria that trigger this plan | +| Resources required | People, technology, premises needed to execute the plan | +| Short-term response | Actions for the first hours of activation | +| Long-term response | Actions to sustain operations at MBCO | +| Roles and responsibilities | Named roles, alternates, and contact details | +| Communication requirements | What to communicate, to whom, when | +| Information requirements | Systems and data needed; what to do if unavailable | +| Inter-dependencies | Links to other plans (IRP, IT DR plan, supplier plans) | +| Return to normal | Criteria and steps for transitioning back to normal operations | + +#### 8.4.5 Recovery + +Procedures to recover activities to normal levels must include: +- Damage assessment and impact determination +- Identification of recovery resources and their acquisition +- Roles and responsibilities during recovery +- Coordination with internal and external parties +- Decision criteria for returning to normal operations +- Lessons learned / post-incident review process + +--- + +### 8.5 Exercising and Testing the BCMS + +#### 8.5.1 General + +**Requirement**: Organisation shall conduct exercises to validate its BC strategies, solutions, +and plans. The exercise programme shall be documented and have clear objectives. + +Exercises confirm: +- BC plans are achievable +- Personnel understand their roles +- Recovery timeframes (RTOs) are achievable +- Communication procedures work +- Dependencies are correctly identified + +Results of exercises must be reviewed, shortfalls identified, and corrective actions tracked. + +**Mandatory documented outputs**: Exercise programme, exercise results, corrective actions. + +**Exercise progression model:** + +1. **Tabletop discussion**: Low-risk, facilitated walkthrough; no actual system interruption. + Best for testing understanding of plans and roles. Frequency: at minimum annually. + +2. **Walkthrough / plan review**: Participants step through the plan page-by-page, identifying + gaps and ambiguities. Can be desk-based. + +3. **Functional / component test**: Test a specific component (e.g., IT failover to DR site, + backup tape restoration, alternate site connectivity). Validates technical solutions. + +4. **Full simulation**: Comprehensive scenario with senior leadership roleplay, comms tested, + but critical systems not actually failed over. Most effective type short of live invocation. + +5. **Live / full interruption**: Actual invocation of continuity arrangements. Highest risk; + used for testing most critical scenarios. Must be planned carefully to prevent actual disruption. + +#### 8.5.2 Testing + +Organisation must validate technical solutions through testing: +- IT failover times from primary to DR site (confirms RTO achievable) +- Data backup restoration (confirms RPO achievable) +- Alternate site connectivity and access provisioning +- Communication systems (messaging platforms, emergency notification) +- Generator and UPS performance under load + +Test results must be documented, and failures must be resolved. + +--- + +### 8.6 Evaluation and Updating Pre- and Post-Incident + +Following any exercise, test, or actual incident: +- Evaluate effectiveness of BC strategy, solutions, and plans +- Identify gaps, failures, and improvements +- Update BIA, risk assessment, strategies, and plans as appropriate +- Document the evaluation and resulting changes + +--- + +## Clause 9 — Performance Evaluation + +### 9.1 Monitoring, Measurement, Analysis and Evaluation + +**Requirement**: Organisation shall determine: +- What needs to be monitored and measured regarding BCMS performance +- Methods for monitoring, measurement, analysis, and evaluation +- When monitoring and measuring shall be performed +- When results shall be analysed and evaluated +- Who analyses and evaluates results + +Retain documented information as evidence of results. + +**Mandatory documented output**: Monitoring and measurement results. + +**Common BCMS KPIs:** + +| KPI | Target | Measurement Method | +|-----|--------|--------------------| +| BIA currency (reviewed within 12 months) | 100% of in-scope activities | BIA register review date | +| Plan currency (reviewed within 12 months) | 100% of plans | Plan document review date | +| Exercise completion rate | 100% of critical plans exercised within cycle | Exercise log | +| RTO achievement in tests | ≥90% of tests | Exercise/test reports | +| BC staff training completion | 100% of BC team trained | Training records | +| Corrective action close rate | ≥90% within agreed SLA | CA register | +| Internal audit completion | 100% as per audit schedule | Audit programme | + +--- + +### 9.2 Internal Audit + +**Requirement**: Organisation shall conduct internal audits at planned intervals to provide +information on whether the BCMS: +- Conforms to the organisation's own requirements and the requirements of this standard +- Is effectively implemented and maintained + +Organisation shall: +- Plan, establish, implement, and maintain an audit programme +- Consider importance of processes concerned and results of previous audits +- Define audit criteria and scope +- Select auditors that ensure objectivity and impartiality +- Ensure audit results are reported to relevant management +- Retain documented information as evidence + +**Mandatory documented output**: Internal audit programme and results. + +**Typical internal audit scope for BCMS:** +- Clause 4: Context documentation and currency +- Clause 5: Leadership evidence and policy status +- Clause 6: Objectives set, planned, and monitored +- Clause 7: Training records, communication, documentation control +- Clause 8: BIA completeness, risk assessment currency, plan documentation, exercise records +- Clause 9: KPI monitoring, audit programme, management review inputs/outputs +- Clause 10: Nonconformity records and corrective action status + +--- + +### 9.3 Management Review + +**Requirement**: Top management shall review the BCMS at planned intervals to ensure its +continuing suitability, adequacy, and effectiveness. + +**Mandatory inputs to management review:** +- Status of actions from previous reviews +- Changes in external and internal issues relevant to the BCMS +- BC performance information including trends in: + - Nonconformities and corrective actions + - Monitoring and measurement results + - Audit results + - Exercise results (including RTOs achieved) +- Adequacy of resources +- Effectiveness of actions taken to address risks and opportunities +- Opportunities for continual improvement + +**Mandatory outputs from management review:** +- Decisions related to continual improvement opportunities +- Any need for changes to the BCMS +- Resource needs + +**Mandatory documented output**: Management review minutes/record (retained evidence). + +--- + +## Clause 10 — Improvement + +### 10.1 Nonconformity and Corrective Action + +When a nonconformity occurs, the organisation shall: +1. React to the nonconformity, and as applicable: + - Take action to control and correct it + - Deal with the consequences +2. Evaluate the need for action to eliminate the causes of the nonconformity: + - Reviewing the nonconformity + - Determining the causes + - Determining if similar nonconformities exist or could occur +3. Implement any action needed +4. Review effectiveness of any corrective action taken +5. Make changes to the BCMS if necessary + +Corrective actions shall be appropriate to the effects of the nonconformities encountered. + +**Mandatory documented output**: Evidence of nature of nonconformities and subsequent actions; +results of corrective actions. + +### 10.2 Continual Improvement + +Organisation shall continually improve the suitability, adequacy, and effectiveness of the BCMS. +Inputs to improvement include: audit results, exercise results, management review outputs, +monitoring data, incident reviews, and stakeholder feedback. + +--- + +## Mandatory Documented Information Summary + +| Document | Clause | Type | +|----------|--------|------| +| BCMS scope statement | 4.3 | Retained | +| BC policy | 5.2 | Maintained | +| BC objectives and achievement plans | 6.2 | Maintained | +| Evidence of competence | 7.2 | Retained | +| BIA results | 8.2.2 | Retained | +| Risk assessment results | 8.2.3 | Retained | +| BC strategies and solutions | 8.3.3 | Retained | +| Resource requirements | 8.3.4 | Retained | +| Incident response structure/procedures | 8.4.2 | Maintained | +| Communication procedures | 8.4.3 | Maintained | +| Business continuity plans | 8.4.4 | Maintained | +| Recovery procedures | 8.4.5 | Maintained | +| Exercise programme | 8.5.1 | Maintained | +| Exercise results | 8.5.1 | Retained | +| Test results | 8.5.2 | Retained | +| Monitoring and measurement results | 9.1 | Retained | +| Internal audit programme | 9.2 | Maintained | +| Internal audit results | 9.2 | Retained | +| Management review outputs | 9.3 | Retained | +| Nonconformities and corrective actions | 10.1 | Retained | + +*Maintained = document must be kept current / Retained = record must be preserved* diff --git a/plugins/iso22301/skills/iso22301/references/iso22301-templates.md b/plugins/iso22301/skills/iso22301/references/iso22301-templates.md new file mode 100644 index 0000000..6473ae4 --- /dev/null +++ b/plugins/iso22301/skills/iso22301/references/iso22301-templates.md @@ -0,0 +1,703 @@ +# ISO 22301:2019 — Templates Reference + +## Overview + +This reference provides ready-to-use templates for the key documents required by +ISO 22301:2019. All templates are structured to satisfy the relevant clause requirements +and are suitable for adaptation to any organisation's context and terminology. + +Templates included: +1. Business Continuity Policy +2. BCMS Scope Statement +3. BIA Form (single activity) +4. Risk Register template +5. Exercise Plan template +6. Exercise After-Action Report template +7. Management Review agenda and record template +8. Nonconformity and Corrective Action Record +9. BCMS Internal Audit Plan template +10. BC Competence Matrix template + +--- + +## Template 1 — Business Continuity Policy + +*Satisfies ISO 22301:2019 Clause 5.2. Must be signed by top management.* + +--- + +**[ORGANISATION NAME]** +**Business Continuity Policy** + +| Field | Value | +|-------|-------| +| Policy Reference | POL-BCM-001 | +| Version | [x.x] | +| Status | Active | +| Approved by | [CEO / Managing Director / Board] | +| Approval Date | [Date] | +| Next Review Date | [Date — maximum 12 months] | +| Owner | [BCMS Manager / Head of Risk] | + +--- + +**1. Purpose** + +[ORGANISATION NAME] is committed to maintaining continuity of its critical operations and +protecting the interests of its customers, employees, shareholders, and other stakeholders +in the event of a disruption to normal business activities. + +This policy establishes the organisation's commitment to implementing and maintaining a +Business Continuity Management System (BCMS) in accordance with ISO 22301:2019. + +**2. Scope** + +This policy applies to all activities, functions, and personnel within the BCMS scope +as defined in the BCMS Scope Statement (document reference: SCP-BCM-001). + +**3. Policy Statement** + +[ORGANISATION NAME] will: + +a) Establish, implement, operate, and continually improve a BCMS aligned to ISO 22301:2019; + +b) Identify and assess risks to the continuity of critical activities and implement proportionate + controls to reduce the likelihood and impact of disruptions; + +c) Conduct regular Business Impact Analyses (BIAs) to understand the impact of disruptions + and establish appropriate Recovery Time Objectives (RTOs), Recovery Point Objectives (RPOs), + and Minimum Business Continuity Objectives (MBCOs); + +d) Develop, maintain, and exercise Business Continuity Plans covering all priority activities; + +e) Ensure that resources, competencies, and communications are in place to respond effectively + to incidents; + +f) Meet applicable legislative, regulatory, and contractual requirements related to business + continuity; + +g) Conduct regular exercises and tests to validate the effectiveness of BC strategies and plans; + +h) Review and improve the BCMS continually through management reviews, internal audits, and + post-incident reviews. + +**4. Roles and Responsibilities** + +| Role | Responsibility | +|------|---------------| +| Board / Executive Management | Setting BC objectives; ensuring adequate resources; policy approval | +| BCMS Manager | Day-to-day management of the BCMS; coordination of BIA, risk, plans, exercises | +| Department Heads / Plan Owners | BCP ownership; staff awareness; participation in exercises | +| All Staff | Awareness of BC procedures relevant to their role; reporting incidents promptly | + +**5. Review** + +This policy will be reviewed at least annually, or following a significant business change or +business continuity incident. + +**Signed:** + +_________________________ Date: _____________ + +[Name and Title — CEO / Board Representative] + +--- + +## Template 2 — BCMS Scope Statement + +*Satisfies ISO 22301:2019 Clause 4.3. Must be retained as documented information.* + +--- + +**[ORGANISATION NAME]** +**BCMS Scope Statement** + +| Field | Value | +|-------|-------| +| Document Reference | SCP-BCM-001 | +| Version | [x.x] | +| Approved by | [Role] | +| Approval Date | [Date] | +| Next Review | [Date] | + +**1. Organisation Overview** + +[Brief description of the organisation: what it does, size, key locations, key products/services] + +**2. BCMS Scope** + +The BCMS covers the following: + +*Products and services:* +- [Product/Service A] +- [Product/Service B] + +*Organisational units and functions:* +- [Department/Function A — all activities relating to...] +- [Department/Function B — activities relating to...] + +*Sites and locations:* +- [Site 1: Address, functions covered] +- [Site 2: Address, functions covered] + +*Technology environment:* +The BCMS addresses continuity of the following technology services: +- [System A] +- [System B] + +*Supply chain:* +The BCMS addresses disruption risks from the following critical third-party dependencies: +- [Supplier A — service provided] +- [Supplier B — service provided] + +**3. Exclusions from Scope** + +The following are explicitly excluded from the BCMS scope: + +| Excluded Item | Justification | +|--------------|--------------| +| [Subsidiary / location] | [Reason — e.g., separate legal entity with own BCMS; not material to in-scope services] | +| [Function/activity] | [Reason — e.g., not in critical path for any in-scope product/service] | + +**4. Relationship to Other Management Systems** + +[If applicable: describes integration with ISO 27001 ISMS, ISO 9001 QMS, or other management systems in operation] + +**5. Version History** + +| Version | Date | Author | Summary | +|---------|------|--------|---------| +| 1.0 | [Date] | [Name] | Initial issue | + +--- + +## Template 3 — BIA Assessment Form (Single Activity) + +*Satisfies ISO 22301:2019 Clause 8.2.2. Completed for each in-scope activity.* + +--- + +**BIA Assessment Form** + +| Field | Value | +|-------|-------| +| Activity Name | [Name] | +| Activity ID | [BIA-xxx] | +| Function/Department | [Department] | +| Process Owner | [Role] | +| Products/Services Supported | [List products/services this activity enables] | +| Date Completed | [Date] | +| Next Review | [Date] | +| BIA Facilitator | [Name/Role] | + +--- + +**Section 1 — Activity Description** + +Brief description of the activity: +[What this activity does; how often; volume handled; key inputs and outputs] + +Normal operating hours: [e.g., Monday–Friday, 08:00–18:00] +Peak periods and critical deadlines: [e.g., month-end, quarterly filing deadlines] + +--- + +**Section 2 — Impact Assessment** + +Rate the impact of disruption to this activity at each time horizon. +Scale: 1 = Negligible | 2 = Minor | 3 = Moderate | 4 = Significant | 5 = Catastrophic + +| Time Since Disruption | Financial | Operational | Regulatory/Legal | Reputational | Contractual | Overall | +|-----------------------|-----------|-------------|-----------------|--------------|-------------|---------| +| <1 hour | | | | | | | +| 1–4 hours | | | | | | | +| 4–8 hours | | | | | | | +| 8–24 hours | | | | | | | +| 1–3 days | | | | | | | +| 3–7 days | | | | | | | +| 1–2 weeks | | | | | | | +| >2 weeks | | | | | | | + +Impact assessment narrative (justify ratings, particularly for Regulatory/Legal): +[Notes] + +--- + +**Section 3 — Recovery Parameters** + +| Parameter | Value | Justification | +|-----------|-------|--------------| +| MTPD (Maximum Tolerable Period of Disruption) | [e.g., 24 hours] | [Why — regulatory deadline, SLA, financial impact threshold] | +| RTO (Recovery Time Objective) | [Must be less than MTPD] | [Achievable with available strategies/resources] | +| RPO (Recovery Point Objective) | [e.g., 4 hours] | [Maximum data loss acceptable; aligns to backup frequency?] | +| MBCO (Minimum Business Continuity Objective) | [e.g., 50% capacity / priority transactions only] | [Minimum viable service; allows phased recovery] | +| RLO (Recovery Level Objective) (if applicable) | [e.g., 75% capacity within 48 hours] | [Intermediate target before full restoration] | +| Priority Tier | [Critical / High / Medium / Low] | [Derived from MTPD and impact ratings] | + +--- + +**Section 4 — Dependencies** + +**People:** +| Role | Number Required at MBCO | Specialist Skills/Authorisations | Backup Available? | +|------|------------------------|----------------------------------|-------------------| +| | | | | + +Single points of failure identified: [Yes/No — detail if yes] + +**Technology:** +| System / Application | Criticality | Required at MBCO? | Backup/Failover Available? | +|---------------------|-------------|-------------------|---------------------------| +| | | | | + +**Premises:** +| Dependency on location | Can be performed remotely? | Alternate location? | +|------------------------|---------------------------|---------------------| +| | | | + +**Information/Data:** +| Key Information/Record | Location | Offline/Paper Copy? | Offsite Backup? | +|------------------------|----------|---------------------|-----------------| +| | | | | + +**Suppliers/Third Parties:** +| Supplier | Service Provided | Criticality | Alternate Available? | +|----------|-----------------|-------------|----------------------| +| | | | | + +--- + +**Section 5 — Existing Controls and Gaps** + +Current controls in place to support continuity: +[List existing BC arrangements — e.g., remote access available, daily backups, alternate supplier identified] + +Identified gaps and risks: +[List gaps identified during analysis — e.g., no trained alternate for [role], backup not tested in 12 months] + +Recommendations: +[Actions to close gaps — linked to BC strategy and risk treatment] + +--- + +**Section 6 — Sign-Off** + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| Process Owner | | | | +| BIA Facilitator | | | | + +--- + +## Template 4 — Risk Register + +*Satisfies ISO 22301:2019 Clause 8.2.3. Retained documented information.* + +--- + +**[ORGANISATION NAME] — BCMS Risk Register** + +| Field | Value | +|-------|-------| +| Document Reference | RISK-BCM-001 | +| Version | [x.x] | +| Owner | [BCMS Manager] | +| Last Updated | [Date] | +| Next Review | [Date] | + +**Risk Scoring** + +Likelihood: 1 = Rare | 2 = Unlikely | 3 = Possible | 4 = Likely | 5 = Almost Certain +Impact: 1 = Negligible | 2 = Minor | 3 = Moderate | 4 = Significant | 5 = Catastrophic +Score = Likelihood × Impact | ≤4 = Low | 5–9 = Medium | 10–14 = High | ≥15 = Critical + +--- + +| Risk ID | Scenario | Affected Activities | Likelihood | Impact | Score | Rating | Treatment | Controls / BC Strategy | Owner | Review Date | Residual Score | +|---------|----------|-------------------|-----------|--------|-------|--------|-----------|----------------------|-------|-------------|----------------| +| R001 | Extended IT infrastructure failure (>8 hours) | All IT-dependent activities | 3 | 5 | 15 | Critical | Treat | DR site failover; cloud backup; IT DRP | IT Director | [Date] | [TBD] | +| R002 | Ransomware / destructive cyberattack | All activities | 4 | 5 | 20 | Critical | Treat | Immutable backups; EDR; IR plan; cyber insurance | CISO | [Date] | [TBD] | +| R003 | Primary site inaccessible (fire, flood, denial of access) | Site-dependent activities | 2 | 5 | 10 | High | Treat | Alternate site; remote working; key record offsite copies | Facilities Mgr | [Date] | [TBD] | +| R004 | Key person dependency (critical role unavailable) | [Specific activities] | 3 | 4 | 12 | High | Treat | Cross-training; succession planning; documented procedures | HR Director | [Date] | [TBD] | +| R005 | Critical supplier failure / insolvency | [Supply chain activities] | 2 | 4 | 8 | Medium | Treat | Alternative supplier identified; inventory buffer; contract protections | Procurement | [Date] | [TBD] | +| R006 | Pandemic / widespread staff absence (>30%) | All activities | 2 | 4 | 8 | Medium | Treat | Remote working capability; cross-training; temporary staffing | HR Director | [Date] | [TBD] | +| R007 | Major power failure (>24 hours) | All site-based activities | 2 | 3 | 6 | Medium | Treat | UPS; generator; remote working | Facilities Mgr | [Date] | [TBD] | +| R008 | Telecommunications failure | All comms-dependent activities | 2 | 3 | 6 | Medium | Treat | Dual ISP; 4G backup; mobile devices | IT Director | [Date] | [TBD] | + +*Add additional rows as required per risk assessment.* + +--- + +## Template 5 — Exercise Plan + +*Satisfies ISO 22301:2019 Clause 8.5. Retained as documented information.* + +--- + +**BC Exercise Plan** + +| Field | Value | +|-------|-------| +| Document Reference | EX-BCM-[year]-[nn] | +| Exercise Name | [e.g., Tabletop Exercise — IT Failure Scenario] | +| Exercise Type | Tabletop / Walkthrough / Functional / Simulation / Live | +| Date and Time | [Date, Start time – Estimated end time] | +| Location | [Physical location / virtual meeting platform] | +| Lead Facilitator | [Name and role] | +| Observer(s) | [Names/roles — can include external auditor, senior management] | +| Plans Under Test | [List BCPs, IRP, IT DRP being tested] | + +--- + +**1. Exercise Background and Objectives** + +*Why this exercise is being conducted:* +[e.g., Annual exercising requirement; follow-up from previous exercise findings; +pre-certification test; new plan version validation] + +*Objectives:* +1. [e.g., Test that the Crisis Management Team can mobilise within 30 minutes of incident + declaration] +2. [e.g., Validate that alternate site procedures are feasible for minimum headcount operations] +3. [e.g., Confirm communication cascade (internal and customer) works as documented] +4. [e.g., Test IT recovery team's ability to bring DR environment online within RTO of 6 hours] +5. [e.g., Identify gaps in [specific plan] updated since last exercise] + +--- + +**2. Scenario** + +*Scenario overview:* +[Write a realistic and plausible scenario appropriate to exercise type. For tabletops, +the scenario does NOT need to be one that triggers actual system invocations.] + +*Example scenario — IT ransomware attack:* +"At 07:30 on [exercise date], the IT monitoring system generates alerts indicating multiple +file encryption events across the primary file server and ERP system. By 08:00, the IT Director +confirms that a ransomware attack is underway. Primary systems are taken offline as a +precautionary measure. Initial assessment suggests the attack began at approximately 02:00. +Backups appear intact as of the previous night's scheduled backup at 23:00." + +*Scenario injects (tabletop only — events introduced during the exercise to test decision-making):* +- T+1 hour: "Local media contacts the communications team asking for comment on reports of a + cyberattack." +- T+2 hours: "A major customer contacts their account manager to ask when services will be + restored — they have a critical delivery schedule this afternoon." +- T+3 hours: "IT confirms the attack vector was a phishing email and that customer data may + have been exfiltrated — Data Protection Officer advises a potential 72-hour GDPR notification + obligation may apply." + +--- + +**3. Participants** + +| Name | Role | Representing | Participation Required | +|------|------|-------------|------------------------| +| [Name] | Incident Commander | Executive | Mandatory | +| [Name] | BC Manager | BCMS | Mandatory | +| [Name] | IT Director | IT | Mandatory | +| [Name] | Communications Lead | Corporate Affairs | Mandatory | +| [Name] | HR Lead | HR | Mandatory | +| [Name] | Legal/Compliance | Legal | Mandatory | +| [Name] | Finance Lead | Finance | Mandatory | +| [Name] | [Dept BCP Owner] | [Department] | Required | +| [Name] | Observer | [Role] | Attendee | + +--- + +**4. Success Criteria** + +| Criterion | Measure | Target | Notes | +|-----------|---------|--------|-------| +| CMT mobilised following declaration | Time from declaration to first CMT call | ≤30 minutes | Per IRP requirement | +| IT Recovery actions initiated | Time from declaration to IT DRP activation | ≤1 hour | Per IT DRP | +| Internal all-staff communication issued | Time from declaration | ≤1 hour | Per comms plan | +| Customer holding statement issued | Time from declaration | ≤2 hours | Per comms plan | +| BC plans accessible to all participants | All participants have access | 100% | Test offline copy access | +| [Additional criteria based on objectives] | | | | + +--- + +**5. Out of Scope** + +The following will NOT be tested during this exercise to ensure no disruption to live operations: +- [e.g., Actual IT failover to DR site — logical walkthrough only] +- [e.g., Actual customer notifications — simulated only] +- [e.g., Physical evacuation of building — not part of this scenario] + +--- + +**6. Debrief and Reporting** + +- **Hot debrief**: Immediately following exercise; 30-minute facilitated discussion + (What worked? What didn't? Initial actions?) +- **After-action report**: Issued within [10] working days; see Template 6 +- **Corrective actions**: All actions logged in nonconformity and CA register (Template 8) +- **Report distribution**: All participants, BCMS Manager, Senior Management + +--- + +## Template 6 — Exercise After-Action Report + +*Satisfies ISO 22301:2019 Clause 8.5, 9.1. Retained as documented information.* + +--- + +**BC Exercise After-Action Report** + +| Field | Value | +|-------|-------| +| Exercise Reference | EX-BCM-[year]-[nn] | +| Exercise Name | [Name] | +| Exercise Date | [Date] | +| Report Author | [Name, Role] | +| Report Date | [Date — within 10 working days] | +| Approved by | [BCMS Manager] | + +--- + +**1. Exercise Summary** + +*Scenario used:* [Brief description] +*Participants:* [Number attended; list key roles] +*Duration:* [Start and end time] +*Plans tested:* [List] + +**2. Objectives Achievement** + +| Objective | Target | Achieved? | Notes | +|-----------|--------|-----------|-------| +| [Objective 1] | [Target] | Yes / No / Partial | [Notes] | +| [Objective 2] | [Target] | Yes / No / Partial | [Notes] | + +**3. Findings** + +*Strengths — what worked well:* +- [Finding 1] +- [Finding 2] + +*Weaknesses and gaps — what did not work as expected:* +- [Finding 1 — description, evidence, impact] +- [Finding 2] + +*Unexpected findings or near-misses:* +- [Any findings that were not anticipated but emerged during the exercise] + +**4. Action Log** + +| Action ID | Finding | Action Required | Owner | Due Date | Status | +|-----------|---------|----------------|-------|----------|--------| +| ACT-001 | [Finding] | [What must be done to address it] | [Role] | [Date] | Open | +| ACT-002 | | | | | | + +*Actions must be raised as nonconformities / corrective actions per Template 8 where required.* + +**5. Plan Update Requirements** + +| Plan / Document | Update Required | Owner | Target Date | +|-----------------|----------------|-------|-------------| +| [BCP-001] | [Description of update] | [Owner] | [Date] | + +**6. Overall Assessment** + +*Summary assessment of BCMS readiness based on exercise outcomes:* + +[Narrative assessment: e.g., "The exercise demonstrated that the CMT can be mobilised +effectively and the IT recovery team has a clear understanding of the DR procedure. +However, the exercise revealed that backup restoration has not been tested within the +stated RTO, and customer communication templates require updating. The overall BCMS +is assessed as partially effective for this scenario; targeted improvements are recommended."] + +--- + +## Template 7 — Management Review Record + +*Satisfies ISO 22301:2019 Clause 9.3. Retained as documented information.* + +--- + +**BCMS Management Review Record** + +| Field | Value | +|-------|-------| +| Review Reference | MREV-BCM-[year]-[nn] | +| Date | [Date] | +| Chair | [Name, Role — must be top management representative] | +| Attendees | [List of attendees with roles] | +| Minutes Prepared by | [Name] | +| Next Review Due | [Date — maximum 12 months] | + +--- + +**Agenda and Record** + +**Item 1 — Status of actions from previous review** +| Action | Owner | Status | Notes | +|--------|-------|--------|-------| +| [Action from previous review] | [Owner] | Complete / In Progress / Overdue | | + +**Item 2 — Changes in external and internal issues** +[Record significant changes since last review: new regulations, organisational restructuring, +new products/services, changes in risk landscape, new sites or supply chain changes] + +**Item 3 — BC performance information** + +*3a. Nonconformities and corrective actions:* +[Number of NCs raised since last review; number closed; number overdue; trend] + +*3b. Monitoring and measurement results:* +| KPI | Target | Actual | Trend | Commentary | +|-----|--------|--------|-------|------------| +| BIA currency (% reviewed within 12 months) | 100% | | | | +| Plan currency (% reviewed within 12 months) | 100% | | | | +| Exercise completion (% planned exercises completed) | 100% | | | | +| RTO achievement rate in exercises | ≥90% | | | | +| Staff training completion | 100% | | | | +| CA close-out rate | ≥90% | | | | + +*3c. Audit results:* +[Summary of internal audit findings; any external audit findings; certification status] + +*3d. Exercise results:* +[Summary of exercises conducted; key findings; actions outstanding] + +*3e. Incidents:* +[Summary of any BC plans invoked since last review; outcomes; lessons learned applied] + +**Item 4 — Adequacy of resources** +[Review whether BC team has sufficient resource (budget, headcount, tools, technology) to +maintain and improve the BCMS. Record decisions on resourcing changes.] + +**Item 5 — Effectiveness of actions to address risks and opportunities** +[Review whether actions taken since last review have been effective. Update risk register +if required.] + +**Item 6 — Opportunities for improvement** +[Record improvement ideas raised during the review] + +**Decisions and Actions** + +| Decision / Action | Owner | Due Date | +|------------------|-------|---------| +| [Decision or action as agreed] | [Role] | [Date] | + +**Approved by (Chair):** _________________________ Date: _____________ + +--- + +## Template 8 — Nonconformity and Corrective Action Record + +*Satisfies ISO 22301:2019 Clause 10.1. Retained as documented information.* + +--- + +**Nonconformity and Corrective Action Record** + +| Field | Value | +|-------|-------| +| NC Reference | NC-BCM-[year]-[nn] | +| Date Raised | [Date] | +| Raised by | [Name, Role] | +| Source | Audit / Exercise / Incident / Management Review / Internal Review | +| Related Clause | [ISO 22301 clause or internal document requirement] | +| Severity | Minor / Major | + +--- + +**Description of Nonconformity:** +[Clear statement of what was found and why it constitutes a nonconformity against the +relevant requirement. Include objective evidence.] + +**Immediate Containment Action (if applicable):** +[What was done immediately to address consequences or prevent further impact] + +**Root Cause Analysis:** +[Why did this nonconformity occur? Use appropriate root cause methodology (e.g., 5-Whys). +Do not confuse the symptom with the cause.] + +**Corrective Action:** +| Action | Owner | Due Date | Completed Date | +|--------|-------|---------|----------------| +| [Action 1] | [Role] | [Date] | | +| [Action 2] | [Role] | [Date] | | + +**Effectiveness Review:** +Date of effectiveness review: [Date — typically 30–90 days after completion] + +[Was the corrective action effective? Has the nonconformity recurred? Evidence of effectiveness:] + +**Status:** Open / Closed + +**Closed by:** [Name, Role] **Date:** [Date] + +--- + +## Template 9 — BCMS Internal Audit Plan + +*Satisfies ISO 22301:2019 Clause 9.2. Maintained documented information.* + +--- + +**BCMS Internal Audit Plan — [Year]** + +| Field | Value | +|-------|-------| +| Document Reference | AUD-BCM-[year]-01 | +| Audit Programme Owner | [BCMS Manager] | +| Audit Period | [Start date – End date] | +| Version | [x.x] | + +**Audit scope:** Full BCMS — ISO 22301:2019 Clauses 4–10 + +**Auditor independence:** Internal auditors must not audit their own work. Where BCMS Manager +is sole internal auditor, audit of BCMS management processes must be conducted by an +independent colleague or contracted third party. + +**Audit Schedule:** + +| Audit # | Clause(s) | Focus Area | Auditor | Planned Date | Status | +|---------|-----------|-----------|---------|-------------|--------| +| 1 | 4.1, 4.2, 4.3 | Context and scope | [Auditor] | [Date] | Planned | +| 2 | 5.1, 5.2, 5.3 | Leadership and policy | [Auditor] | [Date] | Planned | +| 3 | 6.1, 6.2 | Planning and objectives | [Auditor] | [Date] | Planned | +| 4 | 7.1–7.5 | Support — training, comms, documentation | [Auditor] | [Date] | Planned | +| 5 | 8.1, 8.2 | BIA and risk assessment | [Auditor] | [Date] | Planned | +| 6 | 8.3, 8.4 | BC strategy, plans, procedures | [Auditor] | [Date] | Planned | +| 7 | 8.5, 8.6 | Exercises and testing | [Auditor] | [Date] | Planned | +| 8 | 9.1, 9.2, 9.3 | Performance evaluation and management review | [Auditor] | [Date] | Planned | +| 9 | 10.1, 10.2 | Nonconformity and improvement | [Auditor] | [Date] | Planned | + +**Audit outputs:** Each audit produces an audit report summarising findings, nonconformities +(if any), and observations. Reports are submitted to the BCMS Manager and reviewed at +management review. + +--- + +## Template 10 — BC Competence Matrix + +*Satisfies ISO 22301:2019 Clause 7.2. Retained as documented information.* + +--- + +**BC Competence and Training Matrix** + +| Competency Area | Required For | Training Method | [Name 1 — Role] | [Name 2 — Role] | [Name 3 — Role] | [Name 4 — Role] | +|----------------|-------------|-----------------|-----------------|-----------------|-----------------|-----------------| +| ISO 22301:2019 overview | All BC team | Induction + annual briefing | | | | | +| BIA methodology and facilitation | BCMS Manager, BIA Facilitators | External training / internal training | | | | | +| Risk assessment methodology | BCMS Manager | External / internal | | | | | +| BCMS internal audit | Internal auditors | ISO 22301 Lead Auditor course or internal | | | | | +| Incident Commander role | Incident Commander + alternates | Tabletop exercise; crisis leadership training | | | | | +| Incident response procedures | CMT members | Annual tabletop exercise | | | | | +| BCP ownership and activation | Plan owners | Annual BCP walkthrough + exercise | | | | | +| IT DR procedures | IT Recovery team | Annual IT DR test participation | | | | | +| Crisis communications | Communications Lead | Media training; exercise participation | | | | | + +**Key:** +- C = Competent (trained and assessed as competent) +- T = Trained (training completed, competency assessment pending) +- P = Planned (training scheduled) +- N = Not yet trained +- Date = Date training last completed + +*Update this matrix following each training event. Training records must be retained as evidence.* diff --git a/plugins/iso27017/.claude-plugin/plugin.json b/plugins/iso27017/.claude-plugin/plugin.json new file mode 100644 index 0000000..68d1de7 --- /dev/null +++ b/plugins/iso27017/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "iso27017", + "description": "ISO/IEC 27017:2015 cloud security controls advisor — gap analysis, shared responsibility mapping, CSP/CSC control guidance, CLD control implementation, cloud service agreement security reviews, and virtual environment security.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "iso27017", + "cloud-security", + "cloud-controls", + "csp", + "csc", + "shared-responsibility", + "virtual-machine-security", + "iso27002", + "grc", + "compliance" + ] +} diff --git a/plugins/iso27017/skills/iso27017/SKILL.md b/plugins/iso27017/skills/iso27017/SKILL.md new file mode 100644 index 0000000..e6ed9d1 --- /dev/null +++ b/plugins/iso27017/skills/iso27017/SKILL.md @@ -0,0 +1,343 @@ +--- +name: iso27017 +description: > + Expert ISO/IEC 27017:2015 cloud security controls advisor for cloud service providers and cloud + service customers. Use this skill whenever a user asks about ISO 27017, cloud security controls, + shared responsibility in cloud environments, CSP or CSC security obligations, cloud service + agreements, virtual machine hardening, cloud tenant isolation, or implementing ISO 27002 controls + in cloud contexts. Also trigger for requests involving cloud gap analysis, cloud security + assessments, CLD controls (CLD.6.3.1, CLD.8.1.5, CLD.9.5.1, CLD.9.5.2, CLD.12.1.5, + CLD.12.4.5, CLD.13.1.4), cloud service agreement security provisions, cloud asset removal + procedures, virtual network security alignment, or cloud administrator operational security. + Trigger even if the user does not say "skill" — any ISO 27017 or cloud information security + controls question should use this skill. +--- + +# ISO/IEC 27017:2015 Cloud Security Controls Skill + +You are an expert ISO/IEC 27017 cloud security advisor assisting **cloud service providers (CSPs)**, +**cloud service customers (CSCs)**, and their **compliance and security teams**. You have deep +knowledge of ISO/IEC 27017:2015, its parent standard ISO/IEC 27002:2013, and the cloud security +controls framework it establishes. + +--- + +## Standard Overview + +| Attribute | Detail | +|-----------|--------| +| Full title | ISO/IEC 27017:2015 — Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services | +| Published | December 2015 (first edition) | +| Issuing body | ISO/IEC JTC 1/SC 27 | +| Base standard | ISO/IEC 27002:2013 (114 controls, 14 domains) | +| Cloud-specific additions | 7 additional CLD controls not present in ISO 27002 | +| Applicability | Cloud Service Providers (CSPs) and Cloud Service Customers (CSCs) | +| Companion standards | ISO/IEC 27001 (ISMS), ISO/IEC 27002 (general controls), ISO/IEC 27018 (PII in cloud) | + +**Important note on versioning**: ISO 27017:2015 is explicitly based on ISO/IEC 27002:2013. When +ISO 27002 was revised in 2022, ISO 27017 was not simultaneously updated. As of the current date, +ISO 27017:2015 remains the current edition and references the 2013 control numbering. + +--- + +## How to Respond + +Always clarify whether the user is a **CSP**, a **CSC**, or both, as guidance differs significantly +between the two roles. When not stated, ask before providing detailed control guidance. + +Match your output to the task: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Control ID \| Control Name \| Applicability (CSP/CSC/Both) \| Status \| Evidence Needed \| Gap Notes | +| Shared responsibility mapping | Table with CSP obligations \| CSC obligations \| Shared \| per service model (IaaS/PaaS/SaaS) | +| CLD control guidance | Structured: Purpose → CSP Implementation → CSC Implementation → Evidence → Audit Tips | +| Policy / document generation | Full structured document with document control block | +| Cloud service agreement review | Structured review mapping clauses to ISO 27017 requirements | +| General question | Clear, concise prose citing the relevant clause or control | + +--- + +## Standard Structure + +ISO 27017 is organised into two parts: + +### Part 1 — Cloud-Specific Implementation Guidance for ISO 27002 Controls + +ISO 27017 provides additional implementation guidance for the following 37 controls from +ISO/IEC 27002:2013. For each control, guidance is given from both CSP and CSC perspectives. + +Load `references/iso27002-cloud-guidance.md` for the full per-control cloud guidance table. + +**Controls covered (by ISO 27002 domain):** + +| Domain | Controls Covered in ISO 27017 | +|--------|-------------------------------| +| 5 — Information security policies | 5.1.1, 5.1.2 | +| 6 — Organisation of information security | 6.1.1, 6.1.2 | +| 7 — Human resource security | 7.1.1, 7.2.1, 7.2.2, 7.2.3, 7.3.1 | +| 8 — Asset management | 8.1.1, 8.1.2, 8.1.3 | +| 9 — Access control | 9.1.1, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5, 9.2.6, 9.3.1, 9.4.1, 9.4.2, 9.4.3 | +| 10 — Cryptography | 10.1.1, 10.1.2 | +| 11 — Physical and environmental security | 11.1.1, 11.2.5, 11.2.6 | +| 12 — Operations security | 12.1.1, 12.1.2, 12.1.3, 12.3.1, 12.4.1, 12.4.2, 12.4.3, 12.4.4 | +| 13 — Communications security | 13.1.1, 13.1.2, 13.1.3 | +| 14 — System acquisition, development and maintenance | 14.1.1, 14.2.5 | +| 15 — Supplier relationships | 15.1.1, 15.2.1, 15.2.2 | +| 16 — Information security incident management | 16.1.1, 16.1.2, 16.1.3, 16.1.4, 16.1.7 | +| 17 — Business continuity management | 17.1.1, 17.1.2, 17.2.1 | +| 18 — Compliance | 18.1.1, 18.1.3 | + +### Part 2 — Additional Cloud-Specific Controls (CLD) + +ISO 27017 introduces 7 new controls not present in ISO 27002, using the "CLD" prefix. + +Load `references/cloud-controls.md` for detailed guidance on all 7 CLD controls. + +| Control ID | Control Name | Applicability | +|------------|-------------|---------------| +| CLD.6.3.1 | Shared roles and responsibilities within a cloud computing environment | Both | +| CLD.8.1.5 | Removal or return of cloud service customer assets | Both | +| CLD.9.5.1 | Segregation in virtual computing environments | CSP | +| CLD.9.5.2 | Virtual machine hardening | Both | +| CLD.12.1.5 | Administrator's operational security | CSP | +| CLD.12.4.5 | Monitoring of cloud services | Both | +| CLD.13.1.4 | Alignment of security management for virtual and physical networks | CSP | + +--- + +## Core Concepts + +### Shared Responsibility Model + +ISO 27017 explicitly addresses the shared responsibility between CSPs and CSCs. The split of +responsibilities depends on the cloud service model: + +| Security Responsibility | IaaS | PaaS | SaaS | +|------------------------|------|------|------| +| Physical infrastructure | CSP | CSP | CSP | +| Network infrastructure | CSP | CSP | CSP | +| Hypervisor / virtualisation | CSP | CSP | CSP | +| Operating system | CSC | CSP | CSP | +| Runtime / middleware | CSC | CSP | CSP | +| Application code | CSC | CSC | CSP | +| Application configuration | CSC | CSC | CSC | +| Identity and access management | Shared | Shared | Shared | +| Data classification and protection | CSC | CSC | CSC | +| Encryption of data in transit | Shared | Shared | Shared | +| Encryption of data at rest | CSC | Shared | Shared | +| Incident response | Shared | Shared | Shared | +| Compliance | Shared | Shared | Shared | + +Load `references/shared-responsibility.md` for the detailed per-control shared responsibility matrix. + +### Cloud Service Agreement (CSA) + +A Cloud Service Agreement must address the following security aspects per ISO 27017: + +- The confidentiality, integrity, and availability requirements of the cloud service +- Security-related roles and responsibilities of each party +- Incident notification and response procedures +- Data handling, return, and deletion procedures +- Right to audit or assess compliance +- Sub-processor / sub-service provider restrictions +- Applicable laws and jurisdiction +- Encryption and key management responsibilities +- Business continuity and disaster recovery provisions + +### Cloud Service Categories + +| Category | Definition | Key ISO 27017 Considerations | +|----------|-----------|------------------------------| +| IaaS (Infrastructure as a Service) | CSP provides compute, storage, network; CSC manages OS and above | CSC has more responsibility; CLD.9.5.2 (VM hardening) applies heavily to CSC | +| PaaS (Platform as a Service) | CSP provides platform including OS and runtime; CSC manages applications and data | Shared stack; CLD.12.1.5 (admin security) applies heavily to CSP | +| SaaS (Software as a Service) | CSP manages entire stack; CSC consumes the application | CSP bears most responsibility; CSC manages user access and data inputs | + +--- + +## Core Workflows + +### 1. Gap Analysis + +When asked to perform a gap analysis: +1. Ask for: cloud service model (IaaS/PaaS/SaaS), role (CSP/CSC/both), organisation type +2. Load `references/iso27002-cloud-guidance.md` and `references/cloud-controls.md` +3. Produce a table covering all 37 ISO 27002 controls with cloud guidance + all 7 CLD controls +4. For each item: **Applicability** (CSP/CSC/Both), **Status** (Implemented/Partial/Not Implemented/N/A), **Evidence Needed**, **Gap Notes** +5. Summarise critical gaps with recommended priority order +6. Offer to generate a remediation roadmap or supporting policy + +**Status definitions:** +- Implemented — control is fully in place with documented evidence +- Partial — some evidence exists but gaps remain +- Not Implemented — no evidence of implementation +- N/A — does not apply to this service model or role; document justification + +**Gap Analysis Output Template:** + +``` +## ISO 27017 Cloud Security Gap Analysis + +**Organisation:** [Name] +**Role:** [CSP / CSC / Both] +**Service Model:** [IaaS / PaaS / SaaS] +**Assessment Date:** [Date] +**Assessed By:** [Name/Team] + +### CLD Controls (Cloud-Specific) + +| Control | Name | Applicability | Status | Evidence Needed | Gap Notes | +|---------|------|---------------|--------|-----------------|-----------| +| CLD.6.3.1 | Shared roles and responsibilities | Both | [Status] | Documented RACI, CSA clause | [Notes] | +| CLD.8.1.5 | Removal or return of assets | Both | [Status] | Data deletion procedure, CSA clause | [Notes] | +| CLD.9.5.1 | Segregation in virtual environments | CSP | [Status] | Hypervisor isolation evidence | [Notes] | +| CLD.9.5.2 | Virtual machine hardening | Both | [Status] | VM hardening standard, scan results | [Notes] | +| CLD.12.1.5 | Administrator's operational security | CSP | [Status] | Admin access logs, MFA evidence | [Notes] | +| CLD.12.4.5 | Monitoring of cloud services | Both | [Status] | Monitoring reports, dashboards | [Notes] | +| CLD.13.1.4 | Virtual/physical network alignment | CSP | [Status] | Network security policy, architecture docs | [Notes] | + +### ISO 27002 Controls with Cloud-Specific Guidance +[Full table of 37 controls — generated from references/iso27002-cloud-guidance.md] + +### Summary +**Critical Gaps (immediate action required):** [List] +**High Priority (address within 30 days):** [List] +**Medium Priority (address within 90 days):** [List] +``` + +### 2. Cloud Service Agreement (CSA) Review + +When reviewing a cloud service agreement: +1. Load `references/templates.md` for the CSA security requirements checklist +2. Map each security clause in the agreement against ISO 27017 requirements +3. Identify missing provisions and recommend specific clause language +4. Produce a structured findings report: + +``` +## Cloud Service Agreement Security Review + +**Parties:** [CSP Name] / [CSC Name] +**Service Type:** [IaaS/PaaS/SaaS — description] +**Review Date:** [Date] + +### Required Security Provisions (ISO 27017) +| Requirement | ISO 27017 Reference | Present in CSA | Compliant | Notes | +|-------------|--------------------|--------------------|-----------|-------| +| Shared responsibility definition | CLD.6.3.1 | Yes/No | Yes/No | | +| Data return/deletion procedure | CLD.8.1.5 | Yes/No | Yes/No | | +| Incident notification timeline | 16.1.2 | Yes/No | Yes/No | | +| [Continue for all requirements...] | | | | | + +### Missing Provisions +[List of absent requirements with recommended clause language] + +### Compliant Elements +[List of clauses that satisfy ISO 27017 requirements] +``` + +### 3. CLD Control Implementation Guidance + +For any CLD control, structure your response as: + +**Control: [ID] [Name]** +- **Purpose**: Why this control exists in the cloud context +- **CSP Implementation**: Concrete, actionable steps for cloud service providers +- **CSC Implementation**: Concrete, actionable steps for cloud service customers +- **Evidence for audit**: What an auditor will look for +- **Common pitfalls**: What teams typically miss +- **Relationship to ISO 27002**: Which base ISO 27002 clause this supplements + +Consult `references/cloud-controls.md` for full CLD control descriptions. + +### 4. Policy and Document Generation + +When generating policies or documents: +- Include: Purpose, Scope, Policy Statement, Roles and Responsibilities, Procedures/Controls, Review Cycle, References +- Map each policy to the relevant ISO 27017 clause(s) and underlying ISO 27002 control(s) +- Include a document control block: Version | Author | Approved By | Date | Next Review +- Label each provision with whether it applies to CSP, CSC, or both + +**Common policy types for ISO 27017:** + +| Policy | Primary ISO 27017 Reference | Notes | +|--------|-----------------------------|-------| +| Cloud Security Policy | 5.1.1, CLD.6.3.1 | Covers cloud-specific IS obligations | +| Cloud Asset Management Policy | 8.1.1, 8.1.2, CLD.8.1.5 | Covers cloud asset inventory and return | +| Cloud Access Control Policy | 9.1.1, 9.2.1–9.2.6, CLD.9.5.1 | Covers identity, access, and tenant isolation | +| Virtual Machine Hardening Standard | CLD.9.5.2 | VM configuration baseline | +| Cloud Operations Security Policy | 12.1.1, CLD.12.1.5, CLD.12.4.5 | Admin operations and monitoring | +| Cloud Incident Response Plan | 16.1.1, 16.1.2 | Cloud-specific incident notification | +| Cloud Business Continuity Plan | 17.1.1, 17.1.2, 17.2.1 | Cloud service continuity | +| Cloud Supplier Management Policy | 15.1.1, 15.2.1 | Sub-service providers and supply chain | + +### 5. Shared Responsibility Assessment + +When helping a CSC understand what they must manage themselves: +1. Ask for: cloud service model (IaaS/PaaS/SaaS), specific service (if known) +2. Load `references/shared-responsibility.md` +3. Produce a RACI-style table covering all applicable ISO 27017 controls +4. Highlight areas where the CSC has full responsibility and cannot rely on the CSP +5. Recommend compensating controls where CSP capabilities are limited + +--- + +## Mandatory Documentation Checklist + +Produce this checklist when asked for an ISO 27017 compliance readiness assessment: + +**For Cloud Service Providers (CSPs):** +- [ ] Shared responsibility documentation (CLD.6.3.1) +- [ ] Documented cloud service agreement security provisions including data return and deletion procedures (CLD.8.1.5) +- [ ] Hypervisor and virtual environment isolation architecture (CLD.9.5.1) +- [ ] VM hardening baseline and verification evidence (CLD.9.5.2) +- [ ] Privileged administrator access controls, MFA, and activity logging (CLD.12.1.5) +- [ ] Cloud service monitoring and reporting capability (CLD.12.4.5) +- [ ] Virtual network and physical network security policy alignment (CLD.13.1.4) +- [ ] Cloud-specific information security policy (5.1.1) +- [ ] Asset inventory covering all cloud service components (8.1.1) +- [ ] Multi-tenant access control and tenant isolation evidence (9.1.1, CLD.9.5.1) +- [ ] Cryptographic key management for cloud-hosted data (10.1.1, 10.1.2) +- [ ] Physical data centre security documentation (11.1.1) +- [ ] Cloud incident response plan and notification procedures (16.1.1, 16.1.2) +- [ ] Business continuity provisions for cloud services (17.1.1, 17.2.1) +- [ ] Sub-service provider security agreements (15.1.1) + +**For Cloud Service Customers (CSCs):** +- [ ] Documented understanding of shared responsibilities with CSP (CLD.6.3.1) +- [ ] Cloud asset inventory and classification (8.1.1, 8.1.2) +- [ ] Data return and deletion procedures agreed with CSP (CLD.8.1.5) +- [ ] Cloud access control policy covering identity, MFA, and privileged access (9.1.1–9.2.6) +- [ ] VM hardening standards for CSC-managed virtual machines (CLD.9.5.2) +- [ ] Cloud service usage monitoring and alerting (CLD.12.4.5) +- [ ] Cloud service backup and recovery testing evidence (12.3.1) +- [ ] Cloud incident detection and response capability (16.1.1) +- [ ] Encryption policy for data stored and transmitted via cloud (10.1.1) +- [ ] Cloud supplier due diligence and contractual security review (15.1.1) +- [ ] Regulatory compliance assessment for cloud-hosted data (18.1.1) + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +| File | When to load | +|------|-------------| +| `references/cloud-controls.md` | Detailed guidance on the 7 CLD cloud-specific controls | +| `references/iso27002-cloud-guidance.md` | ISO 27002 controls covered by ISO 27017 with CSP/CSC implementation notes | +| `references/shared-responsibility.md` | Shared responsibility matrix by service model and control area | +| `references/templates.md` | CSA security checklist, gap analysis template, policy document templates | + +Load **all relevant files** for broad requests (e.g., "perform a full ISO 27017 assessment"). + +--- + +## Important Caveats + +- ISO 27017 is a **code of practice** (not a certifiable standard in its own right). Organisations + are certified against ISO 27001; ISO 27017 provides supplemental implementation guidance. +- ISO 27017 does not replace ISO 27001 or ISO 27002 — it supplements them for cloud environments. +- The standard is explicitly based on ISO/IEC 27002:2013. Control numbering in this skill uses + the 2013 scheme (A.x.x). Cross-reference `references/iso27002-cloud-guidance.md` for details. +- Always recommend professional legal and compliance review before finalising cloud service + agreements or compliance submissions. diff --git a/plugins/iso27017/skills/iso27017/references/cloud-controls.md b/plugins/iso27017/skills/iso27017/references/cloud-controls.md new file mode 100644 index 0000000..683f919 --- /dev/null +++ b/plugins/iso27017/skills/iso27017/references/cloud-controls.md @@ -0,0 +1,379 @@ +# ISO/IEC 27017:2015 — Cloud-Specific Controls (CLD) + +ISO/IEC 27017:2015 introduces 7 additional controls not present in ISO/IEC 27002:2013. These +controls are prefixed with "CLD" and address security aspects unique to cloud computing +environments. They are intended to be implemented alongside the base ISO 27002 controls. + +--- + +## CLD.6.3.1 — Shared Roles and Responsibilities Within a Cloud Computing Environment + +**Category**: Organisation of Information Security (extends ISO 27002 clause 6) +**Applicability**: Both CSP and CSC + +### Purpose +Ensure that the allocation of information security responsibilities between the cloud service +provider and cloud service customer is clearly defined, agreed, and communicated, so that no +security obligations go unaddressed. + +### The Problem This Solves +Without explicit shared responsibility documentation, both the CSP and CSC may assume the other +party is managing a given control, resulting in security gaps. This is one of the most common +causes of cloud security incidents. + +### CSP Implementation Requirements +- Publish and maintain a clear description of the information security responsibilities that + remain with the CSC versus those managed by the CSP +- Make this responsibility breakdown available as part of the service documentation and cloud + service agreement (CSA) +- Distinguish responsibilities by service model (IaaS, PaaS, SaaS) where different services + are offered +- Update the responsibility documentation when service features or security capabilities change +- Provide the CSC with sufficient information to implement the responsibilities that fall to them + +### CSC Implementation Requirements +- Review and formally acknowledge the CSP's shared responsibility documentation +- Document the specific security controls the CSC is responsible for implementing +- Create an internal RACI that maps ISO 27017 / ISO 27002 controls to the CSP-provided breakdown +- Include shared responsibility provisions in any internal security policy that references + cloud services +- Reassess the shared responsibility model when changing cloud service tier, provider, or scope + +### Cloud Service Agreement Provision Required +The CSA must include a clause that explicitly identifies which information security obligations +rest with the CSP, which rest with the CSC, and which are shared. This must be specific, not +a general disclaimer. + +### Evidence Required for Audit +- Shared responsibility matrix or documentation (published by CSP, acknowledged by CSC) +- CSA clause explicitly defining security obligations of each party +- Internal CSC RACI or control ownership register mapped to cloud controls +- Evidence of CSC review and acceptance of the responsibility breakdown + +### Common Pitfalls +- Assuming the CSP's generic Terms of Service constitutes a shared responsibility agreement +- Not reviewing shared responsibility when moving between IaaS and SaaS +- CSC assuming the CSP manages access control (CSC always owns IAM for user accounts) +- No formal CSC process to acknowledge and act on the CSP responsibility split + +--- + +## CLD.8.1.5 — Removal or Return of Cloud Service Customer Assets + +**Category**: Asset Management (extends ISO 27002 clause 8.1) +**Applicability**: Both CSP and CSC + +### Purpose +Ensure that when a cloud service is terminated, or when assets (including data) belonging to the +CSC need to be transferred or deleted, this is performed completely, verifiably, and in a +format the CSC can use. + +### CSP Implementation Requirements +- Provide the CSC with the technical capability to retrieve all its data in a usable, standard + format before and during service termination +- Define a documented procedure for the return of CSC assets, covering: the format of data + export, the timeline, and the method of delivery +- After confirmed successful retrieval by the CSC, securely delete all copies of the CSC's + data from all CSP systems (including backups and replicated copies) +- Issue a certificate of destruction or deletion on request +- Communicate the data return and deletion procedure to the CSC in the CSA +- Specify the retention period for CSC data after service termination and what happens upon + expiry of that period + +### CSC Implementation Requirements +- Maintain an inventory of all data and assets stored with the CSP +- Document the procedure for retrieving assets from each CSP in use +- Include data return and deletion provisions in every cloud service agreement +- Verify, prior to terminating a service, that all required data has been retrieved and + validated +- Obtain and retain written confirmation (certificate of deletion) from the CSP that data has + been destroyed +- Ensure the data retrieval format is compatible with the CSC's systems or import capabilities + +### Cloud Service Agreement Provision Required +The CSA must specify: +- The format in which data will be returned to the CSC +- The timeline for data return following termination notice +- The method and timeline for confirmed deletion of CSC data +- Whether backups and archived copies are included in deletion +- Responsibility for migration costs + +### Evidence Required for Audit +- CSA clause covering data return and deletion +- CSP data deletion procedure documentation +- CSC data retrieval test records +- Certificate of destruction for any terminated service +- CSC asset inventory showing data stored with cloud providers + +### Common Pitfalls +- Assuming data stored in cloud is automatically deleted when an account is closed +- Not verifying deletion of backup or archived copies +- Data locked in proprietary formats that cannot be exported +- No clause in CSA defining the timeline for data deletion after termination +- CSC retaining data with a CSP after service termination without documented justification + +--- + +## CLD.9.5.1 — Segregation in Virtual Computing Environments + +**Category**: Access Control (extends ISO 27002 clause 9.4 — multi-tenancy context) +**Applicability**: CSP (primary); CSC (where managing their own multi-tenant environments) + +### Purpose +Ensure that the virtual computing resources of different cloud service customers (tenants) are +isolated from each other, and from the CSP's own management infrastructure, so that one +tenant cannot access, disrupt, or observe another tenant's data or operations. + +### The Multi-Tenancy Risk +In multi-tenant cloud environments, multiple customers share the same underlying physical +infrastructure. Without proper isolation, a vulnerability in the virtualisation layer +(hypervisor, virtual network, or storage) could allow one tenant to access another's data. + +### CSP Implementation Requirements +- Implement logical isolation between all tenants at every layer: compute (hypervisor / VM), + storage, and network virtualisation +- Use hypervisor-level isolation to prevent VMs belonging to different tenants from accessing + each other's memory, storage, or CPU resources +- Implement virtual network segmentation (VLANs, SDN, or overlay networks) to prevent + inter-tenant network traffic +- Apply access controls ensuring CSP administrators cannot access tenant data without + authorisation and audit trail +- Conduct regular security testing (including penetration testing) of virtualisation and + isolation mechanisms +- Apply patches to hypervisors and virtualisation platforms promptly, particularly for + vulnerabilities that could enable VM escape +- Document the isolation architecture and make architecture summaries available to CSCs + (without disclosing details that would assist attackers) +- Implement storage isolation to prevent one tenant's data being accessible from another + tenant's storage volumes + +### Evidence Required for Audit +- Virtual environment architecture documentation showing isolation design +- Hypervisor patch management records +- Penetration testing reports covering virtualisation boundary testing +- Access control records for CSP administrator access to tenant environments +- Network segmentation diagrams showing tenant isolation + +### Common Pitfalls +- Misconfigured hypervisors that allow VM-escape or cross-tenant memory access +- Shared storage volumes without encryption or access boundary enforcement +- Failure to patch hypervisors promptly when virtualisation vulnerabilities are disclosed +- CSP administrators having broad access to all tenant data without role-based restrictions +- Insufficient testing of isolation mechanisms after infrastructure changes + +--- + +## CLD.9.5.2 — Virtual Machine Hardening + +**Category**: Access Control / Operations Security (extends ISO 27002 clause 9 and 12) +**Applicability**: Both CSP and CSC + +### Purpose +Ensure that virtual machines (VMs) are configured securely to minimise the attack surface and +reduce the risk of compromise within the cloud environment. + +### CSP Implementation Requirements (for CSP-managed VMs and base images) +- Develop and maintain hardened base images for any VMs or images provided to CSCs +- Ensure hardened images include: unnecessary services and ports disabled, security patches + applied, secure default configurations, logging enabled +- Provide guidance to CSCs on hardening VMs that CSCs deploy +- Apply VM hardening standards to CSP's own management and infrastructure VMs +- Monitor for CSC-deployed VMs that deviate significantly from hardening baselines + (where technically and contractually possible) + +### CSC Implementation Requirements (for CSC-managed VMs) +- Develop and enforce a VM hardening standard covering: + - Removal or disabling of unnecessary operating system features and services + - Application of all available security patches before and after deployment + - Firewall and host-based intrusion detection configuration + - Enabled audit logging for security events + - Encrypted storage volumes for sensitive data + - Disabled or changed default credentials + - Use of approved and hardened OS images as baselines +- Apply the hardening standard to all CSC-deployed VMs before they are connected to + production networks +- Re-apply hardening during major OS or application updates +- Conduct periodic vulnerability scanning of deployed VMs +- Remediate identified vulnerabilities within risk-based timescales + +### Evidence Required for Audit +- VM hardening standard document +- Evidence of hardening applied to production VMs (configuration baseline comparison) +- Vulnerability scanning results and remediation records +- Patch management records for VM operating systems +- Base image management records (CSP-side) + +### Common Pitfalls +- Deploying community cloud images without reviewing their security configuration +- Not disabling default credentials on newly deployed VMs +- VMs with open management ports (SSH, RDP) exposed to the public internet +- Snapshot-based recovery that restores a VM to a pre-patch state +- No periodic re-assessment of hardening compliance on running VMs + +--- + +## CLD.12.1.5 — Administrator's Operational Security + +**Category**: Operations Security (extends ISO 27002 clause 12.1) +**Applicability**: CSP (primary); applicable to CSC administrators managing cloud resources + +### Purpose +Ensure that cloud service administrator activities are performed under strict operational +security controls to prevent accidental or malicious misuse of privileged access to cloud +infrastructure and tenant data. + +### CSP Implementation Requirements +- Implement multi-factor authentication (MFA) for all cloud service administrator accounts +- Apply the principle of least privilege: each administrator account is granted only the + access required for their specific role +- Implement role-based access control (RBAC) separating administrative functions + (e.g., separate roles for: infrastructure admin, security admin, customer support admin) +- Ensure all administrative activities are fully logged, including: login/logout events, + privileged commands executed, data accessed, configuration changes made +- Protect administrator logs from modification or deletion by the administrators themselves +- Implement a separate, hardened management network or jump server for administrative access + to cloud infrastructure; production systems should not be administered from general user + networks +- Require formal approval and documented authorisation for any administrative access to + customer (CSC) data or environments +- Conduct periodic review and recertification of administrator access rights +- Train administrators in secure operational practices and social engineering awareness + +### CSC Implementation Requirements +- Apply equivalent privileged access controls for CSC cloud administrators +- Enforce MFA for all CSC user accounts with administrative privileges in cloud environments +- Implement just-in-time (JIT) access or time-limited privilege elevation where possible +- Audit administrator activities in cloud management consoles + +### Evidence Required for Audit +- MFA enforcement records for administrator accounts +- RBAC configuration showing least privilege assignment +- Administrator access logs with evidence of protection from tampering +- Access approval records for customer data access +- Management network / jump server architecture documentation +- Access recertification records + +### Common Pitfalls +- Shared administrator accounts (no individual accountability) +- Administrator access to production environments from developer or general workstations +- Absence of MFA on highly privileged accounts +- Administrator logs that can be cleared by the same administrators being logged +- No requirement for formal approval before a CSP administrator accesses a CSC environment +- Excessive standing/permanent privileged access rather than just-in-time access + +--- + +## CLD.12.4.5 — Monitoring of Cloud Services + +**Category**: Operations Security (extends ISO 27002 clause 12.4) +**Applicability**: Both CSP and CSC + +### Purpose +Ensure that cloud services are monitored to detect security-relevant events, operational +anomalies, and performance issues, and that monitoring information is made available to the +CSC as required. + +### CSP Implementation Requirements +- Implement comprehensive monitoring of the cloud service covering: availability, performance, + capacity, security events (authentication failures, anomalous access patterns, privilege + escalation), and infrastructure health +- Ensure that security event monitoring is continuous and automated +- Retain monitoring logs for a period defined in the CSA and consistent with applicable + regulatory requirements +- Make available to the CSC, on request or via self-service dashboards, monitoring data + related to the CSC's use of the service, including security events affecting the CSC +- Define and communicate to the CSC: what is monitored, what events will generate alerts, and + what information will be proactively reported versus available on request +- Include monitoring provisions in the CSA + +### CSC Implementation Requirements +- Implement monitoring of the CSC's own use of cloud services, including: + - User account activity and authentication events + - Data access patterns and anomalous queries + - Configuration changes to cloud resources + - API call volumes and unusual patterns +- Integrate CSP-provided monitoring feeds with the CSC's own security information and event + management (SIEM) system where available +- Define alerts and thresholds for cloud-specific events (e.g., unusual data export volumes, + privilege changes, new admin account creation) +- Review monitoring reports from the CSP at scheduled intervals and upon security incidents +- Retain CSC-side monitoring data for a period consistent with the CSC's incident response + and regulatory requirements + +### Evidence Required for Audit +- CSP monitoring architecture and description of what is monitored +- CSA clause defining monitoring data availability to the CSC +- CSP monitoring reports or dashboard access records +- CSC SIEM integration or monitoring configuration for cloud services +- CSC alert configuration and review records + +### Common Pitfalls +- CSC assuming the CSP monitors all security events relevant to the CSC +- No integration between CSP-provided logs and the CSC's internal SIEM +- Cloud API activity logs (e.g., AWS CloudTrail, Azure Activity Log) not enabled by the CSC +- CSP monitoring log retention period shorter than the CSC's incident investigation window +- No process for the CSC to request specific monitoring data from the CSP + +--- + +## CLD.13.1.4 — Alignment of Security Management for Virtual and Physical Networks + +**Category**: Communications Security (extends ISO 27002 clause 13.1) +**Applicability**: CSP (primary) + +### Purpose +Ensure that the security controls applied to virtual networks in a cloud environment are +consistent with (and aligned to) the security controls applied to physical networks, so that +the introduction of virtualisation does not reduce the overall network security posture. + +### CSP Implementation Requirements +- Define network security policies that explicitly cover both physical and virtual network + layers +- Apply equivalent security controls to virtual networks as are required for physical networks, + including: network segmentation, traffic filtering (firewalls/ACLs), intrusion detection, + flow logging, and access controls +- Ensure virtual network security configurations are subject to the same change management + and security review processes as physical network changes +- Implement traffic inspection and filtering between virtual network segments, including + east-west (inter-VM) traffic within the same virtual network where applicable +- Maintain visibility of virtual network topology to the same degree as physical network + topology (network documentation and asset inventory) +- Audit virtual network security configurations periodically against the security policy +- Ensure that virtual networks cannot be created or reconfigured in ways that bypass + established security controls (e.g., VMs directly bridging to external networks) + +### CSC Considerations +- Where the CSC configures virtual networks (e.g., in IaaS), apply equivalent security + controls to those used in the CSC's physical network environment +- Use cloud-native network security features (security groups, network ACLs, virtual firewalls) + to implement network segmentation equivalent to physical environment controls +- Review virtual network security configurations regularly and when architecture changes occur + +### Evidence Required for Audit +- Network security policy covering both physical and virtual layers +- Virtual network architecture and configuration documentation +- Evidence of change management applied to virtual network configuration changes +- Audit results for virtual network security configurations +- Traffic logging and inspection evidence for virtual network segments + +### Common Pitfalls +- Assuming default virtual network configurations are secure +- No firewall rules applied between virtual machine segments on the same virtual network +- Virtual network changes bypassing the change management process +- VMs able to create new virtual network interfaces without security review +- No logging of virtual network traffic flows (equivalent to physical NetFlow/sFlow monitoring) +- CSC creating "flat" virtual networks with no internal segmentation + +--- + +## Summary Reference Table + +| Control ID | Name | CSP | CSC | Key Requirement | +|------------|------|-----|-----|-----------------| +| CLD.6.3.1 | Shared roles and responsibilities | Required | Required | Documented shared responsibility; CSA clause | +| CLD.8.1.5 | Removal or return of assets | Required | Required | Data return format; certified deletion | +| CLD.9.5.1 | Segregation in virtual environments | Required | N/A (unless multi-tenant CSC) | Hypervisor/network tenant isolation | +| CLD.9.5.2 | Virtual machine hardening | Required (base images) | Required (CSC VMs) | Hardening standard; patch management | +| CLD.12.1.5 | Administrator's operational security | Required | Recommended | MFA; least privilege; admin logging | +| CLD.12.4.5 | Monitoring of cloud services | Required | Required | Monitoring provision; CSC data access | +| CLD.13.1.4 | Virtual/physical network alignment | Required | Recommended | Consistent controls across both layers | diff --git a/plugins/iso27017/skills/iso27017/references/iso27002-cloud-guidance.md b/plugins/iso27017/skills/iso27017/references/iso27002-cloud-guidance.md new file mode 100644 index 0000000..e7bf160 --- /dev/null +++ b/plugins/iso27017/skills/iso27017/references/iso27002-cloud-guidance.md @@ -0,0 +1,796 @@ +# ISO/IEC 27017:2015 — ISO 27002 Controls with Cloud-Specific Guidance + +ISO/IEC 27017:2015 provides additional implementation guidance for 37 controls from +ISO/IEC 27002:2013, tailored for cloud computing environments. For each applicable control, +guidance is provided from both the Cloud Service Provider (CSP) and Cloud Service Customer +(CSC) perspectives. + +The control numbering follows ISO/IEC 27002:2013 (the version this standard is based on). + +--- + +## Domain 5 — Information Security Policies + +### 5.1.1 — Policies for Information Security + +**CSP Guidance** +- Develop and publish cloud-specific information security policies that address the unique + characteristics of the cloud environment +- Policies must cover: multi-tenancy, virtualisation security, data sovereignty, third-party + sub-service provider management, and shared responsibility +- Make a summary of the security policy available to CSCs as part of service documentation + +**CSC Guidance** +- Update existing information security policies to explicitly address the use of cloud services +- Include provisions for: approved cloud service use, data classification before cloud upload, + identity and access management in cloud environments, and monitoring of cloud activity +- Ensure policies are reviewed when new cloud services are adopted or existing services change + +--- + +### 5.1.2 — Review of the Policies for Information Security + +**CSP Guidance** +- Trigger policy review when there are significant changes to the cloud service architecture, + new regulatory requirements applicable to cloud, or major security incidents + +**CSC Guidance** +- Include review triggers for changes in cloud service providers, changes in service scope, + and new regulatory requirements affecting cloud-stored data + +--- + +## Domain 6 — Organisation of Information Security + +### 6.1.1 — Information Security Roles and Responsibilities + +**CSP Guidance** +- Clearly define and publish the roles and responsibilities of CSP personnel in maintaining + the security of the cloud service, including: infrastructure team, operations team, security + team, and customer support +- Define escalation paths for security incidents involving CSC environments + +**CSC Guidance** +- Define roles and responsibilities for cloud service management within the CSC organisation: + cloud administrator, data owner, security officer, and end users +- Document who is responsible for each control in the shared responsibility model + +**Note**: See CLD.6.3.1 for the additional cloud-specific shared responsibility control. + +--- + +### 6.1.2 — Segregation of Duties + +**CSP Guidance** +- Separate duties between: infrastructure administrators, security operations, customer + support (accessing CSC environments), and finance/billing +- Prevent a single individual from both deploying cloud infrastructure and auditing that + infrastructure's security + +**CSC Guidance** +- Separate cloud administration duties from security monitoring duties +- Ensure that users who can grant cloud access cannot also approve that grant themselves + +--- + +## Domain 7 — Human Resource Security + +### 7.1.1 — Screening + +**CSP Guidance** +- Apply appropriate background checks to all personnel who have access to cloud infrastructure, + CSC data, or privileged management interfaces +- Apply enhanced screening for roles with direct access to multi-tenant management systems + +**CSC Guidance** +- Ensure personnel who administer cloud services on behalf of the CSC are appropriately vetted + +--- + +### 7.2.1 — Management Responsibilities + +**CSP Guidance** +- Require managers to ensure all staff with cloud infrastructure or CSC data access understand + and comply with cloud security policies + +**CSC Guidance** +- Require managers to ensure cloud users are trained on the CSC's cloud usage policies and + understand the risks of cloud misuse or misconfiguration + +--- + +### 7.2.2 — Information Security Awareness, Education and Training + +**CSP Guidance** +- Provide cloud-specific security training to all personnel, covering: virtualisation security, + multi-tenancy risks, secure cloud operations, and handling of CSC data + +**CSC Guidance** +- Train all cloud users on: approved cloud services, data classification for cloud upload, + recognising phishing attacks targeting cloud credentials, and incident reporting + +--- + +### 7.2.3 — Disciplinary Process + +**CSP Guidance** +- Ensure the disciplinary process specifically addresses unauthorised access to CSC + environments and mishandling of CSC data + +**CSC Guidance** +- Ensure the disciplinary process addresses unauthorised use of unapproved cloud services + (shadow IT) and sharing of cloud credentials + +--- + +### 7.3.1 — Termination or Change of Employment Responsibilities + +**CSP Guidance** +- Immediately revoke access to cloud management interfaces, privileged management tools, + and CSC environment access upon termination or role change +- Ensure former employees cannot retain software, credentials, or data relating to CSC + environments + +**CSC Guidance** +- Immediately revoke cloud service access and credentials for departing employees +- Review cloud service access permissions when employees change roles and no longer require + prior access levels + +--- + +## Domain 8 — Asset Management + +### 8.1.1 — Inventory of Assets + +**CSP Guidance** +- Maintain a comprehensive inventory of all cloud service assets including: physical servers, + virtual machines, storage systems, network equipment, and software components +- Track the versions and patch status of all components as part of the inventory + +**CSC Guidance** +- Maintain an inventory of all assets (data, systems, accounts) hosted with each cloud + service provider +- Track: data categories stored, volumes, retention periods required, and associated + regulatory obligations + +**Note**: See CLD.8.1.5 for the additional control on removal or return of CSC assets. + +--- + +### 8.1.2 — Ownership of Assets + +**CSP Guidance** +- Clearly document that CSC data stored in the cloud remains the property of the CSC +- Include a data ownership clause in the CSA + +**CSC Guidance** +- Assert and document ownership of all data uploaded to cloud services +- Ensure CSA includes explicit confirmation that the CSP holds data only as a processor and + acknowledges CSC ownership + +--- + +### 8.1.3 — Acceptable Use of Assets + +**CSP Guidance** +- Define and publish acceptable use policies for the cloud service, including what types of + data are permitted and any restrictions on use cases (e.g., restrictions on processing of + particularly sensitive data categories unless specifically contracted) + +**CSC Guidance** +- Establish an acceptable use policy for cloud services describing: permitted data types for + cloud storage, prohibited uses, and user responsibilities for data handling + +--- + +## Domain 9 — Access Control + +### 9.1.1 — Access Control Policy + +**CSP Guidance** +- Implement access control policies that enforce tenant isolation: a CSC's users must not be + able to access another CSC's resources under any circumstances +- Document the access control model and make it available to CSCs in service documentation + +**CSC Guidance** +- Develop a cloud-specific access control policy that governs: who can access which cloud + resources, roles and least privilege principles, and required authentication methods +- Map the policy to the shared responsibility model to confirm which access controls are + CSC-managed versus CSP-enforced + +--- + +### 9.2.1 — User Registration and De-Registration + +**CSP Guidance** +- Implement self-service or API-based provisioning that allows CSCs to manage their own user + accounts without requiring CSP administrator intervention for routine operations +- Ensure CSC administrators can immediately de-register users when required + +**CSC Guidance** +- Implement formal processes for creating and removing cloud user accounts, including: + approval workflow, provisioning with least-privilege defaults, and immediate deprovisioning + upon role change or departure + +--- + +### 9.2.2 — User Access Provisioning + +**CSP Guidance** +- Provide role-based access control (RBAC) capabilities to CSCs so they can assign granular + permissions to their users +- Document available access roles and their associated permissions in CSP documentation + +**CSC Guidance** +- Assign cloud access rights based on defined roles and minimum necessary access +- Review cloud service access provisioning requests against documented role definitions + +--- + +### 9.2.3 — Management of Privileged Access Rights + +**CSP Guidance** +- Restrict and log all privileged access to cloud management interfaces +- Require explicit approval for any CSP administrator action that involves accessing CSC + environments or data (see also CLD.12.1.5) + +**CSC Guidance** +- Limit the number of cloud administrator accounts to the minimum necessary +- Apply enhanced controls to privileged cloud accounts: MFA, just-in-time access, and + enhanced logging + +--- + +### 9.2.4 — Management of Secret Authentication Information of Users + +**CSP Guidance** +- Enforce strong password policies or passwordless authentication for cloud management + console access +- Never store CSC user passwords in recoverable form + +**CSC Guidance** +- Enforce strong passwords or MFA for all cloud service user accounts +- Require immediate rotation of cloud service credentials in the event of actual or suspected + compromise + +--- + +### 9.2.5 — Review of User Access Rights + +**CSP Guidance** +- Provide CSCs with tooling (reports, dashboards) to enable periodic review of their users' + access rights + +**CSC Guidance** +- Conduct periodic reviews (at least annually, more frequently for privileged accounts) of + all cloud service user access rights +- Remove or downgrade access where users no longer require it + +--- + +### 9.2.6 — Removal or Adjustment of Access Rights + +**CSP Guidance** +- Provide CSCs with the immediate ability to remove or modify user access rights at any time + +**CSC Guidance** +- Implement processes to remove or adjust cloud access rights immediately upon role change + or departure, with no dependency on deprovisioning through the HR lifecycle alone + +--- + +### 9.3.1 — Use of Secret Authentication Information + +**CSP Guidance** +- Instruct CSC users (via documentation) not to share cloud service credentials and to use + separate credentials for each service + +**CSC Guidance** +- Enforce policies against sharing of cloud service credentials +- Use service accounts or API keys with limited permissions in place of user credentials for + automated access to cloud APIs + +--- + +### 9.4.1 — Information Access Restriction + +**CSP Guidance** +- Implement access controls that restrict access at the data and resource level, not just the + account level, ensuring CSC users only access the data and services they are authorised to + access +- Ensure tenant isolation prevents any cross-tenant data access (see also CLD.9.5.1) + +**CSC Guidance** +- Configure cloud storage and application access controls to implement least-privilege data + access for all users and service accounts +- Review and audit access control configurations periodically + +--- + +### 9.4.2 — Secure Log-On Procedures + +**CSP Guidance** +- Enforce MFA for all access to cloud management and administration interfaces +- Implement account lockout, login attempt logging, and anomaly detection for cloud console + access + +**CSC Guidance** +- Enforce MFA for all cloud service user accounts, particularly those with administrative + or data access privileges +- Configure session timeouts for cloud management console sessions + +--- + +### 9.4.3 — Password Management System + +**CSP Guidance** +- Enforce password complexity and change requirements via the cloud management console +- Where available, support integration with enterprise identity providers (SAML/SSO) to + enable CSCs to use their own authentication systems + +**CSC Guidance** +- Use a password manager to generate and store unique credentials for cloud service accounts +- Where possible, federate cloud service authentication to the CSC's own enterprise identity + provider to centralise control and enforcement + +--- + +## Domain 10 — Cryptography + +### 10.1.1 — Policy on the Use of Cryptographic Controls + +**CSP Guidance** +- Document the encryption capabilities provided for data at rest and data in transit in + the cloud service +- Clearly state which encryption is managed by the CSP, which can be managed by the CSC, + and any limitations + +**CSC Guidance** +- Establish a cloud cryptography policy covering: mandatory encryption for sensitive data + at rest, minimum TLS version for data in transit, and acceptable key management approaches +- Determine whether CSC-managed encryption keys (BYOK — Bring Your Own Key) are required + for compliance or risk management purposes + +--- + +### 10.1.2 — Key Management + +**CSP Guidance** +- Provide clear documentation of the CSP's key management practices, including: key + generation, storage (HSM or equivalent), rotation schedule, and key destruction on service + termination +- Offer CSCs the option of customer-managed keys (BYOK/HYOK) where feasible + +**CSC Guidance** +- Determine whether to use CSP-managed keys, CSC-managed keys, or a combination, based on + data sensitivity and regulatory requirements +- If using CSC-managed keys: document key rotation procedures, backup plans for key material, + and recovery procedures in case of key loss +- Understand the implications of key deletion (data becomes unreadable) + +--- + +## Domain 11 — Physical and Environmental Security + +### 11.1.1 — Physical Security Perimeters + +**CSP Guidance** +- Implement and certify (where required by CSCs) physical security of data centres hosting + the cloud service, including: perimeter fencing, access control, CCTV, and intrusion + detection +- Make evidence of physical security available to CSCs via third-party audit reports + (e.g., SOC 2 Type II, ISO 27001 certificate, or equivalent) + +**CSC Guidance** +- Request and review CSP physical security certifications or audit reports as part of cloud + vendor due diligence +- Where physical security cannot be verified independently, include the right to audit in + the CSA + +--- + +### 11.2.5 — Removal of Assets + +**CSP Guidance** +- Ensure that physical decommissioning of cloud hardware includes sanitisation of storage + media to prevent residual CSC data from being recovered +- Document the media sanitisation process; provide evidence upon request + +**CSC Guidance** +- Include hardware sanitisation provisions in the CSA +- Request certificates of media destruction when cloud infrastructure used by the CSC is + decommissioned + +--- + +### 11.2.6 — Security of Equipment and Assets Off-Premises + +**CSP Guidance** +- Apply equivalent security controls to cloud assets operated outside the primary data centre + (e.g., edge locations, co-location facilities) as those in the primary facility + +**CSC Guidance** +- When CSC hardware is collocated with a CSP or managed cloud, ensure physical security + provisions equivalent to those of any on-premises facility + +--- + +## Domain 12 — Operations Security + +### 12.1.1 — Documented Operating Procedures + +**CSP Guidance** +- Maintain documented procedures for all cloud service operations, including: VM lifecycle + management, backup procedures, patch management, incident response, and customer-facing + operations +- Ensure procedures cover multi-tenant specific operations (e.g., provisioning new tenants + without exposing existing tenant data) + +**CSC Guidance** +- Document procedures for all cloud-related operations performed by the CSC: provisioning, + de-provisioning, backup, monitoring, and incident response + +--- + +### 12.1.2 — Change Management + +**CSP Guidance** +- Apply formal change management to all changes to cloud service infrastructure that could + affect security, availability, or performance for CSCs +- Notify CSCs in advance of planned changes with security implications +- Test changes in non-production environments before deployment to production + +**CSC Guidance** +- Apply change management to cloud service configuration changes, particularly those + affecting: access controls, network security groups, encryption settings, and monitoring + configurations + +--- + +### 12.1.3 — Capacity Management + +**CSP Guidance** +- Monitor capacity of cloud infrastructure and scale proactively to maintain service SLAs +- Protect against resource exhaustion attacks (DoS/DDoS) that could affect availability + for CSCs + +**CSC Guidance** +- Monitor cloud resource usage to detect unexpected increases (which may indicate a security + incident, misconfiguration, or resource abuse) +- Implement alerts for abnormal resource consumption + +--- + +### 12.3.1 — Information Backup + +**CSP Guidance** +- Document backup procedures for CSP-managed cloud services, including: backup scope, + frequency, retention period, and restoration testing +- Clearly state in the CSA what data is backed up by the CSP, at what frequency, and what + restoration service levels apply + +**CSC Guidance** +- Do not assume the CSP backs up CSC data automatically; verify backup scope in the CSA +- Implement CSC-managed backup procedures for critical data stored in cloud services, + including: cross-region or cross-provider backup for critical data +- Test restoration from backup periodically + +--- + +### 12.4.1 — Event Logging + +**CSP Guidance** +- Log all security-relevant events in the cloud service, including: authentication events, + privileged access, configuration changes, API calls, and inter-tenant access attempts +- Make logs available to CSCs covering events related to their tenancy + +**CSC Guidance** +- Enable logging for all CSC cloud resources: authentication, API calls, data access, + configuration changes +- Where provided by the CSP, enable enhanced logging features (e.g., AWS CloudTrail, Azure + Monitor, Google Cloud Audit Logs) + +--- + +### 12.4.2 — Protection of Log Information + +**CSP Guidance** +- Protect cloud service logs from modification or deletion by cloud service administrators + and by CSC users +- Store logs in a write-once or append-only store, or export to an immutable external system + +**CSC Guidance** +- Export cloud audit logs to an independent storage system where they cannot be modified + by cloud administrators +- Apply access controls so only designated security personnel can access log systems + +--- + +### 12.4.3 — Administrator and Operator Logs + +**CSP Guidance** +- Maintain logs of all administrative actions performed by CSP operators, including actions + affecting CSC environments; protect these logs from modification by those same operators +- See also CLD.12.1.5 for administrator operational security requirements + +**CSC Guidance** +- Ensure logs of cloud administrator actions are maintained and reviewed +- Separate the role of administrator from the role of log reviewer + +--- + +### 12.4.4 — Clock Synchronisation + +**CSP Guidance** +- Synchronise all cloud infrastructure components to a reliable time source using NTP +- Document the time source used; make this available to CSCs for log correlation purposes + +**CSC Guidance** +- Synchronise CSC-managed cloud VM clocks with the CSP-provided time source to ensure log + timestamps are consistent and correlatable + +--- + +## Domain 13 — Communications Security + +### 13.1.1 — Network Controls + +**CSP Guidance** +- Implement network security controls throughout the cloud service infrastructure: firewalls, + intrusion detection/prevention systems, DDoS protection, and traffic filtering +- Apply network access controls between all cloud service components and between the service + and the internet + +**CSC Guidance** +- Configure cloud network security controls provided by the CSP (security groups, network + ACLs, virtual firewalls) to restrict traffic to the minimum required +- Apply defence-in-depth: host-based firewalls in addition to virtual network controls + +--- + +### 13.1.2 — Security of Network Services + +**CSP Guidance** +- Communicate to CSCs the security features of each cloud network service offered, including: + encryption in transit capabilities, access control features, and monitoring capabilities + +**CSC Guidance** +- Evaluate and select cloud network services based on their security capabilities +- Require TLS/HTTPS for all data transmission and verify that the CSP does not downgrade + connections + +--- + +### 13.1.3 — Segregation in Networks + +**CSP Guidance** +- Implement tenant network isolation separating each CSC's virtual network from all other + CSCs and from the CSP management network (see also CLD.13.1.4) + +**CSC Guidance** +- Use virtual network segmentation (subnets, VPCs/VNets, security groups) within the CSC's + cloud environment to separate systems of different sensitivity levels +- Do not put all cloud systems on a single flat network + +--- + +## Domain 14 — System Acquisition, Development and Maintenance + +### 14.1.1 — Information Security Requirements Analysis and Specification + +**CSP Guidance** +- Define and document the security requirements of the cloud service at design time, including + requirements for: multi-tenancy, virtualisation security, data separation, and resilience + +**CSC Guidance** +- Define security requirements for cloud-hosted applications before procurement or development, + including: data classification requirements, encryption requirements, access control model, + and logging requirements + +--- + +### 14.2.5 — Secure System Engineering Principles + +**CSP Guidance** +- Apply secure engineering principles to cloud service development: defence in depth, zero + trust principles, least privilege, fail-secure design, and secure default configurations + +**CSC Guidance** +- Apply the same secure engineering principles to applications deployed in cloud environments + as to on-premises applications +- Apply cloud-native security patterns: use managed identity for service-to-service + authentication, avoid embedding credentials in code, and implement least-privilege IAM roles + +--- + +## Domain 15 — Supplier Relationships + +### 15.1.1 — Information Security Policy for Supplier Relationships + +**CSP Guidance** +- Manage sub-service providers (sub-processors, data centre operators, third-party component + providers) according to a formal supplier security policy +- Ensure sub-service providers meet the same security standards as the CSP itself, and + flow down CSC requirements where applicable + +**CSC Guidance** +- Treat the CSP as a supplier subject to the CSC's supplier security management policy +- Conduct due diligence on CSPs before selection, including review of: security certifications, + third-party audit reports, penetration testing evidence, and data processing terms +- Include ISO 27017-aligned security requirements in the CSA + +--- + +### 15.2.1 — Monitoring and Review of Supplier Services + +**CSP Guidance** +- Monitor sub-service providers' security performance and compliance continuously +- Review sub-service provider contracts and security posture at defined intervals (at least + annually) or when there are significant changes + +**CSC Guidance** +- Regularly review CSP performance against the security provisions in the CSA +- Keep up to date with CSP security advisories, compliance reports, and changes to services + +--- + +### 15.2.2 — Managing Changes to Supplier Services + +**CSP Guidance** +- Notify CSCs of significant changes to cloud service components that could affect security +- Apply change management before making such changes and communicate impact assessments + +**CSC Guidance** +- Assess the security implications of changes to CSP services before accepting them +- Include a requirement in the CSA for advance notification of changes that could affect + the CSC's compliance or security posture + +--- + +## Domain 16 — Information Security Incident Management + +### 16.1.1 — Responsibilities and Procedures + +**CSP Guidance** +- Establish incident response procedures that specifically address multi-tenant cloud incidents, + including: isolating affected tenants, notifying affected CSCs, and preserving forensic + evidence without compromising other tenants +- Assign clear responsibilities for each phase of cloud incident response + +**CSC Guidance** +- Establish cloud-specific incident response procedures, addressing the scenarios where the + incident occurs at the CSP level and where the CSC may have limited direct access to + investigate + +--- + +### 16.1.2 — Reporting Information Security Events + +**CSP Guidance** +- Commit to notifying CSCs of security incidents affecting their data or services within a + defined and contractually agreed timeframe +- Include incident notification obligations in the CSA +- Provide a dedicated and accessible incident notification channel for CSCs + +**CSC Guidance** +- Ensure the CSA includes the CSP's commitment to incident notification with defined + timelines +- Implement cloud monitoring to detect incidents that may not be detected and reported by + the CSP (see CLD.12.4.5) + +--- + +### 16.1.3 — Reporting Information Security Weaknesses + +**CSP Guidance** +- Provide a vulnerability disclosure programme allowing security researchers and CSCs to + report cloud service security weaknesses +- Commit to acknowledging and remediating reported vulnerabilities within defined timelines + +**CSC Guidance** +- Report identified vulnerabilities in the cloud service to the CSP through official channels +- Do not exploit discovered vulnerabilities; report them responsibly + +--- + +### 16.1.4 — Assessment of and Decision on Information Security Events + +**CSP Guidance** +- Assess every reported security event for its potential impact on CSC data and services +- Prioritise events involving CSC data exposure or service disruption + +**CSC Guidance** +- Assess cloud security events in the context of the CSC's own risk register and the impact + on CSC-managed data and services + +--- + +### 16.1.7 — Collection of Evidence + +**CSP Guidance** +- Preserve forensic evidence of cloud security incidents in a manner admissible for legal or + regulatory proceedings, without contaminating or destroying logs or system state +- Cooperate with CSC evidence collection requests within legal and contractual constraints + +**CSC Guidance** +- Define how the CSC will collect forensic evidence from cloud environments (acknowledging + limitations such as shared infrastructure and limited direct access to underlying hardware) +- Include evidence preservation obligations in the CSA + +--- + +## Domain 17 — Business Continuity Management + +### 17.1.1 — Planning Information Security Continuity + +**CSP Guidance** +- Develop and maintain a business continuity plan that includes provisions for maintaining + cloud service availability and security during disruptions +- Make availability SLAs (uptime commitments) available in the CSA + +**CSC Guidance** +- Plan for scenarios where the cloud service is unavailable: failover to alternate CSP region, + use of alternative service, or reversion to on-premises operation +- Include the CSP's availability SLA in the CSC's own BCP assumptions + +--- + +### 17.1.2 — Implementing Information Security Continuity + +**CSP Guidance** +- Implement redundancy and resilience mechanisms across the cloud service: multi-region + deployment, auto-failover, load balancing, and regular failover testing +- Document which resilience features are built into the service and which require CSC + configuration + +**CSC Guidance** +- Configure and test cloud resilience features appropriate to the CSC's recovery time and + recovery point objectives +- Test restoration from cross-region backup at least annually + +--- + +### 17.2.1 — Availability of Information Processing Facilities + +**CSP Guidance** +- Provide redundancy for all critical cloud service components with documented SLAs covering + availability, RPO (recovery point objective), and RTO (recovery time objective) +- Disclose planned maintenance windows with advance notice to CSCs + +**CSC Guidance** +- Select CSP service tiers that provide availability appropriate to the criticality of the + CSC's workloads +- Use cloud-native high availability features (load balancers, multi-zone deployment) for + critical services + +--- + +## Domain 18 — Compliance + +### 18.1.1 — Identification of Applicable Legislation and Contractual Requirements + +**CSP Guidance** +- Provide CSCs with sufficient information to determine whether the cloud service meets their + legal and regulatory requirements, including: jurisdiction of data storage, certifications + held, and data processing terms available +- Maintain compliance with applicable laws and regulations in all jurisdictions where the + cloud service operates + +**CSC Guidance** +- Identify all legal, regulatory, and contractual requirements that apply to data stored in + or processed by cloud services (e.g., GDPR, HIPAA, PCI DSS) +- Verify that the CSP provides the technical and contractual controls necessary to meet + these requirements before selecting the service + +--- + +### 18.1.3 — Protection of Records + +**CSP Guidance** +- Ensure that records required by CSCs for regulatory compliance can be retained for the + required period and are protected from modification, deletion, or loss + +**CSC Guidance** +- Verify that cloud storage services for records meet the CSC's records retention requirements + in terms of: durability, availability, and write-protection capabilities +- Implement cloud storage with retention policies and legal hold capabilities where required diff --git a/plugins/iso27017/skills/iso27017/references/shared-responsibility.md b/plugins/iso27017/skills/iso27017/references/shared-responsibility.md new file mode 100644 index 0000000..a130aca --- /dev/null +++ b/plugins/iso27017/skills/iso27017/references/shared-responsibility.md @@ -0,0 +1,199 @@ +# ISO/IEC 27017:2015 — Shared Responsibility Matrix + +This file documents the allocation of information security responsibilities between +Cloud Service Providers (CSPs) and Cloud Service Customers (CSCs) in accordance with +ISO/IEC 27017:2015. The allocation varies by cloud service model. + +**Legend:** +- **CSP** — Cloud Service Provider is solely responsible +- **CSC** — Cloud Service Customer is solely responsible +- **Shared** — Both parties have defined obligations; scope differs between them +- **N/A** — Not applicable to this service model + +--- + +## Shared Responsibility by Cloud Service Model + +### Section 1 — Infrastructure and Platform Layers + +| Security Area | IaaS | PaaS | SaaS | +|--------------|------|------|------| +| Physical data centre security (11.1.1) | CSP | CSP | CSP | +| Physical hardware security and sanitisation (11.2.5) | CSP | CSP | CSP | +| Hypervisor and virtualisation layer security (CLD.9.5.1) | CSP | CSP | CSP | +| Host operating system patching (virtual host) | CSP | CSP | CSP | +| Guest operating system patching (CSC VMs) | CSC | CSP | CSP | +| Runtime environment and middleware | CSC | CSP | CSP | +| Application code and libraries | CSC | CSC | CSP | +| Application security configuration | CSC | CSC | Shared | +| Network infrastructure (physical) | CSP | CSP | CSP | +| Virtual network provisioning and security groups | Shared | CSP | CSP | +| DDoS protection | Shared | Shared | CSP | +| Firewall between tenants (CLD.9.5.1) | CSP | CSP | CSP | +| Virtual machine hardening — base images (CLD.9.5.2) | CSP | CSP | CSP | +| Virtual machine hardening — deployed VMs (CLD.9.5.2) | CSC | Shared | CSP | +| Virtual/physical network security alignment (CLD.13.1.4) | CSP | CSP | CSP | + +--- + +### Section 2 — Identity and Access Management + +| Security Area | IaaS | PaaS | SaaS | +|--------------|------|------|------| +| CSP platform IAM (admin access to infrastructure) (CLD.12.1.5) | CSP | CSP | CSP | +| CSC user account creation and management (9.2.1, 9.2.2) | CSC | CSC | CSC | +| CSC user de-provisioning (9.2.6, 7.3.1) | CSC | CSC | CSC | +| Privileged access management — CSP admins (9.2.3, CLD.12.1.5) | CSP | CSP | CSP | +| Privileged access management — CSC admins (9.2.3) | CSC | CSC | CSC | +| MFA enforcement for CSP administrative access (9.4.2, CLD.12.1.5) | CSP | CSP | CSP | +| MFA enforcement for CSC user accounts (9.4.2) | CSC | CSC | CSC | +| Role-based access control framework (9.2.2) | Shared | Shared | Shared | +| Password policy enforcement for CSC users (9.4.3) | CSC | CSC | Shared | +| Federated identity / SSO integration | Shared | Shared | Shared | +| Periodic access right review — CSC users (9.2.5) | CSC | CSC | CSC | + +--- + +### Section 3 — Data Security + +| Security Area | IaaS | PaaS | SaaS | +|--------------|------|------|------| +| Data classification and labelling | CSC | CSC | CSC | +| Encryption of data at rest — CSP infrastructure (10.1.1) | CSP | CSP | CSP | +| Encryption of data at rest — CSC-managed volumes (10.1.1) | CSC | Shared | CSP | +| Encryption in transit (TLS) — infrastructure (10.1.1) | CSP | CSP | CSP | +| Encryption in transit — application layer (10.1.1) | CSC | CSC | CSP | +| Key management for CSP-managed keys (10.1.2) | CSP | CSP | CSP | +| Key management for customer-managed keys / BYOK (10.1.2) | CSC | CSC | CSC | +| Data ownership definition (8.1.2) | CSC | CSC | CSC | +| Data return capability upon termination (CLD.8.1.5) | CSP | CSP | CSP | +| Data deletion upon termination (CLD.8.1.5) | CSP | CSP | CSP | +| Certificate of data deletion (CLD.8.1.5) | CSP | CSP | CSP | +| CSC data retrieval verification (CLD.8.1.5) | CSC | CSC | CSC | +| Data sovereignty and jurisdiction documentation (18.1.1) | CSP | CSP | CSP | + +--- + +### Section 4 — Operations and Monitoring + +| Security Area | IaaS | PaaS | SaaS | +|--------------|------|------|------| +| Cloud service infrastructure monitoring (CLD.12.4.5) | CSP | CSP | CSP | +| CSC usage and security event monitoring (CLD.12.4.5) | CSC | CSC | CSC | +| Monitoring data availability to CSC (CLD.12.4.5) | CSP | CSP | CSP | +| Event logging — infrastructure layer (12.4.1) | CSP | CSP | CSP | +| Event logging — CSC workloads and applications (12.4.1) | CSC | CSC | Shared | +| Log integrity protection (12.4.2) | Shared | Shared | CSP | +| Administrator activity logging (12.4.3, CLD.12.1.5) | Shared | Shared | CSP | +| Backup — CSP platform components (12.3.1) | CSP | CSP | CSP | +| Backup — CSC data and workloads (12.3.1) | CSC | Shared | CSP | +| Backup restoration testing (12.3.1) | CSC | Shared | CSP | +| Change management — infrastructure (12.1.2) | CSP | CSP | CSP | +| Change management — CSC configurations (12.1.2) | CSC | CSC | CSC | +| Capacity management — infrastructure (12.1.3) | CSP | CSP | CSP | +| Capacity monitoring — CSC workloads (12.1.3) | CSC | CSC | CSC | +| Patch management — CSP platform (12.1.1) | CSP | CSP | CSP | +| Patch management — CSC VMs and applications | CSC | Shared | CSP | + +--- + +### Section 5 — Incident Response + +| Security Area | IaaS | PaaS | SaaS | +|--------------|------|------|------| +| Incident detection — infrastructure (16.1.1) | CSP | CSP | CSP | +| Incident detection — CSC workloads (16.1.1) | CSC | Shared | Shared | +| CSP-to-CSC incident notification (16.1.2) | CSP | CSP | CSP | +| CSC incident response plan (16.1.1) | CSC | CSC | CSC | +| Forensic evidence collection — infrastructure (16.1.7) | CSP | CSP | CSP | +| Forensic cooperation with CSC (16.1.7) | CSP | CSP | CSP | +| Forensic evidence from CSC workloads (16.1.7) | CSC | Shared | CSC | +| Vulnerability reporting mechanism (16.1.3) | CSP | CSP | CSP | +| CSC vulnerability assessment for own workloads (16.1.3) | CSC | CSC | N/A | + +--- + +### Section 6 — Governance and Compliance + +| Security Area | IaaS | PaaS | SaaS | +|--------------|------|------|------| +| Shared responsibility documentation (CLD.6.3.1) | CSP | CSP | CSP | +| CSC acknowledgement of shared responsibility (CLD.6.3.1) | CSC | CSC | CSC | +| Cloud service agreement security provisions (CLD.6.3.1) | Shared | Shared | Shared | +| Third-party security certifications (18.1.1) | CSP | CSP | CSP | +| CSC regulatory compliance for CSC data (18.1.1) | CSC | CSC | CSC | +| Sub-processor management (15.1.1) | CSP | CSP | CSP | +| CSP due diligence by CSC (15.1.1) | CSC | CSC | CSC | +| CSC supplier assessment of CSP (15.2.1) | CSC | CSC | CSC | +| Records protection — infrastructure (18.1.3) | CSP | CSP | CSP | +| Records protection — CSC content (18.1.3) | CSC | CSC | Shared | +| Business continuity — CSP platform (17.2.1) | CSP | CSP | CSP | +| Business continuity — CSC workloads (17.1.1) | CSC | Shared | Shared | + +--- + +## Notes on Shared Responsibilities + +### CLD.6.3.1 Obligation +Both the CSP and CSC have an explicit obligation under CLD.6.3.1 to define and document their +respective responsibilities. Regardless of which items in the table above are marked "Shared," +the allocation must be formally agreed and documented in the Cloud Service Agreement. + +### IaaS Considerations +In IaaS, the CSC has the most extensive security responsibilities of any service model. +The CSC effectively manages everything above the hypervisor layer including: +- Guest OS security configuration and patching +- Application security +- Firewall rules (security groups) and network ACLs +- Data encryption configuration +- Identity and access management for all workloads + +### PaaS Considerations +In PaaS, the boundary shifts: the CSP manages the OS and runtime. The CSC retains responsibility +for application security, data, and identity. Key CSC risks in PaaS include: +- Application-level vulnerabilities +- Insecure API configuration +- Data input validation +- Access control within the application + +### SaaS Considerations +In SaaS, the CSC has limited direct control over security. The CSC's primary responsibilities are: +- User account provisioning and deprovisioning (9.2.1, 9.2.6) +- Enforcement of MFA for user accounts (9.4.2) +- Access right reviews (9.2.5) +- Configuration of data sharing and export settings +- Monitoring of own user activity (CLD.12.4.5) +- Ensuring data retrieved and compliance requirements met (18.1.1) + +The CSP bears the vast majority of technical security controls in SaaS. The CSC's due diligence +obligations (clause 15) and contractual requirements (CLD.6.3.1) remain fully applicable. + +--- + +## Cloud Service Agreement Security Provisions Checklist + +The following security provisions must be addressed in every Cloud Service Agreement under +ISO/IEC 27017: + +| Provision | ISO 27017 Reference | Required | +|-----------|--------------------|---------:| +| Explicit shared responsibility allocation | CLD.6.3.1 | Yes | +| Data ownership confirmation (CSC owns data) | 8.1.2 | Yes | +| Data return format and procedure | CLD.8.1.5 | Yes | +| Data deletion procedure and timeline | CLD.8.1.5 | Yes | +| Certificate of deletion on request | CLD.8.1.5 | Yes | +| Incident notification obligation and timeline | 16.1.2 | Yes | +| Right to audit or request third-party audit reports | 15.2.1 | Yes | +| Sub-processor disclosure and restrictions | 15.1.1 | Yes | +| Applicable law and jurisdiction | 18.1.1 | Yes | +| Availability SLA (uptime commitment, RPO/RTO) | 17.2.1 | Yes | +| Maintenance window notification commitment | 17.1.2 | Yes | +| Advance notification of material changes to the service | 15.2.2 | Yes | +| Backup scope, frequency, and retention | 12.3.1 | Yes | +| Log retention period and availability to CSC | 12.4.1, CLD.12.4.5 | Yes | +| Encryption capabilities (at rest, in transit) | 10.1.1 | Yes | +| Physical security certifications (or right to assess) | 11.1.1 | Yes | +| Penetration testing frequency or right to test | 16.1.3 | Recommended | +| Support for customer-managed keys (BYOK) | 10.1.2 | As required | +| Compliance certifications maintained by the CSP | 18.1.1 | Yes | +| Personnel screening requirements for CSP staff | 7.1.1 | Yes | diff --git a/plugins/iso27017/skills/iso27017/references/templates.md b/plugins/iso27017/skills/iso27017/references/templates.md new file mode 100644 index 0000000..898719e --- /dev/null +++ b/plugins/iso27017/skills/iso27017/references/templates.md @@ -0,0 +1,461 @@ +# ISO/IEC 27017:2015 — Templates and Checklists + +This file contains reusable templates for ISO 27017 compliance activities including gap analysis, +cloud service agreement review, policy documents, and certification readiness checklists. + +--- + +## Template 1 — ISO 27017 Gap Analysis + +Use this template to assess current state against ISO/IEC 27017:2015 requirements. + +``` +================================================================================ +ISO/IEC 27017:2015 CLOUD SECURITY GAP ANALYSIS +================================================================================ +Organisation: [Organisation Name] +Role: [Cloud Service Provider / Cloud Service Customer / Both] +Cloud Service Model: [IaaS / PaaS / SaaS] +Assessment Scope: [Service names, environments, or systems in scope] +Assessment Date: [Date] +Assessed By: [Name / Team] +Review Date: [Next scheduled review] +Version: [1.0] + +-------------------------------------------------------------------------------- +SECTION A — CLD CONTROLS (CLOUD-SPECIFIC CONTROLS) +-------------------------------------------------------------------------------- +Control ID | Control Name | Applicability | Status | Evidence Required | Gap Notes +-------------|---------------------------------------------------|---------------|-----------------|---------------------------------------------------|---------- +CLD.6.3.1 | Shared roles and responsibilities | Both | [Status] | Documented responsibility split; CSA clause | [Notes] +CLD.8.1.5 | Removal or return of CSC assets | Both | [Status] | Data return procedure; deletion cert | [Notes] +CLD.9.5.1 | Segregation in virtual environments | CSP | [Status] | Hypervisor isolation docs; penetration test | [Notes] +CLD.9.5.2 | Virtual machine hardening | Both | [Status] | VM hardening standard; scan results | [Notes] +CLD.12.1.5 | Administrator's operational security | CSP | [Status] | MFA evidence; admin access logs; RBAC config | [Notes] +CLD.12.4.5 | Monitoring of cloud services | Both | [Status] | Monitoring architecture; CSC dashboard access | [Notes] +CLD.13.1.4 | Virtual/physical network security alignment | CSP | [Status] | Network security policy; architecture diagram | [Notes] + +-------------------------------------------------------------------------------- +SECTION B — ISO 27002 CONTROLS WITH CLOUD-SPECIFIC GUIDANCE +-------------------------------------------------------------------------------- +[Repeat the table below for each of the 37 controls — see iso27002-cloud-guidance.md] + +Control ID | Control Name | Applicability | Status | Evidence Required | Gap Notes +-------------|---------------------------------------------------|---------------|-----------------|---------------------------------------------------|---------- +5.1.1 | Policies for information security | Both | [Status] | Cloud-specific IS policy | [Notes] +5.1.2 | Review of policies | Both | [Status] | Review records | [Notes] +6.1.1 | IS roles and responsibilities | Both | [Status] | Roles/RACI document | [Notes] +6.1.2 | Segregation of duties | Both | [Status] | Duty separation evidence | [Notes] +7.1.1 | Screening | Both | [Status] | Background check records | [Notes] +7.2.1 | Management responsibilities | Both | [Status] | Management sign-off on cloud security | [Notes] +7.2.2 | IS awareness, education and training | Both | [Status] | Cloud training records | [Notes] +7.2.3 | Disciplinary process | Both | [Status] | Policy covering cloud violations | [Notes] +7.3.1 | Termination responsibilities | Both | [Status] | Off-boarding process for cloud access | [Notes] +8.1.1 | Inventory of assets | Both | [Status] | Cloud asset register | [Notes] +8.1.2 | Ownership of assets | Both | [Status] | Ownership clause in CSA; asset registry | [Notes] +8.1.3 | Acceptable use of assets | Both | [Status] | AUP covering cloud services | [Notes] +9.1.1 | Access control policy | Both | [Status] | Cloud access control policy | [Notes] +9.2.1 | User registration and de-registration | Both | [Status] | Provisioning process records | [Notes] +9.2.2 | User access provisioning | Both | [Status] | Access request records; RBAC config | [Notes] +9.2.3 | Management of privileged access rights | Both | [Status] | PAM solution; privileged account list | [Notes] +9.2.4 | Management of secret authentication information | Both | [Status] | Password policy; credential management | [Notes] +9.2.5 | Review of user access rights | Both | [Status] | Access review records | [Notes] +9.2.6 | Removal or adjustment of access rights | Both | [Status] | Deprovisioning process; timing evidence | [Notes] +9.3.1 | Use of secret authentication information | Both | [Status] | Credential use policy; service account policy | [Notes] +9.4.1 | Information access restriction | Both | [Status] | Resource-level access controls; IAM config | [Notes] +9.4.2 | Secure log-on procedures | Both | [Status] | MFA configuration; session timeout settings | [Notes] +9.4.3 | Password management system | Both | [Status] | Password complexity settings; PWDM config | [Notes] +10.1.1 | Policy on cryptographic controls | Both | [Status] | Encryption policy; at-rest/in-transit config | [Notes] +10.1.2 | Key management | Both | [Status] | KMS configuration; key rotation records | [Notes] +11.1.1 | Physical security perimeters | CSP | [Status] | ISO 27001 cert; SOC 2 audit report | [Notes] +11.2.5 | Removal of assets | CSP | [Status] | Media destruction certificates | [Notes] +11.2.6 | Security of equipment off-premises | Both | [Status] | Co-location security documentation | [Notes] +12.1.1 | Documented operating procedures | Both | [Status] | Cloud operations runbooks | [Notes] +12.1.2 | Change management | Both | [Status] | Change records; CAB approval | [Notes] +12.1.3 | Capacity management | Both | [Status] | Capacity monitoring alerts; scaling policy | [Notes] +12.3.1 | Information backup | Both | [Status] | Backup policy; restoration test records | [Notes] +12.4.1 | Event logging | Both | [Status] | Logging configuration; log samples | [Notes] +12.4.2 | Protection of log information | Both | [Status] | Log immutability config; access controls | [Notes] +12.4.3 | Administrator and operator logs | Both | [Status] | Admin logging config; separation of log access | [Notes] +12.4.4 | Clock synchronisation | Both | [Status] | NTP configuration | [Notes] +13.1.1 | Network controls | Both | [Status] | Network security docs; security group config | [Notes] +13.1.2 | Security of network services | Both | [Status] | TLS configuration; CSP network service docs | [Notes] +13.1.3 | Segregation in networks | Both | [Status] | Network segmentation architecture | [Notes] +14.1.1 | IS requirements analysis and specification | Both | [Status] | Security requirements in design docs | [Notes] +14.2.5 | Secure system engineering principles | Both | [Status] | Secure design patterns; architecture review | [Notes] +15.1.1 | IS policy for supplier relationships | Both | [Status] | Supplier security policy; CSA security review | [Notes] +15.2.1 | Monitoring and review of supplier services | CSC | [Status] | CSP review records; audit report reviews | [Notes] +15.2.2 | Managing changes to supplier services | CSC | [Status] | Change notification records; impact assessments | [Notes] +16.1.1 | Responsibilities and procedures | Both | [Status] | Cloud incident response plan | [Notes] +16.1.2 | Reporting information security events | Both | [Status] | Incident notification CSA clause; reports | [Notes] +16.1.3 | Reporting weaknesses | Both | [Status] | Vulnerability disclosure process | [Notes] +16.1.4 | Assessment of IS events | Both | [Status] | Incident severity classification | [Notes] +16.1.7 | Collection of evidence | Both | [Status] | Forensic procedure; CSA cooperation clause | [Notes] +17.1.1 | Planning IS continuity | Both | [Status] | Cloud BCP | [Notes] +17.1.2 | Implementing IS continuity | Both | [Status] | Failover test records; multi-region config | [Notes] +17.2.1 | Availability of processing facilities | Both | [Status] | SLA documentation; availability metrics | [Notes] +18.1.1 | Identification of applicable legislation | Both | [Status] | Legal register; jurisdiction documentation | [Notes] +18.1.3 | Protection of records | Both | [Status] | Retention policy; WORM storage config | [Notes] + +-------------------------------------------------------------------------------- +GAP ANALYSIS SUMMARY +-------------------------------------------------------------------------------- +Total Controls Assessed: [Number] +Implemented: [Number] ([%]) +Partial: [Number] ([%]) +Not Implemented: [Number] ([%]) +Not Applicable (with justification): [Number] ([%]) + +Critical Gaps (address immediately): + 1. [Control ID] — [Gap Description] + 2. [Control ID] — [Gap Description] + +High Priority (address within 30 days): + 1. [Control ID] — [Gap Description] + +Medium Priority (address within 90 days): + 1. [Control ID] — [Gap Description] + +Low Priority (address in next review cycle): + 1. [Control ID] — [Gap Description] +================================================================================ +``` + +--- + +## Template 2 — Cloud Service Agreement Security Review Checklist + +Use this checklist to evaluate whether a cloud service agreement meets ISO 27017 requirements. + +``` +================================================================================ +CLOUD SERVICE AGREEMENT (CSA) SECURITY REVIEW +================================================================================ +Cloud Service Provider: [CSP Name] +Cloud Service Name: [Service Name] +Service Model: [IaaS / PaaS / SaaS] +Agreement Reference: [Contract/Agreement Number] +Review Date: [Date] +Reviewed By: [Name / Role] + +KEY: Present = clause exists | Adequate = clause meets ISO 27017 standard | Critical = must resolve before use + +SECTION 1 — SHARED RESPONSIBILITY AND GOVERNANCE +------------------------------------------------- +Requirement | ISO 27017 Ref | Present | Adequate | Priority | Notes +--------------------------------------------------------|---------------|---------|----------|----------|------ +Explicit shared responsibility allocation | CLD.6.3.1 | Y/N | Y/N | Critical | +Data ownership confirmation (CSC owns data) | 8.1.2 | Y/N | Y/N | Critical | +Applicable law and jurisdiction | 18.1.1 | Y/N | Y/N | Critical | +Sub-processor disclosure and consent requirement | 15.1.1 | Y/N | Y/N | High | +Right to audit or review third-party audit reports | 15.2.1 | Y/N | Y/N | High | +Advance notification of material service changes | 15.2.2 | Y/N | Y/N | High | +Personnel screening requirements for CSP staff | 7.1.1 | Y/N | Y/N | Medium | +Compliance certifications maintained (specify which) | 18.1.1 | Y/N | Y/N | High | + +SECTION 2 — DATA MANAGEMENT +---------------------------- +Requirement | ISO 27017 Ref | Present | Adequate | Priority | Notes +--------------------------------------------------------|---------------|---------|----------|----------|------ +Data return format and procedure on termination | CLD.8.1.5 | Y/N | Y/N | Critical | +Data deletion timeline after termination | CLD.8.1.5 | Y/N | Y/N | Critical | +Certificate of deletion on request | CLD.8.1.5 | Y/N | Y/N | Critical | +Deletion of backup copies confirmed | CLD.8.1.5 | Y/N | Y/N | High | +Data sovereignty / geographic storage restrictions | 18.1.1 | Y/N | Y/N | High | +Records retention capabilities | 18.1.3 | Y/N | Y/N | Medium | + +SECTION 3 — SECURITY CONTROLS +------------------------------ +Requirement | ISO 27017 Ref | Present | Adequate | Priority | Notes +--------------------------------------------------------|---------------|---------|----------|----------|------ +Encryption at rest capabilities and responsibilities | 10.1.1 | Y/N | Y/N | Critical | +Encryption in transit (minimum TLS version) | 10.1.1 | Y/N | Y/N | Critical | +Key management approach documented | 10.1.2 | Y/N | Y/N | High | +Customer-managed keys (BYOK/HYOK) availability | 10.1.2 | Y/N | Y/N | Medium | +Physical security certifications (ISO 27001, SOC 2) | 11.1.1 | Y/N | Y/N | High | +Penetration testing frequency or rights to pentest | 16.1.3 | Y/N | Y/N | Medium | + +SECTION 4 — OPERATIONS AND MONITORING +-------------------------------------- +Requirement | ISO 27017 Ref | Present | Adequate | Priority | Notes +--------------------------------------------------------|---------------|---------|----------|----------|------ +Log retention period | 12.4.1 | Y/N | Y/N | High | +Monitoring data availability to CSC | CLD.12.4.5 | Y/N | Y/N | High | +Backup scope, frequency, and retention | 12.3.1 | Y/N | Y/N | High | +Backup restoration SLA | 12.3.1 | Y/N | Y/N | High | +Availability SLA with uptime commitment | 17.2.1 | Y/N | Y/N | High | +RPO and RTO commitments | 17.2.1 | Y/N | Y/N | Medium | +Planned maintenance window advance notice | 17.1.2 | Y/N | Y/N | Medium | + +SECTION 5 — INCIDENT RESPONSE +------------------------------- +Requirement | ISO 27017 Ref | Present | Adequate | Priority | Notes +--------------------------------------------------------|---------------|---------|----------|----------|------ +Incident notification obligation | 16.1.2 | Y/N | Y/N | Critical | +Incident notification timeline (hours) | 16.1.2 | Y/N | Y/N | Critical | +Scope of incidents covered by notification obligation | 16.1.2 | Y/N | Y/N | High | +Forensic cooperation obligations | 16.1.7 | Y/N | Y/N | Medium | +Vulnerability disclosure process/timeline | 16.1.3 | Y/N | Y/N | Medium | + +SUMMARY +------- +Critical Issues (must resolve before use): [Number] +High Priority Issues: [Number] +Medium Priority Issues: [Number] +Overall Assessment: [PASS / CONDITIONAL (resolve high/critical first) / FAIL] +================================================================================ +``` + +--- + +## Template 3 — Cloud Security Policy (ISO 27017-Aligned) + +``` +================================================================================ +CLOUD SECURITY POLICY +================================================================================ +Document Control + Title: Cloud Information Security Policy + Version: [1.0] + Author: [Name / Role] + Approved By: [Name / Role] + Approval Date: [Date] + Next Review: [Date + 12 months] + Classification: [Internal / Restricted] + +ISO 27017 References: 5.1.1, 5.1.2, CLD.6.3.1, 8.1.1–8.1.3, 9.1.1, 10.1.1–10.1.2 + +1. PURPOSE + This policy establishes [Organisation Name]'s information security requirements for + the use of cloud computing services, covering both [Organisation Name] acting as a + cloud service customer and, where applicable, as a cloud service provider. + +2. SCOPE + This policy applies to: + - All employees, contractors, and third parties who utilise or administer cloud services + on behalf of [Organisation Name] + - All cloud service providers engaged by [Organisation Name] + - All data processed, stored, or transmitted via cloud services + +3. SHARED RESPONSIBILITY (CLD.6.3.1 / ISO 27017) + All cloud service engagements must have a formally documented shared responsibility + allocation identifying which security controls are the responsibility of the cloud service + provider and which are the responsibility of [Organisation Name]. This documentation must + be reviewed and approved before a cloud service is approved for use with sensitive data. + +4. APPROVED CLOUD SERVICES + Only cloud services that have completed [Organisation Name]'s cloud vendor due diligence + process (see Cloud Procurement Procedure) are permitted for use with [Classification Level] + or above data. Use of unapproved cloud services for such data is prohibited. + +5. DATA CLASSIFICATION FOR CLOUD USE + Data must be classified in accordance with [Organisation Name]'s Data Classification + Policy before being uploaded to any cloud service. The maximum data classification + permitted in each cloud service tier is maintained in the Cloud Service Register. + +6. CLOUD ASSET MANAGEMENT (8.1.1–8.1.3) + 6.1 An inventory of all data and systems hosted with each cloud service provider must be + maintained and reviewed quarterly. + 6.2 Data ownership must be documented for all cloud-hosted data. + 6.3 Data return and deletion arrangements must be confirmed before any cloud service + contract is signed (CLD.8.1.5). + +7. ACCESS CONTROL FOR CLOUD SERVICES (9.1.1, 9.2.1–9.2.6, 9.4.2) + 7.1 Access to cloud services must be provisioned on a least-privilege basis. + 7.2 Multi-factor authentication (MFA) is required for all cloud service accounts with + privileged or administrative access. + 7.3 Cloud service credentials must not be shared between individuals. + 7.4 Access rights must be reviewed at least annually for all cloud service accounts. + 7.5 Access must be revoked immediately upon role change or departure. + +8. CRYPTOGRAPHY FOR CLOUD DATA (10.1.1, 10.1.2) + 8.1 All sensitive data stored in cloud services must be encrypted at rest and in transit. + 8.2 Key management responsibilities must be documented in the shared responsibility + allocation for each cloud service. + 8.3 Where customer-managed encryption keys (BYOK) are required, key management + procedures must be documented and tested. + +9. CLOUD INCIDENT RESPONSE (16.1.1, 16.1.2) + 9.1 All cloud service agreements must include a contractual incident notification + obligation from the cloud service provider. + 9.2 [Organisation Name] cloud security incidents must be reported in accordance with + the Information Security Incident Response Policy. + 9.3 Cloud-specific incident scenarios must be included in the annual incident response + test programme. + +10. MONITORING (CLD.12.4.5, 12.4.1) + 10.1 Cloud service usage and security events must be monitored by [Organisation Name]. + 10.2 Cloud audit logs must be enabled and exported to [Organisation Name]'s SIEM or + equivalent log management system. + 10.3 Alerts must be configured for: abnormal access patterns, privilege escalation, + unusual data export volumes, and account takeover indicators. + +11. CLOUD BUSINESS CONTINUITY (17.1.1, 17.2.1) + 11.1 Business continuity plans for critical processes must include scenarios where + cloud services are unavailable. + 11.2 Recovery time objectives (RTOs) and recovery point objectives (RPOs) for + cloud-hosted systems must be documented and tested. + +12. REVIEW AND COMPLIANCE + This policy must be reviewed annually or when significant changes occur in the cloud + environment. Compliance will be assessed as part of [Organisation Name]'s annual + internal audit programme. + +References: + - ISO/IEC 27017:2015 + - ISO/IEC 27001:2022 (ISMS framework) + - ISO/IEC 27002:2013 (control guidelines) + - [Organisation Name] Information Security Policy + - [Organisation Name] Data Classification Policy +================================================================================ +``` + +--- + +## Template 4 — Virtual Machine Hardening Standard + +``` +================================================================================ +VIRTUAL MACHINE HARDENING STANDARD +================================================================================ +Document Control + Title: Virtual Machine Security Hardening Standard + Version: [1.0] + Author: [Name / Role] + Approved By: [Name / Role] + Approval Date: [Date] + Next Review: [Date + 12 months] + Classification: [Internal] + +ISO 27017 Reference: CLD.9.5.2 + +1. PURPOSE + This standard defines the minimum security configuration requirements for all virtual + machines deployed by [Organisation Name] in cloud environments. + +2. BASE IMAGE REQUIREMENTS + - Only approved, centre-maintained base images may be used as the starting point for + new VM deployments + - Base images must be rebuilt with current patches at least every [90 days] + - The image registry must record: image version, last patch date, approved platforms + +3. OPERATING SYSTEM HARDENING REQUIREMENTS + 3.1 Remove or disable all OS features and services not required for the VM's function + 3.2 Apply all available security patches before deployment to production + 3.3 Disable all default credentials; set unique strong credentials or key-based auth + 3.4 Disable remote root / administrator login; require use of privilege escalation + 3.5 Enable host-based firewall; default deny all inbound traffic not explicitly permitted + 3.6 Enable OS-level audit logging covering: authentication events, privilege use, + file access events for sensitive directories, and process execution + 3.7 Configure encrypted storage volumes for all volumes containing sensitive data (CLD.9.5.2) + 3.8 Close all unnecessary listening ports; document all open ports with justification + +4. NETWORK EXPOSURE REQUIREMENTS + - Management ports (SSH [22], RDP [3389]) must not be exposed to the public internet + - Use a VPN, bastion host, or zero-trust access gateway for administrative access + - Apply the cloud provider's security group / network ACL to restrict traffic to + the minimum required + +5. PATCH MANAGEMENT + - Critical patches must be applied within [7] days of release + - High severity patches must be applied within [14] days of release + - Medium severity patches must be applied within [30] days of release + - All patches must be applied within [90] days of release + +6. HARDENING VERIFICATION + - All VMs must be scanned with an approved vulnerability scanner before production use + - Scan results must achieve [required score per tool] before deployment is approved + - Periodic re-scans must be conducted at least [quarterly] + +7. EXCEPTIONS + Deviations from this standard require approval of the [CISO / Security Manager] with + documented compensating controls and review date. + +References: + - ISO/IEC 27017:2015 — CLD.9.5.2 + - CIS Benchmarks (appropriate OS version) + - [Organisation Name] Patch Management Policy +================================================================================ +``` + +--- + +## Template 5 — Cloud Vendor Due Diligence Questionnaire (ISO 27017-Aligned) + +Use this questionnaire when assessing a cloud service provider before engagement. + +``` +=================================================================================== +CLOUD VENDOR SECURITY DUE DILIGENCE QUESTIONNAIRE +=================================================================================== +Vendor Name: [CSP Name] +Service Name: [Service Name] +Service Model: [IaaS / PaaS / SaaS] +Assessment Date: [Date] +Assessed By: [Name / Role] + +SECTION 1 — CERTIFICATIONS AND AUDITS +ISO 27017 Ref: 11.1.1, 15.1.1, 18.1.1 + +Q1. Does the CSP hold an ISO 27001 certification? If yes, provide certificate number and scope. +Q2. Does the CSP hold a SOC 2 Type II report? If yes, provide report date and scope. +Q3. Does the CSP comply with ISO/IEC 27017:2015? Provide evidence. +Q4. What other security certifications does the CSP hold? +Q5. How frequently does the CSP commission third-party penetration tests? Are reports available? + +SECTION 2 — SHARED RESPONSIBILITY +ISO 27017 Ref: CLD.6.3.1 + +Q6. Does the CSP provide a formal shared responsibility document or matrix? +Q7. How does the responsibility allocation differ between IaaS, PaaS, and SaaS tiers offered? + +SECTION 3 — DATA HANDLING +ISO 27017 Ref: CLD.8.1.5, 8.1.2, 10.1.1, 10.1.2, 18.1.1 + +Q8. In which geographic regions is customer data stored? Can customers restrict regions? +Q9. Is customer data encrypted at rest? What algorithm and key length is used? +Q10. Is customer data encrypted in transit? What TLS version is the minimum? +Q11. Does the CSP offer customer-managed encryption keys (BYOK)? If yes, which services? +Q12. What is the data return procedure and format when a contract is terminated? +Q13. What is the timeline for complete deletion of customer data after termination? +Q14. Does the CSP provide a written certificate of deletion on request? + +SECTION 4 — ACCESS CONTROL +ISO 27017 Ref: 9.2.3, 9.4.2, CLD.12.1.5 + +Q15. How is CSP administrator access to customer environments controlled? +Q16. Is MFA required for CSP administrator accounts? Provide evidence. +Q17. Are CSP administrator accesses to customer data logged? Are these logs available to the customer? +Q18. Is formal approval required before a CSP administrator accesses a customer environment? + +SECTION 5 — MONITORING AND LOGGING +ISO 27017 Ref: CLD.12.4.5, 12.4.1, 12.4.2, 12.4.3 + +Q19. What security events are logged for each customer tenancy? +Q20. How long are security logs retained? +Q21. Can customers access their own logs? Via what mechanism (API, dashboard, export)? +Q22. Can logs be exported to the customer's own SIEM? + +SECTION 6 — INCIDENT RESPONSE +ISO 27017 Ref: 16.1.1, 16.1.2, 16.1.7 + +Q23. Within what timeframe will the CSP notify customers of a security incident affecting their data? +Q24. What is the process for notifying customers of incidents? +Q25. Does the CSP cooperate with customer forensic investigations? + +SECTION 7 — BUSINESS CONTINUITY +ISO 27017 Ref: 17.2.1, 17.1.2 + +Q26. What is the published availability SLA (uptime %) for the service? +Q27. What are the RPO and RTO commitments? +Q28. What redundancy mechanisms are in place (multi-region, geo-replication)? +Q29. How frequently is failover tested? + +SECTION 8 — SUPPLY CHAIN +ISO 27017 Ref: 15.1.1, 15.2.1 + +Q30. Who are the sub-processors / sub-service providers with access to customer data? +Q31. Are sub-processors subject to equivalent security requirements? How is this enforced? +Q32. How is the customer notified of changes to sub-processors? +=================================================================================== +``` diff --git a/plugins/iso31000/.claude-plugin/plugin.json b/plugins/iso31000/.claude-plugin/plugin.json new file mode 100644 index 0000000..a4383c7 --- /dev/null +++ b/plugins/iso31000/.claude-plugin/plugin.json @@ -0,0 +1,21 @@ +{ + "name": "iso31000", + "description": "ISO 31000:2018 Risk Management advisor — risk framework design, risk assessment (identification, analysis, evaluation), risk treatment planning, risk register development, risk appetite statements, monitoring and review, and integration with ISO 27001, ISO 9001, and ISO 42001.", + "version": "0.1.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "iso31000", + "risk-management", + "risk-assessment", + "risk-treatment", + "risk-register", + "enterprise-risk", + "grc" + ] +} diff --git a/plugins/iso31000/skills/iso31000/SKILL.md b/plugins/iso31000/skills/iso31000/SKILL.md new file mode 100644 index 0000000..25f1280 --- /dev/null +++ b/plugins/iso31000/skills/iso31000/SKILL.md @@ -0,0 +1,431 @@ +--- +name: iso31000 +description: > + Expert ISO 31000:2018 Risk Management advisor. Use this skill whenever a user asks about + ISO 31000, risk management frameworks, risk assessment, risk identification, risk analysis, + risk evaluation, risk treatment, risk appetite, risk tolerance, risk registers, risk + treatment plans, monitoring and review of risks, recording and reporting, enterprise risk + management (ERM), operational risk, residual risk, inherent risk, risk owners, risk criteria, + risk communication and consultation, or integration of risk management with ISO 27001, + ISO 9001, ISO 42001, or other management systems. Trigger even if the user doesn't say + "skill" -- any ISO 31000 or risk management framework question should use this skill. +--- + +# ISO 31000:2018 Risk Management Skill + +You are an expert ISO 31000:2018 Risk Management consultant and lead practitioner assisting +**risk, compliance, and operations teams**. You have deep knowledge of the ISO 31000:2018 +standard -- its principles, framework, and risk management process -- and can help with +risk framework design, risk assessments, risk registers, risk treatment plans, risk appetite +statements, integration with other ISO standards, and facilitation of risk workshops. + +--- + +## How to Respond + +Always clarify the organisation's sector, size, and risk management maturity level if not +stated, as these factors shape the appropriate depth and complexity of outputs. + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| Risk framework design | Structured narrative: Principles → Framework → Process alignment | +| Gap analysis | Table: Component \| Requirement \| Status 🔴/🟡/🟢 \| Evidence Needed \| Gap Notes | +| Risk assessment | Risk register table with Likelihood × Consequence scoring | +| Risk treatment plan | Table: Risk ID \| Treatment Option \| Action \| Owner \| Due Date \| Residual Risk | +| Risk appetite statement | Structured policy document with tolerance bands per risk category | +| Risk workshop facilitation | Structured agenda + facilitation guide + output templates | +| Policy / procedure generation | Full document with document control block | +| Integration guidance | Mapping table to target standard + integration recommendations | +| General question | Clear, concise prose with standard clause citations | + +Always cite the relevant ISO 31000:2018 clause (e.g., Clause 6.4.2, Clause 5.4) in outputs. + +--- + +## Standard Overview + +**ISO 31000:2018** — *Risk management — Guidelines* — was published in **February 2018**, +replacing ISO 31000:2009. It is a universal, sector-agnostic risk management standard that +applies to any organisation regardless of size, sector, or type of risk. + +ISO 31000 is **not a certifiable standard** — organisations cannot be certified against it. +It provides principles and guidelines that are designed to be integrated into management +processes and into other ISO management system standards (see Integration section below). + +### Three Pillars of ISO 31000:2018 + +``` +ISO 31000:2018 +├── Clause 4 — Principles (8 principles underpinning risk management) +├── Clause 5 — Framework (how risk management is embedded in the organisation) +└── Clause 6 — Process (how individual risks are assessed and treated) +``` + +--- + +## Clause 4 — Principles + +ISO 31000:2018 defines **8 principles** that characterise effective risk management. +All framework and process decisions should be traceable back to these principles. + +| # | Principle | What It Means | +|---|-----------|--------------| +| 1 | **Integrated** | Risk management is embedded in all activities — not a stand-alone process | +| 2 | **Structured and comprehensive** | Consistent, comparable results through systematic approaches | +| 3 | **Customised** | Tailored to the external/internal context and objectives | +| 4 | **Inclusive** | Appropriate stakeholder involvement improves awareness and risk treatment | +| 5 | **Dynamic** | Risks change — risk management anticipates, detects, and responds to those changes | +| 6 | **Best available information** | Decisions informed by historical, current, and forecast data; acknowledging uncertainty | +| 7 | **Human and cultural factors** | Human behaviour and culture significantly influence risk management at every level | +| 8 | **Continual improvement** | Learn from experience and evolve the framework and process | + +When reviewing a risk management programme, assess each principle as: ✅ Embedded / 🟡 Partial / 🔴 Not present. + +--- + +## Clause 5 — Framework + +The framework describes how to **embed risk management into the organisation's governance and +strategic decision-making**. It is an iterative model following the PDCA cycle. + +### 5.1 Leadership and Commitment +Top management and oversight bodies must: +- Align risk management with strategy and objectives +- Issue a risk management policy +- Allocate resources (people, tools, time, budget) +- Establish accountability at all levels +- Ensure risk management is embedded — not siloed + +**Evidence:** Board-level risk management mandate, appointed Chief Risk Officer (or equivalent), +risk management policy signed by top management, board/executive risk committee terms of reference. + +### 5.2 Integration +Risk management must be integrated into all organisational processes — strategic planning, +operations, project management, procurement, HR, and governance. + +**Integration test questions:** +- Does strategic planning include a risk assessment step? +- Are project management gates risk-aware? +- Does procurement assess supplier risk? +- Are KPIs/OKRs risk-informed? + +### 5.3 Design +Design the framework to fit the organisation's context: +1. **Understand the organisation** — external and internal context (use PESTLE/SWOT) +2. **Articulate risk management commitment** — policy statement +3. **Assign roles and responsibilities** — RACI for risk activities +4. **Allocate resources** — budget, tools, training, dedicated staff +5. **Establish communication and consultation** — how risk information flows + +**Key design output:** Risk Management Policy + Risk Management Framework document. + +### 5.4 Implementation +Put the framework into practice: +- Risk management process applied at all relevant organisational levels +- Formal risk management plan with timelines and owners +- Decision-making processes incorporate risk information +- Risk management training and awareness programme + +### 5.5 Evaluation +Periodically measure the performance of the risk management framework: +- Against the policy, risk management plan, and KPIs +- Identify gaps, underperforming areas, and emerging needs +- Report findings to top management + +### 5.6 Improvement +Based on evaluation: +- Adapt the framework to contextual changes (new regulations, strategic pivots, incidents) +- Continual improvement cycle — treat the framework itself as a risk-managed process + +--- + +## Clause 6 — Risk Management Process + +The risk management process consists of **8 interrelated activities**. Communication & +consultation (6.2) and monitoring & review (6.7) run continuously across all other steps. + +``` +6.2 Communication and Consultation ←──────────────────────────────────────────────┐ + │ +6.3 Scope, Context, and Criteria │ + ↓ │ +6.4 Risk Assessment │ + ├── 6.4.2 Risk Identification │ + ├── 6.4.3 Risk Analysis │ + └── 6.4.4 Risk Evaluation │ + ↓ │ +6.5 Risk Treatment │ + ↓ │ +6.6 Monitoring and Review ─────────────────────────────────────────────────────────┘ +6.7 Recording and Reporting (continuous) +``` + +### 6.2 Communication and Consultation +- Involve stakeholders throughout the entire risk process — not just at the start +- Internal: senior leaders, process owners, subject matter experts, affected staff +- External: regulators, customers, suppliers, industry bodies (as appropriate) +- Output: Stakeholder communication plan for risk management + +### 6.3 Scope, Context, and Criteria +Before assessing risks, define: + +**Scope:** What processes, systems, projects, or organisational units are being assessed? + +**External context:** PESTLE factors — political, economic, social, technological, legal, +environmental. Also: regulatory environment, competitive landscape, relationships with +external stakeholders. + +**Internal context:** Organisational culture, structure, governance, capabilities, data +systems, contractual commitments, internal policies. + +**Risk criteria:** The parameters used to evaluate risk significance: +- Likelihood/consequence scales (typically 1–5 or 1–3) +- Risk appetite and tolerance thresholds +- Time horizon +- How combinations of multiple risks will be treated + +### 6.4 Risk Assessment + +#### 6.4.2 Risk Identification +Identify all risks that could affect objectives — both threats and opportunities. + +**Techniques:** +| Technique | Best For | +|-----------|---------| +| Brainstorming / workshops | Initial identification, diverse perspectives | +| SWOT analysis | Strategic risks linked to context | +| PESTLE analysis | External risk sources | +| Process mapping / SIPOC | Operational risks within specific processes | +| Bowtie analysis | Causation chains for complex risks | +| Failure Mode and Effects Analysis (FMEA) | Product/process failure risks | +| Interviews with Subject Matter Experts | Technical, regulatory, or specialist risks | +| Historical incident/near-miss review | Risk sources from past events | +| Checklists / taxonomies | Gap-filling against known risk categories | + +**Risk entry fields:** Risk ID | Risk Description | Risk Category | Risk Source / Cause | +Potential Consequences | Existing Controls | Risk Owner + +#### 6.4.3 Risk Analysis +Determine the nature, likelihood, and consequences of each identified risk. + +**Likelihood × Consequence matrix (5×5):** + +| | **Negligible (1)** | **Minor (2)** | **Moderate (3)** | **Major (4)** | **Catastrophic (5)** | +|---|---|---|---|---|---| +| **Almost Certain (5)** | 5 | 10 | 15 | 20 | **25** | +| **Likely (4)** | 4 | 8 | 12 | **16** | **20** | +| **Possible (3)** | 3 | 6 | 9 | 12 | 15 | +| **Unlikely (2)** | 2 | 4 | 6 | 8 | 10 | +| **Rare (1)** | 1 | 2 | 3 | 4 | 5 | + +**Risk scoring bands:** 🟢 1–4 Low | 🟡 5–9 Medium | 🟠 10–14 High | 🔴 15–25 Critical + +**Analysis dimensions:** +- **Inherent risk**: Risk score BEFORE existing controls are applied +- **Control effectiveness**: How well current controls reduce likelihood/consequence +- **Residual risk**: Risk score AFTER existing controls — decision point for treatment + +#### 6.4.4 Risk Evaluation +Compare the residual risk score against the organisation's risk criteria: +- Is the residual risk within appetite? → Accept / Monitor +- Does residual risk exceed tolerance? → Must treat +- Prioritise risks for treatment based on score and strategic importance + +### 6.5 Risk Treatment +Select and implement options for modifying risk. + +**Treatment options (in order of preference for threat risks):** + +| Option | Description | When to Use | +|--------|-------------|-------------| +| **Avoid** | Eliminate the risk source by stopping the activity | Risk exceeds appetite and cannot be reduced | +| **Reduce (Mitigate)** | Reduce likelihood and/or consequence | Most common — risk can be cost-effectively controlled | +| **Transfer (Share)** | Shift financial consequence to a third party (insurance, contract) | Residual financial risk beyond tolerance; or shared accountability | +| **Accept (Retain)** | Conscious decision to bear the risk | Risk within appetite; treatment cost exceeds benefit | +| **Exploit** | For opportunity risks — take action to realise the upside | When risk represents a strategic opportunity | + +**Risk Treatment Plan format:** + +| Field | Content | +|-------|---------| +| Risk ID | [Unique ID, e.g. R-001] | +| Risk Description | Plain-language description | +| Treatment Option | Avoid / Reduce / Transfer / Accept | +| Proposed Actions | Specific, measurable actions | +| Responsible Owner | Named individual | +| Target Date | Completion deadline | +| Resources Required | Budget, tools, people | +| Expected Residual Risk | Likelihood × Consequence post-treatment | +| KPI / Success Measure | How effectiveness will be verified | +| Review Date | When treatment will be reviewed | + +### 6.6 Monitoring and Review +- Monitor risk controls to ensure they remain effective and relevant +- Review risk register on a defined schedule (typically quarterly + after major incidents) +- Track implementation progress of risk treatment actions +- Report risk status to governance bodies (board, executive, audit committee) + +**Monitoring triggers:** +- Periodic schedule (e.g., quarterly risk register review) +- Material change in business context (merger, new regulation, technology change) +- Near-miss or incident +- Change in strategic objective +- New project or product launch + +### 6.7 Recording and Reporting +Maintain documented evidence of the risk management process: +- Risk register (maintained and version-controlled) +- Risk treatment plans with status updates +- Risk assessment reports +- Board / executive risk reports +- Management review records +- Lessons learned log + +--- + +## Core Workflows + +### 1. Risk Framework Gap Analysis + +**Process:** +1. Ask for: sector, organisation size, current risk maturity (ad hoc / defined / managed / optimised), existing risk tools/registers +2. Assess against all 3 pillars: Principles → Framework (5.1–5.6) → Process (6.2–6.7) +3. Produce a prioritised gap table + +**Output format:** +``` +COMPONENT | REQUIREMENT | STATUS | EVIDENCE NEEDED | GAP NOTES +Principle 1 | Risk management integrated into | 🔴 | Evidence of risk steps | Risk exists as a +(Integrated) | all organisational activities | | in key business | stand-alone quarterly + | | | processes | review; not embedded +5.1 Leadership | Risk policy signed by top management | 🟡 | Signed risk policy | Policy exists but not +& Commitment | | | | approved at board level +6.3 Context | Risk criteria defined | 🔴 | Risk criteria document | No formal likelihood/ +& Criteria | | | | consequence scale +``` + +### 2. Risk Register Development + +**Risk Register columns:** + +| Risk ID | Risk Category | Risk Description | Risk Source | Existing Controls | Inherent L | Inherent C | Inherent Score | Residual L | Residual C | Residual Score | Risk Band | Treatment Option | Treatment Owner | Due Date | Review Date | +|---------|--------------|-----------------|-------------|------------------|-----------|-----------|---------------|-----------|-----------|---------------|-----------|-----------------|----------------|---------|-------------| + +**Standard risk categories:** +- Strategic | Financial | Operational | Compliance / Regulatory | Technology / Cyber | Reputational | Environmental / ESG | People / HR | Third Party / Supply Chain | Project + +When building a risk register: +1. Ask for the scope, sector, and key business objectives +2. Identify at least 3–5 risks per category relevant to the stated context +3. Apply 5×5 matrix for inherent and residual scoring +4. Flag all critical (🔴) and high (🟠) risks for immediate treatment planning +5. Offer to generate a Risk Treatment Plan for high/critical risks + +### 3. Risk Appetite Statement + +A risk appetite statement defines **how much risk the organisation is willing to accept** in +pursuit of its objectives. + +**Structure:** +1. **Overall risk appetite**: Narrative statement of general risk tolerance (e.g., "low appetite for compliance risk; moderate for strategic/growth risk") +2. **Risk category statements**: Specific appetite per category (Strategic, Financial, Operational, Compliance, Technology, Reputational) +3. **Tolerance thresholds**: The maximum residual risk score that triggers mandatory escalation +4. **Review cycle**: How and when appetite will be reviewed + +**Example format:** + +| Risk Category | Appetite Statement | Tolerance Threshold | Escalation Path | +|--------------|--------------------|--------------------|----| +| Compliance / Regulatory | Zero tolerance — no deliberate breaches | Any residual risk ≥ 5 | CEO + General Counsel immediately | +| Strategic | Moderate risk accepted for growth opportunities | Residual score ≤ 12 | Board quarterly review | +| Cyber / Technology | Low tolerance — all critical/high residuals must be treated | Residual score ≤ 8 | CISO + Board Risk Committee | +| Financial | Conservative appetite — no unhedged material exposure | Residual score ≤ 9 | CFO + Audit Committee | + +### 4. Risk Workshop Facilitation Guide + +When asked to plan or facilitate a risk workshop: + +**Pre-workshop preparation:** +- Define scope: what processes, projects, or strategic objectives are being assessed? +- Identify participants: process owners, subject matter experts, risk lead, sponsor +- Distribute pre-read: context document, existing risk register (if any), risk criteria + +**Workshop agenda template:** + +| Time | Activity | Facilitator Action | +|------|----------|-------------------| +| 00:00 | Welcome & objective setting | Confirm scope, explain methodology | +| 00:10 | Context review | Walk through PESTLE/SWOT, confirm risk criteria | +| 00:30 | Risk identification (brainstorm) | Facilitated input: "What could stop us achieving X?" | +| 01:00 | Risk validation & deduplication | Group similar risks, agree register entries | +| 01:30 | Risk analysis (L × C scoring) | Dot voting or consensus scoring; record inherent + residual | +| 02:00 | Risk evaluation & prioritisation | RAG band review, flag top 10 | +| 02:20 | Treatment option discussion | Agree Avoid/Reduce/Transfer/Accept per priority risk | +| 02:40 | Owners and actions | Assign owners, agree treatment deadlines | +| 02:50 | Wrap-up | Agree next review date, reporting format | + +### 5. Policy and Procedure Generation + +When generating a risk management policy: +- Include document control block: Doc ID | Version | Owner | Approved By | Date | Next Review +- Link to relevant ISO 31000:2018 clauses +- Include: Purpose, Scope, Principles, Roles & Responsibilities, Risk Process Overview, + Risk Criteria, Risk Appetite Statement, Reporting Requirements, Review Cycle, References + +**Core risk management documents (recommended minimum set):** + +| Document | ISO 31000 Clause | Mandatory for Compliance? | +|----------|-----------------|--------------------------| +| Risk Management Policy | 5.1, 5.3 | Yes | +| Risk Management Framework document | 5.3 | Yes | +| Risk Register | 6.4.2, 6.7 | Yes | +| Risk Assessment Report | 6.4, 6.7 | Yes (per assessment) | +| Risk Treatment Plan | 6.5, 6.7 | Yes (for H/C risks) | +| Risk Appetite Statement | 6.3 | Strongly recommended | +| Risk Communication Plan | 6.2 | Recommended | +| Monitoring and Review Report | 6.6, 6.7 | Yes (periodic) | +| Lessons Learned Log | Clause 5.6 (improvement) | Recommended | + +--- + +## Integration with Other ISO Management Systems + +ISO 31000 underpins the risk provisions within all ISO Annex SL (High Level Structure) standards. +When asked about integration, use this mapping: + +| Standard | Where ISO 31000 Risk Process Applies | +|----------|-------------------------------------| +| **ISO 27001:2022** | Clause 6.1 (Information security risk assessment and treatment); Annex A controls selected via risk treatment | +| **ISO 9001:2015** | Clause 6.1 (Risk and opportunities for the QMS); Clause 8 operational risk controls | +| **ISO 42001:2023** | Clause 6.1 (AI-specific risk assessment); AI system impact assessment (AISIA) methodology | +| **ISO 14001:2015** | Clause 6.1 (Risks and opportunities for the EMS); environmental aspect/impact assessment | +| **ISO 45001:2018** | Clause 6.1 (OH&S risk assessment); hazard identification and risk controls | +| **NIST CSF 2.0** | GOVERN and IDENTIFY functions; risk assessment directly maps to ID.RA | +| **COSO ERM** | Fully compatible — ISO 31000 process maps to COSO ERM risk assessment components | + +**Integration guidance:** +When an organisation uses ISO 31000 alongside ISO 27001 or ISO 9001: +- A **single integrated risk register** can serve both standards — add columns for standard-specific + fields (e.g., ISO 27001 Annex A control reference; ISO 9001 process reference) +- The **risk criteria** (Clause 6.3) must be defined once and applied consistently +- The **risk appetite** statement can govern treatment thresholds across all management systems +- Use a single **management review** meeting to cover risk status for all integrated standards + +--- + +## Reference Files + +Load these references when needed: + +- **`references/iso31000-framework.md`** — Full framework structure (Clauses 5.1–5.6) with design + checklist, implementation guide, and evaluation criteria +- **`references/iso31000-risk-assessment-process.md`** — Detailed risk assessment guidance: + scope/context/criteria, identification techniques, 5×5 matrix, analysis and evaluation templates +- **`references/iso31000-risk-treatment.md`** — Risk treatment options, treatment plan templates, + risk appetite framework, monitoring and reporting guidance + +Load `references/iso31000-framework.md` for: framework design, gap analysis, leadership/governance questions. +Load `references/iso31000-risk-assessment-process.md` for: risk registers, workshops, identification techniques, scoring. +Load `references/iso31000-risk-treatment.md` for: treatment plans, risk appetite, residual risk, monitoring. diff --git a/plugins/iso31000/skills/iso31000/references/iso31000-framework.md b/plugins/iso31000/skills/iso31000/references/iso31000-framework.md new file mode 100644 index 0000000..2627ff7 --- /dev/null +++ b/plugins/iso31000/skills/iso31000/references/iso31000-framework.md @@ -0,0 +1,258 @@ +# ISO 31000:2018 — Risk Management Framework (Clause 5) + +The ISO 31000 framework describes how to embed risk management as an integral function of +organisational governance and leadership, strategy, and planning, management, reporting, +policies, values, and culture. The framework is iterative and follows the PDCA cycle +(Plan → Do → Check → Act). + +--- + +## Framework Overview + +``` +5.1 Leadership and Commitment (mandate from top) + ↓ +5.2 Integration (embed into all processes) + ↓ +5.3 Design (tailor to the organisation's context) + ↓ +5.4 Implementation (put it into practice) + ↓ +5.5 Evaluation (measure performance) + ↓ +5.6 Improvement (continual improvement cycle) +``` + +The framework is not linear — Improvement (5.6) feeds back into Design (5.3) and +Implementation (5.4) as the organisation learns and its context evolves. + +--- + +## 5.1 Leadership and Commitment + +### What the standard requires +Top management and oversight bodies (e.g., board of directors, council, governing body) must: +- Customise and implement all components of the framework +- Issue a statement or policy confirming risk management commitment +- Ensure accountability, authority, and appropriate competence for managing risk +- Ensure risk management is integrated into all organisational activities +- Allocate necessary resources (human, technological, financial) +- Communicate the value of risk management + +### Design checklist for 5.1 + +| Requirement | Evidence / Output | Status | +|-------------|------------------|--------| +| Top management mandate for risk management | Board/executive resolution or minute | | +| Risk management policy issued and signed | Signed Risk Management Policy | | +| Risk management governance structure defined | Risk committee ToR, RACI chart | | +| Chief Risk Officer (or equivalent) appointed | Organisation chart, role description | | +| Risk management budget allocated | Budget line item or business case approval | | +| Risk management integrated into strategic planning | Strategy documents with risk sections | | + +### Common gaps +- Risk management owned by a single team/function — not integrated across the organisation +- Policy exists but has not been reviewed or renewed in >2 years +- No named risk owner at executive level — risk is "everyone's responsibility" (i.e., nobody's) +- Resources allocated in principle but not in practice (no budget, no dedicated time) + +--- + +## 5.2 Integration + +### What the standard requires +Risk management must be integrated into all organisational functions and processes: +- Governance structures +- Strategic and operational planning +- HR processes (recruitment, competency, performance) +- Project and change management +- Financial planning and investment decisions +- IT and technology governance +- Procurement and supplier management +- Operational procedures + +### Integration maturity levels + +| Level | Description | Characteristics | +|-------|-------------|----------------| +| **Ad hoc** | Risk assessed only when a crisis occurs | No formal process; reactive; risk as a compliance checkbox | +| **Defined** | Formal risk process exists but runs in parallel to business | Separate risk register; annual reviews; limited business ownership | +| **Managed** | Risk integrated into key business processes | Risk gates in projects, investment, procurement; regular reviews | +| **Optimised** | Risk management is a strategic capability | Risk informs strategic decisions; risk culture embedded; dynamic framework | + +### Integration test questions (use during gap analysis) + +1. Is risk formally assessed as part of the annual strategic planning cycle? +2. Do project management gates include a risk assessment step? +3. Are board/executive decisions accompanied by a risk statement? +4. Does HR/people management include role-based risk training and competency assessments? +5. Does procurement include supplier risk assessments before contract award? +6. Are operational changes (new systems, process changes) formally risk-assessed? +7. Are financial models adjusted for risk scenarios (best/worst/base)? + +--- + +## 5.3 Design + +The design phase tailors the risk management framework to the organisation's specific context. + +### Step 1: Understand the Organisation and Its Context + +#### External Context +Use a structured model to capture external risk drivers: + +| PESTLE Factor | Examples of External Risk Sources | +|--------------|----------------------------------| +| **Political** | Government policy changes, geopolitical instability, elections, sanctions | +| **Economic** | Inflation, interest rates, recession, currency fluctuations, supply chain costs | +| **Social** | Demographic shifts, workforce availability, changing customer expectations, social licence | +| **Technological** | Cyber threats, disruptive technologies, AI adoption, legacy system obsolescence | +| **Legal / Regulatory** | New legislation, regulatory enforcement trends, litigation risk, privacy law changes | +| **Environmental** | Climate change impacts, ESG obligations, natural disaster exposure, resource scarcity | + +#### Internal Context +| Internal Factor | Examples | +|----------------|---------| +| **Governance and culture** | Risk culture maturity, tolerance for failure, leadership style | +| **Strategy and objectives** | What the organisation is trying to achieve — risks are threats/opportunities to these | +| **Capabilities and resources** | People skills, financial strength, technology infrastructure | +| **Information systems** | Quality of data, access controls, data dependencies | +| **Stakeholder relationships** | Customer dependencies, partner agreements, community expectations | +| **Contractual obligations** | SLAs, regulatory licences, supply agreements that create risk exposure | + +### Step 2: Articulate Risk Management Commitment +Output: **Risk Management Policy** — must address: +- The organisation's rationale for risk management +- Links between risk management and strategic objectives +- Risk appetite and tolerance statement (or reference to separate document) +- Roles and responsibilities (RACI) +- Requirement to maintain a risk register and risk treatment plans +- Review cycle for the policy itself (minimum annually) + +### Step 3: Assign Roles and Responsibilities + +**RACI for Risk Management:** + +| Activity | Board / Oversight | Executive / CEO | CRO / Risk Function | Process Owners | All Staff | +|----------|------------------|----------------|--------------------|----|---| +| Set risk appetite | A | I | R | I | I | +| Approve risk management policy | A | C | R | I | I | +| Oversee risk reporting | A | R | R | I | - | +| Conduct risk assessments | I | I | C | R | C | +| Own and treat risks | I | A | C | R | - | +| Report risk status | I | A | R | C | - | +| Implement risk controls | - | I | C | A | R | + +(R = Responsible, A = Accountable, C = Consulted, I = Informed) + +### Step 4: Allocate Resources + +Minimum resources required for a functioning risk management framework: +- **People**: Named risk manager / CRO (or part-time equivalent for small organisations) +- **Tools**: Risk register (spreadsheet minimum; GRC platform for complex organisations) +- **Training**: Annual risk awareness training; specialist training for risk owners +- **Time**: Quarterly risk reviews; annual full risk assessment cycle; board risk reporting +- **Budget**: Risk treatment budget allocation; tool/platform costs + +### Step 5: Establish Communication and Consultation +Define: +- Internal reporting frequency and format (quarterly risk report to board, monthly to exec) +- External stakeholder communication (regulators, investors, customers as applicable) +- Escalation paths: who is notified when a new critical risk is identified? +- Risk disclosure obligations (annual report, regulatory filings) + +--- + +## 5.4 Implementation + +### Implementation Roadmap Template + +| Phase | Timeline | Activities | Owner | Success Criteria | +|-------|----------|-----------|-------|-----------------| +| **Foundation** | Month 1–2 | Appoint risk lead; draft Risk Management Policy; confirm risk criteria | CEO / HR | Policy signed; roles assigned | +| **Assessment** | Month 2–4 | Conduct first risk assessment; build initial risk register; set risk appetite | CRO / Risk Lead | Risk register populated; top 10 risks scored | +| **Treatment** | Month 3–5 | Develop Risk Treatment Plans for high/critical risks; assign owners | Risk Owners | Treatment plans signed off; actions started | +| **Integration** | Month 4–6 | Embed risk steps into strategic planning, project, procurement processes | Process Owners | Process documents updated; training delivered | +| **Review** | Month 6+ | First quarterly risk review; board risk report; lessons learned | CRO / Board | Review completed; risk register updated | +| **Optimise** | Ongoing | Continuous improvement; tool upgrades; culture programme | All | Framework evaluation score improving | + +--- + +## 5.5 Evaluation + +Evaluate the performance of the risk management framework on a defined schedule (typically annually, plus after major incidents or strategic changes). + +### Framework Evaluation Criteria + +| Component | Evaluation Questions | Evidence Sources | +|-----------|---------------------|-----------------| +| **5.1 Leadership** | Is top management actively engaged? Is risk on the board agenda? | Board minutes, committee papers | +| **5.2 Integration** | Is risk embedded in strategic and operational decisions? | Process documents, project files, investment decisions | +| **5.3 Design** | Is the framework still fit for the organisation's current context? | Policy review, context analysis | +| **5.4 Implementation** | Are risk management activities being carried out as designed? | Risk register dates, treatment plan progress | +| **5.5 Evaluation** | Are we measuring and reporting risk management performance? | KPIs, management review records | +| **5.6 Improvement** | Have improvements been identified and implemented? | Lessons learned log, framework change log | + +### Risk Management KPIs + +| KPI | Measurement | Target | +|-----|------------|--------| +| Risk register coverage | % of business processes with assessed risks | 100% of critical processes | +| Treatment plan completion | % of high/critical treatment actions completed on time | ≥ 85% | +| Review cycle adherence | Quarterly risk reviews completed | 4 of 4 per year | +| Escalation response time | Time from risk identification to escalation to executive | < 48 hours for critical risks | +| Risk culture awareness | % of staff who completed risk awareness training | ≥ 90% annually | +| Board risk reporting | Risk reports submitted to board on schedule | 100% | + +--- + +## 5.6 Improvement + +Improvement should be triggered by: +- Evaluation findings (5.5) — gaps in framework effectiveness +- Major incidents or near-misses — root cause often traceable to framework gaps +- Strategic or contextual changes — new markets, regulations, technologies +- Audit findings — internal or external audits of the risk management function +- Benchmark comparisons — peer organisations, industry best practice + +**Improvement process:** +1. Identify improvement area (from evaluation, incident review, or audit) +2. Determine root cause (5-WHY or similar) +3. Define improvement action with owner and deadline +4. Implement and verify effectiveness +5. Update framework documentation +6. Communicate changes to stakeholders + +--- + +## Framework Design Checklist (Summary) + +Use this as a gap analysis tool — tick each item as Implemented / Partial / Not Present: + +**Leadership and Governance:** +- [ ] Risk management policy issued and signed by top management (5.1) +- [ ] Risk management governance structure defined (roles, committee, RACI) (5.1) +- [ ] Designated risk lead / CRO role (5.1) +- [ ] Resources (people, budget, tools) formally allocated (5.1) + +**Integration:** +- [ ] Risk management steps embedded in strategic planning (5.2) +- [ ] Risk gates in project management methodology (5.2) +- [ ] Supplier/procurement risk assessment process (5.2) +- [ ] Risk management incorporated into HR/people processes (5.2) + +**Design:** +- [ ] External and internal context documented (5.3) +- [ ] Risk criteria defined (likelihood/consequence scales, tolerance thresholds) (5.3) +- [ ] Risk appetite statement in place (5.3) + +**Process:** +- [ ] Risk register in place and maintained (6.4) +- [ ] Risk treatment plans for high/critical risks (6.5) +- [ ] Monitoring and review schedule defined (6.6) +- [ ] Risk reporting to executive and board (6.7) + +**Evaluation and Improvement:** +- [ ] Annual framework evaluation conducted (5.5) +- [ ] Risk management KPIs tracked (5.5) +- [ ] Improvement log maintained (5.6) diff --git a/plugins/iso31000/skills/iso31000/references/iso31000-risk-assessment-process.md b/plugins/iso31000/skills/iso31000/references/iso31000-risk-assessment-process.md new file mode 100644 index 0000000..b82be00 --- /dev/null +++ b/plugins/iso31000/skills/iso31000/references/iso31000-risk-assessment-process.md @@ -0,0 +1,312 @@ +# ISO 31000:2018 — Risk Assessment Process (Clause 6) + +This reference covers the detailed risk management process defined in Clause 6 of +ISO 31000:2018 — from establishing scope, context, and criteria (6.3) through risk +identification (6.4.2), risk analysis (6.4.3), and risk evaluation (6.4.4). + +--- + +## Clause 6.3 — Scope, Context, and Criteria + +Before any risk assessment begins, three foundation inputs must be defined. + +### Scope Definition + +The scope sets the boundary for the risk assessment. Define: + +| Scope Element | Questions to Answer | +|--------------|-------------------| +| **Organisational boundary** | Which divisions, sites, or business units are included? | +| **Process boundary** | Which processes, systems, or projects are in scope? | +| **Time horizon** | Short-term (12 months)? Medium (3 years)? Long-term (5+ years)? | +| **Risk types** | All risk categories? Or specific types (e.g., cyber, financial, operational only)? | +| **Stakeholder universe** | Who has an interest in or influence over the risks in scope? | + +**Scope statement template:** +> "This risk assessment covers [process/project/division] within [organisation name] +> for the period [start date] to [end date]. It encompasses risks of type [categories] +> that could affect the achievement of [specific objectives]. Out of scope: [explicit exclusions]." + +### Context Setting + +#### External Context — PESTLE Analysis Template + +| Factor | Risk Source / Issue | Potential Impact on Objectives | Current Controls | +|--------|--------------------|---------------------------------|-----------------| +| Political | | | | +| Economic | | | | +| Social | | | | +| Technological | | | | +| Legal / Regulatory | | | | +| Environmental | | | | + +#### Internal Context — Key Questions +1. What are the organisation's strategic objectives? (Risks are threats/opportunities to these) +2. What are the organisation's core capabilities and key dependencies? +3. What is the risk culture — risk-averse, risk-neutral, or risk-seeking? +4. What are the existing governance and control structures? +5. What internal constraints exist (budget, resourcing, regulatory obligations)? +6. What are the organisation's key performance indicators that risk events could disrupt? + +### Criteria Definition + +Risk criteria must be agreed before scoring begins to ensure consistency. + +#### Likelihood Scale + +| Score | Label | Definition | Example Frequency | +|-------|-------|-----------|------------------| +| 5 | Almost Certain | Expected to occur in most circumstances | Several times per year | +| 4 | Likely | Will probably occur in most circumstances | Once per year or more | +| 3 | Possible | Might occur at some time | Every 2–5 years | +| 2 | Unlikely | Could occur at some time | Every 5–10 years | +| 1 | Rare | May only occur in exceptional circumstances | Less than once per 10 years | + +#### Consequence Scale + +Calibrate consequence descriptors to the organisation's size, sector, and objectives. + +| Score | Label | Financial | Reputational | Operational | Regulatory / Legal | +|-------|-------|-----------|-------------|-------------|--------------------| +| 5 | Catastrophic | Loss > 20% annual revenue / insolvency risk | National/international media; long-term brand damage | Complete cessation of operations | Criminal prosecution; licence revocation | +| 4 | Major | Loss 5–20% annual revenue | Significant national media; sustained negative coverage | Major disruption > 1 week | Regulatory enforcement action; significant fines | +| 3 | Moderate | Loss 1–5% annual revenue | Regional media; sector-level notice | Disruption 1–7 days | Formal regulatory warning; investigation | +| 2 | Minor | Loss 0.1–1% annual revenue | Limited local coverage; manageable | Disruption < 24 hours | Compliance breach; informal regulatory notice | +| 1 | Negligible | Loss < 0.1% annual revenue | No media coverage; internal reputational impact | Temporary inconvenience | Minor procedural non-compliance | + +#### Risk Tolerance Thresholds (example — adjust to match organisational appetite) + +| Score Range | Risk Band | Default Treatment Decision | +|------------|-----------|---------------------------| +| 15–25 | 🔴 Critical | Mandatory treatment; escalate to executive/board immediately | +| 10–14 | 🟠 High | Treatment plan required within 30 days; monthly monitoring | +| 5–9 | 🟡 Medium | Treatment plan required within 90 days; quarterly monitoring | +| 1–4 | 🟢 Low | Accept with monitoring; annual review | + +--- + +## Clause 6.4.2 — Risk Identification + +The goal is to identify **all sources of risk** — both threats (negative outcomes) and +opportunities (positive outcomes) — that could affect the achievement of objectives. + +### Risk Identification Techniques + +#### 1. Structured Workshop / Brainstorming + +**Best for:** Initial identification; diverse team input; new risk domains. + +**Facilitation prompt sequence:** +1. "What events or circumstances could prevent us from achieving [objective X]?" +2. "What incidents have occurred before in this organisation or sector?" +3. "What has changed recently that introduces new risk?" (regulatory, market, technology) +4. "What assumptions are we making that could prove wrong?" +5. "Where are our biggest dependencies — what happens if they fail?" + +#### 2. SWOT Analysis for Risk Identification + +| | Positive | Negative | +|--|----------|---------| +| **Internal** | **Strengths** (what we can exploit) | **Weaknesses** (internal vulnerabilities) | +| **External** | **Opportunities** (upside risks to pursue) | **Threats** (external threats to address) | + +#### 3. Process Mapping / SIPOC + +Mapping processes reveals risk at each step: + +| Suppliers | Inputs | Process | Outputs | Customers | +|-----------|--------|---------|---------|-----------| +| Who/what provides inputs? | What enters the process? | What happens? | What exits? | Who receives outputs? | +| **Risk:** Supplier failure | **Risk:** Poor quality inputs | **Risk:** Process failure, human error | **Risk:** Non-conforming outputs | **Risk:** Customer/stakeholder dissatisfaction | + +#### 4. Bowtie Analysis + +Bowtie is excellent for complex risks with multiple causation paths and consequence scenarios: + +``` +Cause 1 ──┐ +Cause 2 ──┤── [Preventive Controls] ──► RISK EVENT ──► [Recovery Controls] ──┬── Consequence A +Cause 3 ──┘ ├── Consequence B + └── Consequence C +``` + +- **Left side (threats):** Root causes and preventive controls +- **Centre:** The undesired risk event (the "top event") +- **Right side (consequences):** Impacts and recovery/mitigation controls + +#### 5. FMEA — Failure Mode and Effects Analysis + +Best for operational, product, or process failure risks: + +| Process Step | Failure Mode | Effect of Failure | Severity (1–10) | Occurrence (1–10) | Detection (1–10) | RPN = S×O×D | Recommended Action | +|-------------|-------------|------------------|----------------|------------------|-----------------|-------------|-------------------| + +RPN = Risk Priority Number. Score > 100 typically requires action. + +#### 6. Taxonomy-Based Risk Checklist + +Run through standard risk category checklists to avoid blind spots: + +**Strategic risks:** Market position, competitor action, strategic misalignment, M&A integration, +key leadership departure, innovation failure, investor relations + +**Financial risks:** Liquidity, credit, currency, interest rate, tax, insurance gap, +budget overrun, fraud, treasury management + +**Operational risks:** Process failure, human error, system downtime, quality defects, +supply chain disruption, facilities damage, health and safety + +**Technology / Cyber risks:** Ransomware, data breach, system availability, legacy +technology debt, software vulnerability, shadow IT, vendor security failure + +**Compliance / Regulatory risks:** Regulatory change, non-compliance with licence conditions, +data protection breach, employment law, environmental obligation, product liability + +**Reputational risks:** Media/social media exposure, whistleblower incidents, ESG +performance, executive misconduct, product recall, customer complaint surge + +**People / HR risks:** Key person dependency, skills shortage, industrial action, +succession failure, workplace culture (harassment, discrimination) + +**Third party / Supply chain risks:** Single-source dependency, supplier insolvency, +outsourced service failure, geopolitical supply disruption, counterparty default + +### Risk Description Template + +For each identified risk: + +``` +Risk ID: [Unique reference, e.g. R-001] +Risk Category: [Strategic / Financial / Operational / Cyber / Compliance / etc.] +Risk Description: [Clear plain-language statement: "The risk that [X] occurs, caused by [Y], + resulting in [Z]."] +Risk Source: [Root cause or triggering event] +Existing Controls:[Controls currently in place to manage this risk] +Risk Owner: [Named individual accountable for managing this risk] +Date Identified: [Date] +``` + +### Risk Register Template (Full) + +| Risk ID | Category | Risk Description | Risk Source | Existing Controls | Inherent L (1–5) | Inherent C (1–5) | Inherent Score | Control Effectiveness | Residual L | Residual C | Residual Score | Band 🔴🟠🟡🟢 | Treatment Option | Owner | Target Date | Review Date | Status | +|---------|---------|-----------------|-------------|------------------|---------|---------|----------|-----------|-----------|-----------|---------|------|------|------|---------|-------------|------| + +--- + +## Clause 6.4.3 — Risk Analysis + +Risk analysis determines the level of risk to enable evaluation and treatment prioritisation. + +### 5×5 Likelihood × Consequence Matrix + +``` +Consequence → + 1-Negligible 2-Minor 3-Moderate 4-Major 5-Catastrophic + 5 5 10 15 20 25 🔴 +L 4 4 8 12 16 🔴 20 🔴 +i 3 3 6 9🟡 12 🟠 15 🔴 +k 2 2 4 6🟡 8🟡 10 🟠 +e 1 1 2 3🟢 4🟢 5 🟡 +l +``` + +Legend: +- 🔴 Critical (15–25): Escalate immediately; mandatory treatment +- 🟠 High (10–12): Treatment plan within 30 days +- 🟡 Medium (5–9): Treatment plan within 90 days +- 🟢 Low (1–4): Accept; monitor annually + +### Inherent vs Residual Risk + +| Term | Definition | When Used | +|------|-----------|-----------| +| **Inherent risk** | Raw risk score BEFORE any controls are applied | Understand worst-case exposure | +| **Control effectiveness** | Assessment of how well existing controls reduce likelihood and/or consequence | Evaluate adequacy of current controls (Effective / Partially Effective / Ineffective) | +| **Residual risk** | Risk level AFTER existing controls are applied | The actual risk exposure; decision point for further treatment | +| **Target residual risk** | The desired risk level after treatment is implemented | The goal for the risk treatment plan | + +### Qualitative vs Quantitative Analysis + +| Approach | When to Use | Methods | +|----------|------------|---------| +| **Qualitative** (1–5 scales) | Most risks; initial assessments; limited data | L×C matrix, expert judgment, workshops | +| **Semi-quantitative** | Financial risks; risks with some historical data | Loss exposure ranges linked to consequence scores | +| **Quantitative** | High-value risks; financial modelling; insurance | Monte Carlo simulation, Value at Risk (VaR), Expected Loss | + +### Multi-Dimensional Analysis + +For complex risks, analyse across multiple consequence dimensions: + +| Risk | Financial Impact | Operational Impact | Reputational Impact | Regulatory Impact | Composite Score | +|------|----------------|------------------|--------------------|--------------------|----------------| +| [Risk 1] | 3 | 4 | 2 | 3 | 3.0 (avg) | + +Use the **highest single dimension** as the consequence score (not the average) — this is +the conservative approach recommended by most risk practitioners. + +--- + +## Clause 6.4.4 — Risk Evaluation + +Risk evaluation determines which risks require treatment, what priority, and what form of +treatment is appropriate. + +### Evaluation Steps + +1. **Compare residual risk score to risk criteria:** Is the residual risk within the + organisation's defined tolerance thresholds? + +2. **Apply the treatment decision rule:** + + | Residual Score | Band | Decision | + |---------------|------|----------| + | ≥ 15 | 🔴 Critical | Must treat — escalate to board/executive; treatment plan mandatory | + | 10–14 | 🟠 High | Must treat — risk treatment plan within 30 days | + | 5–9 | 🟡 Medium | Should treat — risk treatment plan within 90 days | + | 1–4 | 🟢 Low | Accept — periodic review; document acceptance decision | + +3. **Prioritise treatment order:** Where multiple high/critical risks exist: + - First: Risks that exceed risk appetite by the greatest margin + - Second: Risks with the highest consequence (catastrophic impact even if low likelihood) + - Third: Risks with highest strategic relevance to organisational objectives + +4. **Document the evaluation rationale:** For any risk that is accepted, record: + - Why the risk is accepted (cost of treatment vs. residual risk level) + - Who authorised acceptance (must be at appropriate seniority level) + - Review date for the acceptance decision + +### Risk Evaluation Output: Prioritised Risk Summary + +| Priority | Risk ID | Risk Description | Residual Score | Band | Recommended Treatment | Owner | +|----------|---------|----------------|---------------|------|-----------------------|-------| +| 1 | R-007 | [Description] | 20 | 🔴 | Avoid or Reduce — immediate action | [Name] | +| 2 | R-003 | [Description] | 16 | 🔴 | Reduce — treatment plan this month | [Name] | +| 3 | R-011 | [Description] | 12 | 🟠 | Transfer (insure) + Reduce controls | [Name] | + +--- + +## Communication and Consultation (Clause 6.2) — Running Thread + +Communication and consultation are not a one-time step — they run throughout the entire +risk management process. + +### Stakeholder Consultation Plan + +| Stakeholder Group | Interest in Risk | Engagement Method | Frequency | +|-------------------|-----------------|------------------|-----------| +| Board / Oversight body | Overall risk exposure and appetite | Risk report at board meeting | Quarterly | +| Executive team | Strategic and operational risk status | Risk dashboard + narrative | Monthly | +| Process owners | Risks within their area of responsibility | Risk assessment workshops | Quarterly | +| All staff | Awareness of operational risks and controls | Training; intranet updates | Annually + ad hoc | +| External auditors | Risk register accuracy and control adequacy | Audit file + interviews | Annual audit cycle | +| Regulators | Material risks that may affect regulatory obligations | Mandatory disclosures as required | Per regulation | + +### Internal Risk Reporting Schedule + +| Report | Audience | Frequency | Contents | +|--------|---------|-----------|---------| +| Risk Register | CRO / Risk function | Ongoing / real-time | Full risk inventory | +| Risk Dashboard | Executive team | Monthly | Top 10 risks; RAG status; treatment progress | +| Board Risk Report | Board / oversight committee | Quarterly | Risk appetite status; critical risks; emerging risks | +| Annual Risk Report | All stakeholders | Annually | Full risk review; framework evaluation; year-ahead outlook | +| Incident / Near-miss report | CRO + relevant exec | Within 48 hours | Nature of event; potential risk implication; immediate response | diff --git a/plugins/iso31000/skills/iso31000/references/iso31000-risk-treatment.md b/plugins/iso31000/skills/iso31000/references/iso31000-risk-treatment.md new file mode 100644 index 0000000..9d851e6 --- /dev/null +++ b/plugins/iso31000/skills/iso31000/references/iso31000-risk-treatment.md @@ -0,0 +1,358 @@ +# ISO 31000:2018 — Risk Treatment, Appetite, and Monitoring (Clauses 6.5–6.7) + +This reference covers risk treatment (Clause 6.5), risk appetite and tolerance frameworks +(supporting Clause 6.3 criteria), monitoring and review (Clause 6.6), and recording and +reporting (Clause 6.7). + +--- + +## Clause 6.5 — Risk Treatment + +Risk treatment modifies risk. For **threat risks**, treatment reduces either likelihood, +consequence, or both. For **opportunity risks**, treatment increases the probability of the +beneficial outcome. + +### Treatment Options — Full Reference + +#### 1. Avoid (Eliminate) +Stop the activity that gives rise to the risk, or change the way the objective is achieved. + +**When to use:** +- The risk score remains critical even after realistic control investment +- The cost and consequence of an event far outweigh the benefits of the activity +- A less risky path to the same objective exists + +**Examples:** +- Withdraw from a high-risk market or jurisdiction +- Retire a legacy IT system that cannot be adequately secured +- Decline a contract where liability exposure is unacceptable +- Discontinue a product line with unresolvable safety risks + +**Considerations:** Avoidance may mean foregoing opportunity / revenue. Always assess +whether the upside being avoided is significant. + +#### 2. Reduce (Mitigate) +Implement controls that reduce likelihood of the risk occurring, reduce the severity of +consequences if it does occur, or both. + +**Preventive controls (reduce likelihood):** +- Staff training and competency programmes +- Process controls and standard operating procedures (SOPs) +- Preventive maintenance programmes +- Access controls and authorisation requirements +- Supplier qualification and monitoring +- Redundancy / failover systems + +**Detective controls (early warning / limit consequence):** +- Monitoring and alert systems +- Internal audit and assurance activities +- KPI dashboards and trend analysis +- Exception reporting and escalation triggers +- Testing and scenario exercises (fire drills, business continuity tests) + +**Recovery controls (reduce consequences after event):** +- Business Continuity Plans (BCPs) +- Disaster Recovery Plans (DRPs) +- Crisis Communications Plans +- Insurance coverage +- Data backup and restore procedures + +**Control effectiveness assessment:** + +| Rating | Description | +|--------|-------------| +| **Effective** | Control operates as designed; evidence of routine operation; tested and verified | +| **Partially Effective** | Control exists but has gaps: not consistently applied, not tested, or provides partial coverage | +| **Ineffective** | Control exists on paper but is not operating; or no control present | + +#### 3. Transfer (Share) +Shift the financial or operational burden of risk consequence to a third party. + +**Mechanisms:** +| Transfer Mechanism | How It Works | Best For | +|------------------|----|---------| +| **Insurance** | Premium paid; insurer covers defined losses | Property, liability, cyber, professional indemnity | +| **Contractual transfer** | Indemnification clauses, warranties, limitation of liability | Supplier contracts, outsourcing agreements, SLAs | +| **Joint ventures / shared ownership** | Risk shared across partners | Capital-intensive projects; markets with political risk | +| **Derivatives / hedging** | Financial instruments to offset currency/commodity risk | Financial and commodity risk | + +**Important limitations of transfer:** +- Transfer removes financial exposure but NOT operational or reputational risk +- Responsibility and accountability (regulatory, ethical) cannot be transferred +- Insurance may not cover the full loss (deductibles, exclusions, policy limits) +- Contractual transfer is only as good as the counter-party's ability to pay + +#### 4. Accept (Retain) +Make an informed decision to bear the risk without additional treatment. + +**When to use:** +- The residual risk score is within the organisation's defined appetite +- The cost of treatment exceeds the expected value of the risk reduction +- The risk is so remote (Rare × Negligible) that treatment is not warranted + +**Requirements for risk acceptance:** +- Documented acceptance decision (not a default / unaware acceptance) +- Acceptance authorised at appropriate seniority (see RACI): + - 🟢 Low → Process owner may accept + - 🟡 Medium → Department head / line manager must accept + - 🟠 High → Senior executive / CRO must accept and document rationale + - 🔴 Critical → Board / CEO acceptance required; review every quarter +- Defined review date — acceptance decisions must be periodically re-evaluated +- Contingency plans in place for accepted risks above 🟡 Medium + +#### 5. Exploit (for opportunity risks) +Actively pursue a risk to maximise the probability of a beneficial outcome. + +**Examples:** +- Fast-follow strategy in a new market where competitor risk is the "opportunity" +- Investing in AI capability ahead of regulatory clarification (opportunity = first-mover) +- Acquiring a distressed competitor + +--- + +### Risk Treatment Plan — Full Template + +``` +RISK TREATMENT PLAN + +Risk ID: [e.g. R-007] +Risk Description: [Plain-language description of the risk] +Risk Category: [Strategic / Operational / Financial / Cyber / Compliance / etc.] +Current Residual Risk: Likelihood [1-5] × Consequence [1-5] = Score [___] Band [🔴🟠🟡🟢] +Treatment Option: [Avoid / Reduce / Transfer / Accept / Exploit] + +TARGET RESIDUAL RISK (after treatment): + Likelihood: [Target L] + Consequence: [Target C] + Target Score: [Target Score] Target Band: [🟢🟡🟠] + +TREATMENT ACTIONS: + +| # | Action | Description | Owner | Resources Required | Due Date | Status | +|---|--------|-------------|-------|-------------------|---------|--------| +| 1 | | | | | | Not Started | +| 2 | | | | | | Not Started | +| 3 | | | | | | Not Started | + +SUCCESS MEASURES / KPIs: + [How will effectiveness of treatment be measured? What evidence will confirm the + target residual risk has been achieved?] + +REVIEW DATE: [Date when treatment plan progress will next be formally reviewed] +PLAN OWNER: [Named senior owner accountable for treatment completion] +APPROVED BY: [Name and title] +APPROVAL DATE: [Date] +``` + +--- + +### Treatment Selection Decision Framework + +When selecting a treatment, consider: + +1. **Is the residual risk within appetite?** + - Yes → Consider Accept (with documented decision) + - No → Proceed to treatment selection + +2. **Can the risk source be eliminated?** + - Yes, without major business impact → Consider Avoid + - No, or avoidance sacrifices critical objectives → Continue + +3. **Is there a cost-effective way to reduce likelihood or consequence?** + - Yes → Reduce (identify specific preventive/detective/recovery controls) + - No (treatment cost > Expected risk value) → Consider Transfer or Accept + +4. **Can the financial exposure be transferred?** + - Insurable risk → Transfer (insurance) + - Contractually assignable → Transfer (contractual mechanisms) + +5. **Is the risk within appetite even without further treatment?** + - Yes → Accept with documented rationale + - No → Escalate for management decision; consider business case for avoidance + +--- + +## Risk Appetite Framework + +### Definitions + +| Term | Definition | +|------|-----------| +| **Risk appetite** | The amount and type of risk the organisation is willing to take in pursuit of its objectives | +| **Risk tolerance** | The organisation's readiness to bear the risk AFTER treatment (i.e., the maximum acceptable residual risk level) | +| **Risk capacity** | The maximum risk the organisation can absorb before viability is threatened | +| **Risk attitude** | The organisation's approach to risk — risk-averse, risk-neutral, or risk-seeking | + +**Key relationship:** Appetite ≤ Tolerance ≤ Capacity + +### Risk Appetite Statement Structure + +A risk appetite statement should contain: + +1. **Overarching appetite narrative** — a single statement summarising the organisation's + general relationship with risk in the context of its strategy + +2. **Category-level appetite statements** — specific statements for each major risk category + +3. **Tolerance thresholds** — the maximum residual risk score that triggers mandatory + escalation or treatment (linked to the risk scoring scale) + +4. **Boundaries (zero-tolerance areas)** — risk types the organisation will not accept + under any circumstances (e.g., deliberate regulatory breach, health and safety + violations, fraud) + +### Risk Appetite Statement Template + +--- +**[Organisation Name] Risk Appetite Statement** +**Version:** [X.X] | **Approved By:** [Name, Title] | **Date:** [Date] | **Review:** [Date] + +**Overarching Statement:** +> [Organisation name] pursues its strategic objectives with a [low/moderate/measured] +> overall risk appetite. We accept calculated risks that support growth, innovation, and +> value creation, while maintaining zero tolerance for risks that threaten the safety of +> our people, the integrity of our compliance obligations, or the security of our customers' +> data. + +**Category Appetites:** + +| Risk Category | Appetite Level | Tolerance Threshold (max residual score) | Zero-Tolerance Triggers | +|--------------|---------------|----------------------------------------|------------------------| +| **Strategic** | Moderate | 12 (🟠 High) | Reputational catastrophe; insolvency risk | +| **Financial** | Conservative | 9 (🟡 Medium) | Unexpected loss > [X]% revenue | +| **Operational** | Low–Moderate | 9 (🟡 Medium) | Safety incident; major service failure | +| **Cyber / Technology** | Low | 8 (🟡 Medium) | Breach of customer PII; material data loss | +| **Compliance / Regulatory** | Very Low | 5 (🟡 Medium) | Any deliberate non-compliance; criminal breach | +| **Reputational** | Low | 8 (🟡 Medium) | Sustained media / public reputational damage | +| **Environmental / ESG** | Low | 6 (🟡 Medium) | Environmental incident; ESG disclosure failure | +| **People / HR** | Low–Moderate | 9 (🟡 Medium) | Workplace safety failure; key person loss cascade | + +**Approval and Review:** This statement is approved by [Board / CEO] and reviewed annually +or when the strategic context materially changes. + +--- + +### Using Risk Appetite in Practice + +1. **Risk assessment gate:** After scoring each risk, compare residual score against the + relevant appetite band. Any risk exceeding the tolerance threshold must have a + treatment plan. + +2. **Investment decisions:** New projects / initiatives include a risk statement confirming + that the risk profile is within appetite. Decisions outside appetite require explicit + board/executive sign-off. + +3. **Escalation trigger:** When a risk is identified or an event occurs that breaches the + tolerance threshold, the escalation path (from the appetite statement) is activated + automatically. + +4. **Annual review:** The board reviews the appetite statement annually. Changes in + strategy, regulation, or risk environment may shift appetite levels. + +--- + +## Clause 6.6 — Monitoring and Review + +Monitoring ensures that risk controls remain effective and that the risk picture (likelihood, +consequence) keeps pace with changes in context. + +### Monitoring Schedule + +| Activity | Frequency | Owner | Output | +|----------|-----------|-------|--------| +| Risk register review | Quarterly | CRO / Risk Lead | Updated risk register | +| Control effectiveness testing | Annually (or event-driven) | Risk Owner + Internal Audit | Control effectiveness ratings updated | +| Board risk reporting | Quarterly | CRO | Board risk report | +| Executive risk dashboard | Monthly | CRO | Risk dashboard update | +| Full risk reassessment | Annually (+ after major changes) | Risk Lead + Process Owners | Refreshed risk register | +| Incident / near-miss review | Within 48 hours of event | CRO + relevant Process Owner | Incident report; risk register update | + +### Monitoring Triggers — Event-Driven Review + +Risk reassessment should be initiated whenever: +- A material strategic change occurs (M&A, new market, restructure) +- A significant regulatory or legal change is announced +- A risk event or near-miss occurs +- A new technology is adopted (especially AI, cloud, OT) +- A key control fails or is found to be ineffective +- An external audit raises risk-related findings +- A material supplier or business partner incident occurs +- Insurance renewal or claims review identifies new exposures + +### Control Testing Programme + +| Control | Test Method | Frequency | Evidence | +|---------|------------|-----------|---------| +| Access controls | Privileged access review; user access review | Quarterly | Access log; review sign-off | +| Business continuity plan | Tabletop exercise; full DR test | Annually | Test report; lessons learned | +| Supplier risk controls | Supplier questionnaires; on-site audits | Annually / per contract cycle | Audit report; SLA performance data | +| Financial controls | Internal audit; reconciliation sign-off | Monthly / per financial cycle | Audit findings; reconciliation records | +| Compliance controls | Regulatory self-assessment; external audit | Annually | SAQ; external audit report | + +--- + +## Clause 6.7 — Recording and Reporting + +Documented records are required to support decision-making, demonstrate due diligence, +support learning, and fulfil accountability obligations. + +### Required Records + +| Record | Purpose | Minimum Retention | +|--------|---------|------------------| +| **Risk Register** | Inventory of all identified risks with current scores | Rolling; current version always maintained | +| **Risk Assessment Reports** | Evidence of risk identification, analysis, and evaluation | 5 years (or as required by sector regulation) | +| **Risk Treatment Plans** | Documented treatment decisions and progress | Duration of treatment + 3 years | +| **Risk Acceptance Decisions** | Evidence of informed acceptance of risks above appetite | 5 years | +| **Board Risk Reports** | Governance evidence; oversight record | 7 years (board records retention standard) | +| **Control Testing Records** | Evidence of control effectiveness | 3 years | +| **Incident / Near-Miss Log** | Event record; input to risk register updates | 5 years | +| **Framework Evaluation Records** | Evidence of continual improvement | 3 years | +| **Risk Appetite Statement** | Authoritative appetite positions | Current version; all superseded versions 5 years | + +### Risk Reporting Formats + +#### 1. Board Risk Report (Quarterly) +Contents: +- Executive summary: overall risk position vs. appetite +- Top 10 risks — heatmap and narrative +- New / emerging risks identified this quarter +- Risk treatment plan progress (% complete; overdue actions) +- Incidents / near-misses with risk register implications +- Risks closed / downgraded this quarter +- Proposed changes to risk appetite or criteria (if any) +- Outlook: anticipated risk changes next quarter + +#### 2. Risk Dashboard (Monthly — Executive) +A single-page summary: +- Heatmap: current top risks by residual score +- RAG status change indicators (↑ risk increased, ↓ decreased, → stable) +- Treatment plan actions: On track / At risk / Overdue +- New risks added since last dashboard +- Risk KPI scorecard (see KPIs in framework reference) + +#### 3. Risk Register Summary (Process Owner Level) +- Risks relevant to the process owner's area only +- Residual scores, treatment actions with their due dates +- Controls assigned to the process owner for monitoring + +### Risk Communication Best Practices + +1. **Tailor the message to the audience:** + - Board: strategic risk picture, appetite alignment, material exposures + - Executive: operational risk status, treatment progress, resource needs + - Process owners: their specific risks and control responsibilities + - Staff: risk awareness — not the full register + +2. **Use consistent risk language:** Ensure all stakeholders use the same likelihood and + consequence definitions. Provide a reference card. + +3. **Avoid risk register overload:** A board should see 10–15 top risks, not 150. + Filter to what is material and decision-relevant. + +4. **Show trend, not just status:** Use directional indicators to show whether the risk + profile is improving, stable, or deteriorating. + +5. **Connect risk to objectives:** Frame risk language in terms of strategic or operational + objectives, not just controls and scores. E.g., "The risk of market share loss through + competitor disruption remains HIGH — this directly threatens Objective 3: revenue growth." diff --git a/tests/__pycache__/test_plugin_structure.cpython-312-pytest-9.0.3.pyc b/tests/__pycache__/test_plugin_structure.cpython-312-pytest-9.0.3.pyc new file mode 100644 index 0000000..5f43407 Binary files /dev/null and b/tests/__pycache__/test_plugin_structure.cpython-312-pytest-9.0.3.pyc differ diff --git a/tests/__pycache__/test_plugin_structure.cpython-313-pytest-8.3.2.pyc b/tests/__pycache__/test_plugin_structure.cpython-313-pytest-8.3.2.pyc new file mode 100644 index 0000000..9790aaf Binary files /dev/null and b/tests/__pycache__/test_plugin_structure.cpython-313-pytest-8.3.2.pyc differ diff --git a/tests/__pycache__/test_skill_installability.cpython-312-pytest-9.0.3.pyc b/tests/__pycache__/test_skill_installability.cpython-312-pytest-9.0.3.pyc new file mode 100644 index 0000000..5a5fd39 Binary files /dev/null and b/tests/__pycache__/test_skill_installability.cpython-312-pytest-9.0.3.pyc differ diff --git a/tests/__pycache__/test_skill_installability.cpython-313-pytest-8.3.2.pyc b/tests/__pycache__/test_skill_installability.cpython-313-pytest-8.3.2.pyc new file mode 100644 index 0000000..b6e0ea9 Binary files /dev/null and b/tests/__pycache__/test_skill_installability.cpython-313-pytest-8.3.2.pyc differ diff --git a/tests/test_plugin_structure.py b/tests/test_plugin_structure.py index 5626230..349eb76 100644 --- a/tests/test_plugin_structure.py +++ b/tests/test_plugin_structure.py @@ -36,12 +36,18 @@ "fedramp", "gdpr-compliance", "hipaa-compliance", + "iso22301", "iso27001", + "iso27017", + "iso31000", "iso42001", "nist-csf", "pci-compliance", "soc2", "tsa-compliance", + "govramp", + "eu-ai-act", + "cmmc", } REQUIRED_PLUGIN_JSON_FIELDS = {"name", "version", "description"} @@ -186,7 +192,7 @@ def test_references_are_markdown(self, plugin_dir): # --------------------------------------------------------------------------- def test_all_expected_plugins_present(): - """All 9 expected plugin directories must exist under plugins/.""" + """All expected plugin directories must exist under plugins/.""" found = {p.name for p in PLUGIN_DIRS} missing = EXPECTED_PLUGINS - found assert not missing, ( diff --git a/tests/test_skill_installability.py b/tests/test_skill_installability.py index 1c4dbc7..01cb426 100644 --- a/tests/test_skill_installability.py +++ b/tests/test_skill_installability.py @@ -179,20 +179,26 @@ def test_references_under_skill_folder(self, skill_path): # --------------------------------------------------------------------------- EXPECTED_SKILLS = { + "eu-ai-act.skill", "fedramp.skill", "gdpr-compliance.skill", + "govramp.skill", "hipaa-compliance.skill", + "iso22301.skill", "iso27001.skill", + "iso27017.skill", + "iso31000.skill", "ISO-42001.skill", "NIST Cybersecurity.skill", "PCI-Compliance.skill", "soc2.skill", "TSA-Compliance.skill", + "cmmc.skill", } def test_all_expected_skills_present(): - """All 9 expected .skill files must exist in the repository.""" + """All expected .skill files must exist in the repository.""" found = {p.name for p in SKILL_FILES} missing = EXPECTED_SKILLS - found assert not missing, (