diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 921d1ff..a2a7237 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, HITRUST, NIST CSF, PCI DSS, TSA Cybersecurity, ISO 42001 AI Management System, ISO 13485 Medical Device QMS, GovRAMP, CMMC, ISO 31000, and EU AI Act.", "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,74 @@ "grc" ] }, + { + "name": "iso9001", + "source": "./plugins/iso9001", + "description": "ISO 9001:2015 Quality Management System (QMS) advisor \u2014 gap analysis, quality policy and procedure writing, clause-by-clause implementation guidance, process documentation, nonconformity and CAPA management, audit preparation, and certification readiness.", + "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": [ + "iso9001", + "quality-management", + "qms", + "compliance", + "gap-analysis", + "certification", + "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": "hitrust", + "source": "./plugins/hitrust", + "description": "HITRUST CSF compliance advisor covering all assessment types (e1, i1, r2) — gap analysis, control implementation guidance, MyCSF assessment support, CAP management, inheritance planning, and certification readiness for healthcare and regulated industries.", + "version": "0.3.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "hitrust", + "hitrust-csf", + "healthcare-security", + "hipaa", + "e1", + "i1", + "r2", + "mycsf", + "grc" + ] + }, { "name": "iso42001", "source": "./plugins/iso42001", @@ -200,6 +290,125 @@ "aisia", "grc" ] + }, + { + "name": "iso13485", + "source": "./plugins/iso13485", + "description": "ISO 13485:2016 medical device quality management system (QMS) advisor — gap analysis, design control guidance, DHF structure, regulatory mapping (EU MDR, FDA 21 CFR Part 820, MDSAP), CAPA, complaint handling, vigilance reporting, and certification readiness for medical device manufacturers and suppliers.", + "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": [ + "iso13485", + "medical-devices", + "qms", + "quality-management", + "mdr", + "fda-820", + "design-controls", + "mdsap", + "grc", + "compliance", + "regulatory" + ] + }, + { + "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/HITRUST - Claude Skill/HITRUST-README.md b/HITRUST - Claude Skill/HITRUST-README.md new file mode 100644 index 0000000..5fb5773 --- /dev/null +++ b/HITRUST - Claude Skill/HITRUST-README.md @@ -0,0 +1,168 @@ +# HITRUST CSF Compliance Skill for Claude + +A comprehensive Claude skill that provides expert HITRUST Common Security Framework (CSF) +compliance guidance for healthcare organisations, business associates, and technology vendors +operating in the US healthcare ecosystem. + +> **Disclaimer:** This skill provides informational guidance only and does not constitute +> legal, regulatory, or formal certification advice. HITRUST certification requires engagement +> with a HITRUST Authorized External Assessor and submission through the official MyCSF +> portal. For formal compliance determinations, consult a qualified HITRUST Authorized +> External Assessor and, where required, qualified legal counsel. + +--- + +## What Does This Skill Do? + +The HITRUST CSF Compliance Skill transforms Claude into a knowledgeable HITRUST advisor +capable of handling the full range of questions that arise when an organization is pursuing, +maintaining, or renewing HITRUST certification. + +At a high level, the skill does five things: + +1. **Guides assessment type selection** — It helps organizations determine whether e1, + i1, or r2 is the appropriate assessment based on their risk profile, organizational + size, customer requirements, and regulatory context. + +2. **Performs and supports gap analyses** — It produces structured gap assessments covering + all 14 HITRUST CSF control categories (v9.x) and 156 control specifications, with + status ratings, gap descriptions, CAP requirements, and prioritized remediation steps. + +3. **Supports Corrective Action Plan (CAP) management** — It helps teams develop, document, + and track CAPs for non-certifiable and near-certifiable findings, including root cause + analysis and evidence planning. + +4. **Generates HITRUST-aligned policies and procedures** — It produces ready-to-use policy + and procedure documents mapped to specific HITRUST control categories and specifications, + with all required document control elements. + +5. **Explains HITRUST concepts, processes, and cross-framework mappings** — It translates + HITRUST's prescriptive requirements into plain-language guidance, explains how HITRUST + maps to HIPAA, NIST SP 800-53, ISO 27001, PCI DSS, SOC 2, and other frameworks, and + advises on the inheritance program for cloud and third-party service providers. + +The skill is backed by four detailed reference files covering the control domains, assessment +guide (e1/i1/r2 processes and scoring), scoping factors, and framework overview — loaded +selectively based on the specific question or task. + +--- + +## Intended Audiences + +| Audience | How They Use the Skill | +|----------|----------------------| +| **Healthcare Compliance Officers** | Understand HITRUST requirements, drive internal preparation, manage the assessment process, and answer organisational questions about certification obligations | +| **Security Engineers and Architects** | Get specific technical control guidance, understand encryption and access control requirements, map existing controls to HITRUST specifications | +| **Healthcare IT Teams** | Understand what evidence is needed for each control, prepare system documentation for assessor review, configure systems to meet prescriptive HITRUST requirements | +| **Health IT Vendors and SaaS Companies** | Determine if HITRUST is required for their customer base, select the right assessment type, understand what a certification programme involves | +| **Privacy Officers** | Focus on HITRUST Category 13 (Privacy Practices) and understand how HITRUST CSF incorporates HIPAA Privacy Rule obligations | +| **Risk Officers** | Understand the HITRUST risk management control category, support HITRUST risk assessment requirements, map HITRUST to the organisation's enterprise risk framework | +| **Procurement and Legal Teams** | Understand what a HITRUST certification letter means, how to verify certification status, and how to include HITRUST requirements in contracts and BAAs | + +--- + +## Common Use Cases + +### Assessment Type Selection +- "We're a business associate with about 500,000 patient records. What HITRUST assessment should we pursue?" +- "Our hospital customer is asking for HITRUST r2. What does that mean for us?" +- "What is the difference between e1, i1, and r2?" +- "We have a SOC 2 Type 2. Is that equivalent to HITRUST?" + +### Gap Analysis +- "Perform a HITRUST r2 gap analysis against our current security programme" +- "Which HITRUST controls are we most likely to fail?" +- "We're a cloud-based EHR vendor. What HITRUST controls apply beyond the base set?" +- "Run a gap analysis against the HITRUST Category 01 Access Control domain" + +### CAP Development and Management +- "We have 15 non-certifiable findings. Help us build CAPs for each one" +- "What do we need to remediate before scoring above 75 on 09.l.1 (Backup)?" +- "Write a CAP for our finding on 02.e.1 (Security Awareness Training)" +- "We have an open CAP on audit logging — what evidence do we need to close it?" + +### Policy and Procedure Generation +- "Write a HITRUST-compliant Access Control Policy" +- "Generate an Information Security Policy that satisfies HITRUST category 04" +- "We need a vendor management policy that covers HITRUST 05.k controls" +- "Draft a Business Continuity Plan that meets HITRUST Category 12 requirements" +- "Write an incident response procedure that satisfies 11.c.1" + +### Assessment Process Support +- "What happens during an r2 assessment?" +- "How long does HITRUST certification take?" +- "How do we select an Authorized External Assessor?" +- "What is MyCSF and how do we use it for our assessment?" +- "What does the HITRUST QA review involve?" + +### Cross-Framework Mapping +- "We have SOC 2 Type 2. How much of HITRUST does that cover?" +- "Map our ISO 27001 controls to the equivalent HITRUST specifications" +- "How does HITRUST relate to HIPAA? Can we use HITRUST instead of a HIPAA risk analysis?" +- "Which HITRUST controls map to NIST SP 800-53 AC-2 (Account Management)?" + +### Inheritance and Scoping +- "We use AWS for our infrastructure. Which HITRUST controls can we inherit?" +- "How does HITRUST inheritance work?" +- "Build a shared responsibility matrix for our AWS-hosted application" +- "We use Epic as our EHR. Can we inherit any HITRUST controls from them?" +- "What scoping factors determine how many r2 controls we'll have?" + +--- + +## Skill Structure + +| File | Content | +|------|---------| +| `SKILL.md` | Main skill file — assessment type guidance, workflows, maturity model, core use cases | +| `references/hitrust-control-domains.md` | Full listing of all 14 HITRUST CSF control categories, 49 objectives, and 156 control specifications with descriptions | +| `references/hitrust-assessment-guide.md` | e1/i1/r2 comparison, assessment process phases, maturity scoring model, CAP lifecycle, MyCSF platform, interim assessment requirements | +| `references/hitrust-scoping-factors.md` | r2 scoping questionnaire, risk factor categories, data volume tiers, technology factors, regulatory factors, inheritance program, shared responsibility matrix | +| `references/hitrust-framework-overview.md` | HITRUST Alliance history, CSF version history, HITRUST vs. HIPAA, HITRUST vs. SOC 2 / ISO 27001 / NIST SP 800-53, cross-framework control mapping, key terminology | + +--- + +## How HITRUST Maps to Other Frameworks + +HITRUST CSF is designed to incorporate and harmonise requirements from more than 40 +authoritative frameworks and regulations. Key mappings include: + +| Standard | Relationship to HITRUST | +|----------|------------------------| +| HIPAA Security Rule | Fully incorporated — all Security Rule specifications map to HITRUST controls | +| HIPAA Privacy Rule | Incorporated in Category 13 (Privacy Practices) | +| NIST SP 800-53 | Each HITRUST control cites the corresponding NIST control(s) | +| ISO/IEC 27001 / 27002 | Each HITRUST control cites corresponding ISO controls | +| PCI DSS | If PCI scoping factors apply, PCI requirements are incorporated | +| SOC 2 / AICPA TSC | Significant overlap with Security criteria; HITRUST has published mapping | +| NIST Cybersecurity Framework | HITRUST has published official CSF-to-NIST CSF mapping | +| CMS Acceptable Risk Safeguards | Incorporated for organizations with CMS data | + +A robust HITRUST r2 certification substantially satisfies the security-related requirements +of HIPAA and provides meaningful evidence toward SOC 2, ISO 27001, and NIST compliance, but +does not replace framework-specific legal obligations or documentation requirements (e.g., +a formal HIPAA risk analysis under 45 CFR 164.308(a)(1)). + +--- + +## HITRUST Assessment Types at a Glance + +| Feature | e1 | i1 | r2 | +|---------|-----|-----|-----| +| Controls | 44 fixed | 219 Defined Baseline | Variable (risk-tailored) | +| Certification period | 1 year | 1 year | 2 years | +| Maturity levels assessed | 3 | 3 | 5 | +| Minimum certifiable score | 62/100 | 62/100 | 62/100 | +| Assurance level | Entry / Basic | Moderate | Highest | +| Interim required | No | No | Yes (at 12 months) | +| Typical use | Foundational attestation; new to HITRUST | Established programme; moderate assurance | Major healthcare enterprises; customer-mandated | + +--- + +## Installation + +Install this skill in Claude Code by importing the `hitrust.skill` file through the +Claude Code plugin manager, or by placing the plugin directory in your Claude configuration. + +For full installation instructions, see the repository +[INSTALLATION.md](../INSTALLATION.md). diff --git a/HITRUST - Claude Skill/hitrust.skill b/HITRUST - Claude Skill/hitrust.skill new file mode 100644 index 0000000..f4420d5 Binary files /dev/null and b/HITRUST - Claude Skill/hitrust.skill differ diff --git a/INSTALLATION.md b/INSTALLATION.md index 8df4971..daecb65 100644 --- a/INSTALLATION.md +++ b/INSTALLATION.md @@ -76,16 +76,20 @@ Once the marketplace is registered, install only the frameworks you need. /plugin install iso42001@grc-skills ``` +```shell +/plugin install iso9001@grc-skills +``` + Each plugin is installed to a local cache (`~/.claude/plugins/cache`) and activates immediately in new Claude Code sessions. --- -## 3. Install All Nine at Once +## 3. Install All Ten at Once To install the full GRC suite in a single command: ```shell -/plugin install iso27001@grc-skills soc2@grc-skills fedramp@grc-skills gdpr-compliance@grc-skills hipaa-compliance@grc-skills nist-csf@grc-skills pci-compliance@grc-skills tsa-compliance@grc-skills iso42001@grc-skills +/plugin install iso27001@grc-skills soc2@grc-skills fedramp@grc-skills gdpr-compliance@grc-skills hipaa-compliance@grc-skills nist-csf@grc-skills pci-compliance@grc-skills tsa-compliance@grc-skills iso42001@grc-skills iso9001@grc-skills ``` --- diff --git a/ISO 13485 - Claude Skill/ISO-13485-README.md b/ISO 13485 - Claude Skill/ISO-13485-README.md new file mode 100644 index 0000000..27c3386 --- /dev/null +++ b/ISO 13485 - Claude Skill/ISO-13485-README.md @@ -0,0 +1,150 @@ +# ISO 13485:2016 Medical Device QMS Skill + +> A Claude skill for quality, regulatory, and compliance teams to navigate ISO 13485:2016 — from gap analysis and design controls to regulatory submissions, post-market surveillance, and certification readiness. + +--- + +## 1. What Does the Skill Do? + +The ISO 13485 skill turns Claude into an expert ISO 13485:2016 Lead Auditor and medical device Quality Management System (QMS) implementation consultant. It provides structured, audit-ready guidance across the full lifecycle of a medical device QMS — from initial gap assessment through to certification readiness and ongoing post-market compliance. + +The skill covers the complete ISO 13485:2016 standard (Clauses 4–8) with all sub-clause requirements, mandatory documented procedures, and mandatory records. It understands the specific requirements for medical device manufacturers, contract manufacturers, suppliers, importers, and distributors. + +Key capabilities: +- Full clause-by-clause guidance for ISO 13485:2016 +- Design and development controls (Clause 7.3) including DHF structure +- Risk management integration (ISO 14971:2019) +- Regulatory mapping: EU MDR 2017/745, EU IVDR 2017/746, FDA 21 CFR Part 820 (QMSR), MDSAP, Health Canada, TGA, MHLW +- CAPA and nonconformance management +- Complaint handling and vigilance/MDR reporting +- Certification pathway guidance (Stage 1 / Stage 2 / surveillance) +- Mandatory document templates (quality manual, CAPA form, NCR form, complaint record, management review, internal audit report, supplier evaluation, design change request, process validation protocol, risk management plan) + +--- + +## 2. Intended Audiences + +This skill is designed for quality and regulatory professionals in the medical device industry: + +- **Quality Managers and QA Engineers** responsible for establishing, maintaining, and improving the QMS +- **Regulatory Affairs Managers and Specialists** preparing technical documentation and regulatory submissions +- **Design and Development Engineers** navigating design control requirements +- **Management Representatives / PRRCs** (Persons Responsible for Regulatory Compliance) +- **Internal Auditors** conducting ISO 13485 audits +- **Consultants** supporting manufacturers through first-time certification, MDSAP readiness, or EU MDR transition +- **Notified Body / MDSAP audit teams** using this as a reference tool +- **Suppliers to the medical device industry** seeking to understand applicable QMS requirements + +--- + +## 3. Common Use Cases + +| Use Case | Example Prompt | +|----------|---------------| +| **Gap analysis** | "Perform a gap analysis of our QMS against ISO 13485:2016 Clause 8 — we are a Class II device manufacturer." | +| **Design controls** | "Walk me through the design and development process requirements under ISO 13485:2016 Clause 7.3 for a new surgical instrument." | +| **DHF structure** | "What should be included in a Design History File for a Class IIb active implantable device?" | +| **CAPA** | "Help me write a CAPA for repeated failures in our incoming inspection process." | +| **Complaint procedure** | "Draft a complaint handling procedure that meets ISO 13485 Clause 8.2.2 and EU MDR vigilance requirements." | +| **Regulatory mapping** | "How does ISO 13485 Clause 7.3 map to FDA 21 CFR 820.30 design controls?" | +| **Certification readiness** | "What documents do I need ready before a Stage 1 ISO 13485:2016 certification audit?" | +| **Process validation** | "Help me write a process validation protocol for our heat-sealing process for sterile pouches." | +| **Risk management** | "Help me set up a risk management file for a Class III implantable device aligned to ISO 14971:2019." | +| **MDSAP readiness** | "What are the MDSAP-specific requirements beyond ISO 13485 that I need to address for FDA and Health Canada?" | +| **NC product handling** | "What are my options for disposing of nonconforming product detected before delivery?" | +| **Vigilance reporting** | "What are the EU MDR vigilance reporting timeframes and what triggers a serious incident report?" | + +--- + +## 4. How to Use the Skill + +Once the skill is installed in Claude, it activates automatically whenever you ask about ISO 13485, medical device QMS, design controls, medical device compliance, CAPA, vigilance reporting, or related topics. You do not need to reference the skill by name. + +### Tips for Best Results + +**Specify your organisation type** — the requirements differ for manufacturers (all clauses), contract manufacturers (may exclude Clause 7.3), suppliers (subset applies), and distributors/importers. State which role applies to your organisation. + +**Identify the regulatory markets** — the skill includes regulatory mappings for EU (MDR/IVDR), FDA (QMSR), Canada (MDSAP), Australia (TGA), and Japan (MHLW). Tell the skill which markets are relevant so it can tailor advice. + +**Reference specific clauses or activities** — for implementation guidance, referencing specific clauses (e.g., "Clause 7.5.6 process validation") or activities (e.g., "design reviews at phase gates") produces more targeted responses. + +**Provide device context** — ISO 13485 requirements scaled by device risk. Stating your device classification (EU: Class I/IIa/IIb/III; FDA: Class I/II/III) helps the skill calibrate the depth of guidance. + +**Ask for document templates** — the skill can generate complete, structured template documents. Provide your organisation name and relevant context for personalised outputs. + +--- + +## 5. Key Features + +### Complete Clause Coverage +All ISO 13485:2016 clauses and sub-clauses (4.1–8.5.3) with: +- Mandatory documented procedure requirements (17 documented procedures required) +- Mandatory record requirements (40+ records explicitly required) +- Common audit findings and pitfalls per clause + +### Design Control Deep Dive +Phase-by-phase design and development guidance including: +- DHF structure and index template +- Design input and output requirements with traceability +- Verification vs. validation distinction with test protocol templates +- Design transfer requirements and first article inspection +- Design change control with substantial modification assessment criteria +- Risk management integration throughout (ISO 14971) + +### Regulatory Intelligence +Detailed cross-reference tables mapping ISO 13485 clauses to: +- EU MDR 2017/745 and IVDR 2017/746 (including Annex I GSPR, Annex II Technical Documentation, Annex IX/XI conformity assessment) +- FDA 21 CFR Part 820 QMSR (aligned 2024) including DHF, DMR, DHR requirements +- MDSAP 7-process audit approach +- Health Canada SOR/98-282 +- TGA and MHLW requirements + +### Document Templates +Ten out-of-the-box templates covering the most critical QMS documents, ready to customise for your organisation. + +--- + +## 6. ISO 13485:2016 at a Glance + +| Clause | Title | Focus Area | +|--------|-------|-----------| +| 4 | Quality Management System | QMS establishment, documentation, medical device file | +| 5 | Management Responsibility | Policy, objectives, management review, MR | +| 6 | Resource Management | Competence, training, infrastructure, work environment | +| 7 | Product Realization | Customer requirements, design controls, purchasing, production, traceability, calibration | +| 8 | Measurement, Analysis and Improvement | Feedback, complaints, vigilance, audits, NC product, CAPA | + +**Mandatory documented procedures:** 17 (control of documents, control of records, design and development, design change control, purchasing, production controls, process validation, identification, traceability, feedback, complaint handling, regulatory authority reporting, internal audit, NC product control, rework, corrective action, preventive action) + +**Mandatory records:** 40+ explicit records required across all clauses + +--- + +## 7. Supported Standards and Regulations + +ISO 13485:2016 is the central standard. The skill also covers: + +| Standard / Regulation | Jurisdiction | Role | +|----------------------|-------------|-----| +| EU MDR 2017/745 | European Union | Medical device market access; CE marking | +| EU IVDR 2017/746 | European Union | In vitro diagnostic market access | +| FDA 21 CFR Part 820 (QMSR 2024) | United States | Manufacturing quality requirements | +| 21 CFR Part 803 | United States | Medical Device Reporting (MDR) — adverse event reporting | +| MDSAP | AU, BR, CA, JP, US | Single audit programme | +| Health Canada SOR/98-282 | Canada | Device licence and QMS requirements | +| TGA Regulations | Australia | ARTG listing and QMS requirements | +| PMD Act / MHLW Ordinance | Japan | Japanese market access | +| ISO 14971:2019 | International | Risk management — required by 13485 Clause 7.1 | +| IEC 62304:2006+AMD1 | International | Software lifecycle | +| IEC 62366-1:2015+AMD1 | International | Usability engineering | +| ISO 10993 series | International | Biological evaluation | +| ISO 11607 series | International | Sterile packaging | + +--- + +## 8. Installation + +Install this skill directly in Claude using the `.skill` file in this folder, or via the Claude Skills Marketplace at: +[https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/](https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/) + +See [INSTALLATION.md](../../INSTALLATION.md) for step-by-step installation instructions. diff --git a/ISO 13485 - Claude Skill/iso13485.skill b/ISO 13485 - Claude Skill/iso13485.skill new file mode 100644 index 0000000..b325a61 Binary files /dev/null and b/ISO 13485 - Claude Skill/iso13485.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/ISO 9001 - Claude Skill/ISO-9001-README.md b/ISO 9001 - Claude Skill/ISO-9001-README.md new file mode 100644 index 0000000..9fa4738 --- /dev/null +++ b/ISO 9001 - Claude Skill/ISO-9001-README.md @@ -0,0 +1,142 @@ +# ISO 9001 Quality Management System — Claude Skill + +> A Claude skill for quality, operations, and compliance teams to implement, audit, and certify a Quality Management System (QMS) under ISO 9001:2015. + +--- + +## 1. What Does the Skill Do? + +The ISO 9001 skill turns Claude into an expert ISO 9001 Lead Auditor and QMS implementation consultant. It provides structured, audit-ready guidance across the full lifecycle of a Quality Management System — from initial gap assessment through certification readiness and beyond. + +The skill covers **ISO 9001:2015** in full — all mandatory clauses (4–10), the seven quality management principles, risk-based thinking, process approach, and all required documented information. It understands common valid exclusions (e.g. Clause 8.3 Design and Development), the differences between 2008 and 2015, and sector-specific extensions including IATF 16949 (automotive), AS9100D (aerospace), ISO 13485 (medical devices), and ISO/IEC 90003 (software). + +Outputs are tailored to the task: structured gap analysis tables with 🔴/🟡/🟢 status, complete policy and procedure documents with document control blocks, clause-by-clause audit checklists, CAPA reports with root cause analysis, management review agendas, and certification readiness checklists. + +--- + +## 2. Intended Audiences + +This skill is designed for **quality, operations, and compliance teams** working on ISO 9001 certification, maintenance, and continual improvement. It is most useful for: + +- **Quality Managers** and **Quality Engineers** overseeing QMS implementation, maintenance, and internal auditing +- **Operations Managers** seeking to document and control production or service delivery processes +- **Compliance teams** preparing for Stage 1 or Stage 2 third-party certification audits +- **Managing Directors / CEOs** of SMEs seeking first-time ISO 9001 certification +- **Internal auditors** planning and conducting audits and writing findings reports +- **Consultants** supporting clients through first-time QMS implementation or recertification +- **Sector-specific teams** in automotive (IATF 16949), aerospace (AS9100D), medical device (ISO 13485), or software (ISO/IEC 90003) organisations using 9001 as the base + +--- + +## 3. Common Use Cases + +| Use Case | Example Prompt | +|----------|---------------| +| **Gap analysis** | "Run a gap analysis of our QMS against ISO 9001:2015. We're a 50-person contract electronics manufacturer." | +| **Policy generation** | "Write me a complete Quality Policy for a professional services firm." | +| **Procedure generation** | "Generate a Documented Information Control Procedure mapped to ISO 9001:2015 Clause 7.5." | +| **Document templates** | "Give me a template for a Nonconformity and Corrective Action Report (CAPA)." | +| **Risk register** | "Help me build a QMS risk and opportunities register for Clause 6.1 for our logistics company." | +| **Internal audit checklist** | "Create an internal audit checklist for Clause 8.4 (supplier controls) at a manufacturing site." | +| **Audit preparation** | "What documentation will an auditor expect to see during a Stage 2 audit of our production processes?" | +| **CAPA support** | "Help me write a corrective action for an NC finding about calibration records." | +| **Management review** | "Generate a management review agenda and minutes template with all required ISO 9001:2015 inputs." | +| **Certification readiness** | "What mandatory documents do we need before our Stage 1 audit?" | +| **Sector extension** | "We're IATF 16949 certified. How do our PPAP and APQP requirements relate to ISO 9001:2015 Clause 8.3?" | +| **Nonconformity records** | "What does ISO 9001:2015 require us to retain as documented information for Clause 8.7 — nonconforming outputs?" | + +--- + +## 4. How to Use the Skill + +Once installed in Claude Code, the skill activates automatically whenever you ask about ISO 9001, QMS, quality management, internal audits, nonconformity management, or related topics. You do not need to reference the skill by name. + +### Tips for best results + +**Give context about your organisation** — the skill tailors outputs based on your sector, products or services, size, and whether you are going for initial certification, maintaining an existing QMS, or transitioning from ISO 9001:2008. + +> "We're a 200-person precision machining company supplying to the aerospace sector. Help us prepare for our first ISO 9001:2015 Stage 1 audit." + +**Name the specific clause or document** — for targeted outputs, reference the clause number (e.g. `Clause 8.4`) or document type (e.g. `Supplier Evaluation Form`) you need. + +**Work one task at a time** — asking for a full QMS implementation plan in one prompt will produce broad output. It's more effective to work through tasks in sequence (gap analysis → priority procedures → audit checklists → CAPA → certification readiness). + +**For sector schemes** — state your applicable sector scheme (IATF 16949, AS9100D, ISO 13485) and the skill will integrate sector-specific requirements into its outputs. + +### Example interaction + +``` +You: Write me a Nonconformity and Corrective Action Procedure for our ISO 9001:2015 QMS. + +Claude: [Generates a full procedure including: + - Document control block (ID, version, owner, approval, review date) + - Purpose and scope + - Definitions (NC, CAPA, major/minor) + - Roles and responsibilities + - Procedure steps: identification → containment → root cause → corrective action → verification → closure + - Mapping to Clause 8.7 and 10.2 + - Records required + - Related documents + - Revision history table] +``` + +--- + +## 5. Skill Implementation Details + +### Architecture + +``` +iso9001/ +├── SKILL.md # Core skill logic and workflows +└── references/ + ├── iso9001-clauses-requirements.md # Detailed clause-by-clause requirements (4–10) + ├── iso9001-quality-controls.md # Process control framework and control tables + └── iso9001-document-templates.md # Ready-to-use document templates (10 templates) +``` + +`SKILL.md` is loaded into Claude's context whenever the skill triggers. Reference files are loaded on demand — only when needed for the specific task — keeping the context window efficient. + +### What's in SKILL.md + +- **Persona**: Claude adopts the role of an ISO 9001 Lead Auditor and QMS implementation consultant +- **Output format matrix**: Maps each task type to a specific output format (gap table, document, checklist, CAPA, narrative) +- **Standard overview**: Seven quality management principles; risk-based thinking vs. preventive action; Annex SL +- **Clause structure summary**: All mandatory clauses (4–10) with key deliverables per clause +- **6 core workflows**: Gap Analysis, Policy & Procedure Generation, CAPA, Internal Audit Support, Process Documentation, Certification Readiness +- **Integration table**: ISO 9001 alignment with ISO 14001, ISO 45001, ISO 27001, ISO 42001, IATF 16949, AS9100D, ISO 13485 +- **Sector scheme awareness**: Context-specific guidance for automotive, aerospace, medical devices, software, construction, food +- **Mandatory documentation checklist**: All documented information required by ISO 9001:2015 +- **Key terminology glossary**: 14 key terms defined + +### What's in the reference files + +| File | Contents | +|------|----------| +| `iso9001-clauses-requirements.md` | Detailed requirements, audit evidence, and common gaps for every sub-clause from 4.1 to 10.3 | +| `iso9001-quality-controls.md` | Process control tables for customer controls, supplier controls, production controls, inspection/calibration, CAPA, document control, internal audit, management review, and continual improvement | +| `iso9001-document-templates.md` | 10 ready-to-use templates: Quality Policy, QMS Scope, Quality Objectives Register, Risk and Opportunities Register, Internal Audit Report, CAPA Report, Management Review Minutes, Supplier Evaluation Form, Competency Matrix, Customer Satisfaction Survey | + +### Install this skill + +```shell +/plugin install iso9001@grc-skills +``` + +--- + +## 6. ISO 9001:2015 at a Glance + +| Feature | Detail | +|---------|--------| +| Standard | ISO 9001:2015 | +| Publisher | ISO (International Organization for Standardization) | +| First published | 1987; current version September 2015 | +| Replaced | ISO 9001:2008 (transition deadline: September 2018) | +| Structure | Annex SL High Level Structure — Clauses 4–10 | +| Controls | No Annex A controls — requirements embedded in Clauses 4–10 | +| Certifications worldwide | >1 million (most widely adopted management system standard) | +| Applicable sectors | All — manufacturing, services, construction, software, healthcare, government, education | +| Related sector schemes | IATF 16949 (automotive), AS9100D (aerospace), ISO 13485 (medical devices) | +| Certification body | Any UKAS/IAF-accredited certification body (TÜV, Bureau Veritas, SGS, BSI, Intertek, etc.) | +| Audit cycle | Stage 1 (doc review) → Stage 2 (implementation) → Annual surveillance → Recertification every 3 years | diff --git a/ISO 9001 - Claude Skill/ISO-9001.skill b/ISO 9001 - Claude Skill/ISO-9001.skill new file mode 100644 index 0000000..28a066a Binary files /dev/null and b/ISO 9001 - Claude Skill/ISO-9001.skill differ diff --git a/README.md b/README.md index d4bd058..43d246b 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,11 @@ # Claude Skills for Governance, Risk & Compliance (GRC) -Expert-level compliance guidance for ISO 27001, SOC 2, FedRAMP, GDPR, HIPAA, NIST CSF, PCI DSS, TSA Cybersecurity, and ISO 42001 AI Management System — powered by Claude Skills. +Expert-level compliance guidance for ISO 27001, SOC 2, FedRAMP, GDPR, HIPAA, NIST CSF, PCI DSS, TSA Cybersecurity, ISO 42001 AI Management System, and ISO 9001 Quality Management System — powered by Claude Skills. Benchmarked across 18 test cases (2 per framework) using the eval framework — each graded against 4–5 verifiable assertions by independent agents. Skills scored **94% ± 10%** vs a baseline of 72% ± 28%. [![Release: v0.3.0](https://img.shields.io/badge/Release-v0.3.0-brightgreen.svg)](../../releases/tag/v0.3.0) [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE) -[![Skills: 9](https://img.shields.io/badge/Skills-9-green.svg)](#the-skills) +[![Skills: 10](https://img.shields.io/badge/Skills-10-green.svg)](#the-skills) [![Built with Claude](https://img.shields.io/badge/Built%20with-Claude-orange.svg)](https://claude.ai) --- @@ -24,6 +24,7 @@ Benchmarked across 18 test cases (2 per framework) using the eval framework — - [PCI DSS](#-pci-dss) - [TSA Cybersecurity](#-tsa-cybersecurity) - [ISO 42001 AI Management System](#-iso-42001-ai-management-system) + - [ISO 9001 Quality Management System](#-iso-9001-quality-management-system) - [Potential Use Cases](#potential-use-cases) - [How to Install a Skill](#how-to-install-a-skill) - [Install via Claude Code Marketplace](#install-via-claude-code-marketplace) @@ -241,6 +242,26 @@ The ISO 42001 skill turns Claude into an expert **ISO/IEC 42001:2023** AI Manage --- +### 🏭 ISO 9001 Quality Management System + +**File:** `ISO 9001 - Claude Skill/ISO-9001.skill` + +The ISO 9001 skill turns Claude into an expert ISO 9001 Lead Auditor and QMS implementation consultant. It covers **ISO 9001:2015** in full — all mandatory clauses (4–10), the seven quality management principles, risk-based thinking, process approach, and all required documented information. It is aware of common valid exclusions (e.g. Clause 8.3 Design and Development) and sector-specific extensions including IATF 16949 (automotive), AS9100D (aerospace), ISO 13485 (medical devices), and ISO/IEC 90003 (software). + +**What it does:** +- Runs structured **gap analyses** against all mandatory clauses (4–10) with 🔴/🟡/🟢 status and prioritised remediation roadmaps +- Generates complete, audit-ready **QMS policies and procedures** — Quality Policy, Documented Information Control, CAPA, Internal Audit, Management Review, Supplier Control — with document control blocks and clause citations +- Provides detailed **process documentation** using SIPOC tables and the process approach framework (inputs, outputs, controls, resources, KPIs, risks) +- Builds **risk and opportunities registers** (Clause 6.1) at the process level, replacing the old preventive action requirement +- Produces ready-to-use **document templates**: Quality Objectives Register, Internal Audit Report, CAPA Report, Management Review Minutes, Supplier Evaluation Form, Competency Matrix, Customer Satisfaction Survey +- Supports **nonconformity and corrective action (CAPA)** with structured root cause analysis (5-Why, Fishbone) and effectiveness verification +- Guides **Stage 1 and Stage 2 certification readiness** with mandatory document checklists and auditor evidence expectations +- Advises on **sector scheme extensions** — IATF 16949, AS9100D, ISO 13485, ISO/IEC 90003 + +**Trigger phrases:** `ISO 9001`, `QMS`, `quality management`, `quality policy`, `quality objectives`, `gap analysis ISO 9001`, `internal audit`, `corrective action`, `CAPA`, `nonconformity`, `management review`, `supplier qualification`, `calibration`, `design and development`, `process approach`, `risk-based thinking`, `certification readiness`, `IATF 16949`, `AS9100D` + +--- + ## Potential Use Cases | Scenario | Relevant Skill(s) | @@ -290,6 +311,14 @@ The ISO 42001 skill turns Claude into an expert **ISO/IEC 42001:2023** AI Manage | Mapping ISO 42001 AISIA requirements to EU AI Act Fundamental Rights Impact Assessment (FRIA) | ISO 42001 | | Integrating an ISO 42001 AIMS with an existing ISO 27001 ISMS | ISO 42001 + ISO 27001 | | Governing staff use of public AI tools (ChatGPT, Copilot) under Annex A control A.9.7 | ISO 42001 | +| Running a gap analysis against ISO 9001:2015 for a manufacturing or services organisation | ISO 9001 | +| Writing a Quality Policy, CAPA procedure, or Documented Information Control procedure | ISO 9001 | +| Preparing Stage 1 and Stage 2 audit evidence for ISO 9001:2015 certification | ISO 9001 | +| Building a process-level risk and opportunities register under Clause 6.1 | ISO 9001 | +| Drafting a corrective action report with full root cause analysis (5-Why / Fishbone) | ISO 9001 | +| Preparing a Management Review agenda and minutes with all required ISO 9001:2015 inputs | ISO 9001 | +| Setting up supplier qualification and evaluation under Clause 8.4 | ISO 9001 | +| Implementing ISO 9001 alongside ISO 27001 or ISO 42001 as an integrated management system | ISO 9001 + ISO 27001 / ISO 42001 | --- @@ -308,6 +337,7 @@ The ISO 42001 skill turns Claude into an expert **ISO/IEC 42001:2023** AI Manage | 💳 PCI DSS | [PCI-Compliance.skill](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/raw/main/PCI%20Compliance%20-%20Claude%20Skill/PCI-Compliance.skill) | | 🚨 TSA Cybersecurity | [TSA-Compliance.skill](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/raw/main/TSA%20Compliance%20-%20Claude%20Skill/TSA-Compliance.skill) | | 🤖 ISO 42001 AI Management System | [ISO-42001.skill](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/raw/main/ISO%2042001%20-%20Claude%20Skill/ISO-42001.skill) | + | 🏭 ISO 9001 Quality Management System | [ISO-9001.skill](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/raw/main/ISO%209001%20-%20Claude%20Skill/ISO-9001.skill) | 2. Open Claude and navigate to **Customize → Skills**. 3. Click **Upload Skill** and select the `.skill` file. @@ -327,7 +357,7 @@ Add the marketplace and install the skills you need directly from the terminal: ```shell /plugin marketplace add Sushegaad/Claude-Skills-Governance-Risk-and-Compliance -/plugin install iso27001@grc-skills soc2@grc-skills fedramp@grc-skills gdpr-compliance@grc-skills hipaa-compliance@grc-skills nist-csf@grc-skills pci-compliance@grc-skills tsa-compliance@grc-skills iso42001@grc-skills +/plugin install iso27001@grc-skills soc2@grc-skills fedramp@grc-skills gdpr-compliance@grc-skills hipaa-compliance@grc-skills nist-csf@grc-skills pci-compliance@grc-skills tsa-compliance@grc-skills iso42001@grc-skills iso9001@grc-skills ``` Teams can pre-wire the marketplace in `.claude/settings.json` so every developer gets the skills automatically when they open the project — no manual install required. 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/hitrust/.claude-plugin/plugin.json b/plugins/hitrust/.claude-plugin/plugin.json new file mode 100644 index 0000000..a82d171 --- /dev/null +++ b/plugins/hitrust/.claude-plugin/plugin.json @@ -0,0 +1,23 @@ +{ + "name": "hitrust", + "description": "HITRUST CSF compliance advisor covering all assessment types (e1, i1, r2) \u2014 gap analysis, control implementation guidance, MyCSF assessment support, corrective action planning, and certification readiness for healthcare and other regulated industries.", + "version": "0.3.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": [ + "hitrust", + "hitrust-csf", + "healthcare-security", + "hipaa", + "e1", + "i1", + "r2", + "mycsf", + "grc" + ] +} diff --git a/plugins/hitrust/skills/hitrust/SKILL.md b/plugins/hitrust/skills/hitrust/SKILL.md new file mode 100644 index 0000000..cf10096 --- /dev/null +++ b/plugins/hitrust/skills/hitrust/SKILL.md @@ -0,0 +1,325 @@ +--- +name: hitrust +description: > + Expert HITRUST CSF (Common Security Framework) compliance advisor. Use this skill whenever + a user asks about HITRUST, HITRUST CSF, HITRUST certification, MyCSF, e1 assessment, + i1 assessment, r2 assessment, HITRUST Authorized External Assessor, HITRUST control + categories, corrective action plans (CAPs), HITRUST gap analysis, HITRUST scoping, + HITRUST inheritance, HITRUST and HIPAA alignment, shared responsibility matrices for + HITRUST, HITRUST Assurance Program, or any question about achieving, maintaining, or + preparing for HITRUST certification. Also trigger for requests involving healthcare security + frameworks that harmonise HIPAA, NIST SP 800-53, PCI DSS, ISO 27001, and other standards. + Trigger even if the user says "we need HITRUST" or "our customer requires HITRUST + certification" without specifying an assessment type. +--- + +# HITRUST CSF Compliance Skill + +You are an expert HITRUST implementation consultant and assessment advisor with deep knowledge +of the HITRUST Common Security Framework (CSF), the HITRUST Assurance Program, and the MyCSF +assessment platform. You assist compliance teams, security officers, and organizations seeking +or maintaining HITRUST certification. + +> **Disclaimer:** This guidance is for informational purposes only and does not constitute +> legal, regulatory, or formal certification advice. HITRUST certification requires engagement +> with a HITRUST Authorized External Assessor and submission through the official MyCSF portal. + +--- + +## How to Respond + +Clarify the assessment type (e1, i1, or r2) and the organization's industry context if not +stated. Default to **r2** guidance for complex requests or when the user does not specify, +as r2 is the most comprehensive assessment type and the most common target for certification. + +Match output to the task: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Domain | Control ID | Requirement | Status | Gap | CAP Needed | Priority | +| Assessment type selection | Decision matrix with rationale and effort comparison | +| Control implementation guidance | Structured: Control ID > Objective > What to Implement > Evidence > Assessor Tips | +| Corrective Action Plan (CAP) | Table: Finding ID | Control | Gap | Remediation Action | Owner | Target Date | Status | +| Policy generation | Full structured policy with HITRUST control citations | +| Scoping exercise | Narrative with suggested domains, risk factor count, and included/excluded systems | +| Inheritance guidance | Shared Responsibility Matrix format | +| General question | Clear, concise prose with control category and specification citations | + +--- + +## HITRUST CSF — Framework Overview + +HITRUST (Health Information Trust Alliance) was founded in 2007. The HITRUST Common Security +Framework (CSF) was first published in 2009 as a certifiable, risk-based framework that +harmonises and consolidates requirements from multiple regulations and standards into a single, +prescriptive control set. + +### Frameworks Harmonised by HITRUST CSF + +HITRUST CSF incorporates and maps to more than 40 authoritative sources, including: + +| Source | Relationship | +|--------|-------------| +| HIPAA / HITECH | Core healthcare regulatory driver | +| NIST SP 800-53 Rev 5 | Federal security controls baseline | +| ISO/IEC 27001 / 27002 | International ISMS standard | +| PCI DSS | Payment card data security | +| SOC 2 (AICPA TSC) | Service organisation controls | +| CMS ARS | CMS Acceptable Risk Safeguards | +| NIST Cybersecurity Framework (CSF) | Cybersecurity risk management | +| COBIT | IT governance and management | +| GDPR | European data protection | +| CMMC | US defence supply chain | +| 21st Century Cures Act | Health interoperability | + +--- + +## HITRUST CSF Control Structure + +### Version 9.x (v9.6.2 — Widely Deployed Baseline) + +HITRUST CSF v9.x organises requirements into: +- **14 Control Categories** (numbered 00–13) +- **49 Control Objectives** (lettered sub-divisions within categories) +- **156 Control Specifications** (specific prescriptive requirements) + +### Version 11 (v11 — Current, Released January 2023) + +HITRUST CSF v11 reorganised and updated the framework: +- Continued support for e1, i1, and r2 assessment types +- Introduced Defined Baseline (dB) controls for i1 +- Enhanced alignment with CMMC 2.0, NIST SP 800-171, and NIST CSF 2.0 +- Improved cross-framework mapping and prescriptive implementation guidance + +### The 14 Control Categories (v9.x) + +| Category | Name | Representative Objectives | +|----------|------|--------------------------| +| 00 | Information Security Management Program | Program establishment, governance | +| 01 | Access Control | Logical access, privilege management, remote access, network controls | +| 02 | Human Resources Security | Screening, training, termination, NDAs | +| 03 | Risk Management | Risk assessment, risk treatment, program development | +| 04 | Security Policy | Policy documentation, review cycle | +| 05 | Organization of Information Security | Roles, responsibilities, third-party agreements | +| 06 | Compliance | Legal/regulatory identification, audit controls, cryptography controls | +| 07 | Asset Management | Inventory, classification, media handling | +| 08 | Physical and Environmental Security | Physical perimeter, equipment protection | +| 09 | Communications and Operations Management | Operating procedures, change management, backup, monitoring, logging | +| 10 | Information Systems Acquisition, Development & Maintenance | Secure SDLC, input validation, cryptography, vulnerability management | +| 11 | Information Security Incident Management | Incident reporting, response procedures, evidence collection | +| 12 | Business Continuity Management | BCP/DR, risk assessment, plan testing | +| 13 | Privacy Practices | Privacy notice, PHI safeguards, patient access, minimum necessary | + +Consult `references/hitrust-control-domains.md` for the full listing of objectives and +specifications within each category. + +--- + +## Assessment Types + +### e1 — Entry-Level Assessment (1-Year Certification) + +- **Scope**: 44 essential control requirements — a curated baseline for fundamental cyber hygiene +- **Purpose**: Provides a basic, entry-level assurance level; suitable for lower-risk entities + or those beginning their HITRUST journey +- **Assessment method**: Validated by a HITRUST Authorized External Assessor (CPA firm) +- **Certification period**: 1 year +- **Controls**: Fixed set — not customised by risk factors; same 44 requirements for all entities +- **Appropriate for**: Organizations new to HITRUST, smaller healthcare entities, or those + needing a baseline attestation at lower cost + +### i1 — Implemented 1-Year Assessment (1-Year Certification) + +- **Scope**: 219 control requirements (v11) covering implemented security practices +- **Purpose**: Moderate assurance; demonstrates that security controls are designed and + implemented; broader than e1 +- **Assessment method**: HITRUST Authorized External Assessor validation required +- **Certification period**: 1 year +- **Controls**: Fixed Defined Baseline (dB) set in v11; not risk-tailored +- **Appropriate for**: Organizations that have mature security programmes and need a + mid-tier assurance level for business partners or regulators + +### r2 — Risk-Based 2-Year Assessment (2-Year Certification) + +- **Scope**: Variable — driven by risk factors (see Scoping section below); typically + 150 to 500+ control requirements +- **Purpose**: Highest assurance level; demonstrates that controls are designed, + implemented, measured, and managed +- **Assessment method**: HITRUST Authorized External Assessor validation + HITRUST QA review +- **Certification period**: 2 years (with interim assessment at 12 months) +- **Controls**: Risk-tailored based on HITRUST scoping factors +- **Appropriate for**: Large healthcare organisations, health plans, major business associates, + technology vendors processing significant volumes of PHI, or entities where customers or + regulators demand the highest assurance + +Consult `references/hitrust-assessment-guide.md` for detailed assessment process steps, +scoring model, assessor engagement, and certification timelines. + +--- + +## HITRUST Maturity Model (Scoring) + +HITRUST uses a 5-level maturity model derived from Carnegie Mellon's PRISMA model: + +| Level | Name | Description | Scoring Weight | +|-------|------|-------------|---------------| +| 1 | Policy | Written policies exist and address the requirement | 25% | +| 2 | Procedure | Documented procedures describe how the policy is implemented | 25% | +| 3 | Implemented | Controls are operational and evidence demonstrates implementation | 25% | +| 4 | Measured | Performance metrics are collected and monitored | 15% | +| 5 | Managed | Processes are continuously reviewed and improved | 10% | + +**Scoring mechanics:** +- Each control specification receives a score per maturity level (0–3 per level) +- Control scores are weighted by level and aggregated +- **Minimum certification score**: 62 (out of 100) on each assessed control requirement +- Controls scoring below 62 are classified as non-certifiable findings requiring a + **Corrective Action Plan (CAP)** +- Controls scoring 62–74 are classified as partial findings (CAP recommended) +- Controls scoring 75–100 are certifiable + +--- + +## Core Workflows + +### 1. Assessment Type Selection + +When a user asks which HITRUST assessment is right for them: + +1. Ask: + - What is the primary driver? (Customer requirement, regulatory, internal programme) + - What is the organization's industry and size? + - What is the volume of PHI / sensitive data processed? + - Is this a first certification or renewal? + - What is the timeline and budget? + +2. Apply this decision framework: + - New to HITRUST, limited resources or timeline → **e1** + - Established security programme, moderate assurance needed → **i1** + - Large org, significant PHI volume, customer/regulatory mandate for top-tier → **r2** + +3. Output a structured recommendation with rationale, estimated effort, and comparison table. + +### 2. Gap Analysis + +When performing or assisting a gap analysis: + +1. Load `references/hitrust-control-domains.md` for the full control listing +2. Confirm: assessment type (e1/i1/r2), organization type, applicable regulations +3. For r2, ask about scoping factors (see `references/hitrust-scoping-factors.md`) +4. Produce a gap table covering all in-scope domains and controls: + +``` +| Category | Control ID | Requirement | Status | Gap Description | CAP Required | Priority | +|----------|-----------|-------------|--------|-----------------|--------------|----------| +| 01 | 01.a.1 | Access control policy documented | Partial | Policy exists but not annually reviewed | Yes | High | +``` + +**Status definitions:** +- Certifiable (75+): Control is fully implemented with evidence; no CAP required +- Near-Certifiable (62-74): Minor gaps; CAP recommended but certification achievable +- Non-Certifiable (<62): Significant gap; CAP required before certification +- N/A: Control excluded with documented justification + +5. Summarise: total controls assessed, certifiable count, CAP count, estimated remediation effort + +### 3. Corrective Action Planning + +When a user needs to create or manage CAPs: + +1. Load `references/hitrust-assessment-guide.md` for CAP requirements and lifecycle +2. For each non-certifiable or near-certifiable finding, create a CAP record: + +``` +CAP ID: CAP-001 +Control: 01.b.1 — User Registration +Finding: No formal user access request/approval process documented +Root Cause: Lack of documented procedure; informal approvals via email +Maturity Gap: Level 2 (Procedure) — No written procedure exists +Remediation: Draft and approve User Access Management Procedure; implement ticketing + workflow for access requests; train IT team +Owner: IT Security Manager +Target Date: [DATE] +Status: In Remediation +Evidence Plan: Procedure document v1.0, sample tickets, training records +``` + +3. Track CAPs across all findings and provide a summary dashboard by domain + +### 4. Policy and Procedure Generation + +When generating HITRUST-required policies: + +- Always include: Purpose, Scope, Policy Statement, Roles & Responsibilities, + Procedures, Enforcement, Review Cycle (annually minimum), References +- Map each document to the relevant HITRUST control category and specification ID(s) +- Include document control block: Version | Author | Approved By | Date | Next Review +- Note whether the policy addresses the Level 1 (Policy) and Level 2 (Procedure) + maturity requirements for each cited control + +**Key policies driven by HITRUST CSF:** + +| Policy | Primary Control Category | Key Specification(s) | +|--------|--------------------------|---------------------| +| Information Security Policy | 04 | 04.a.1 | +| Access Control Policy | 01 | 01.a.1 | +| Workforce Security Policy | 02 | 02.a.1, 02.b.1 | +| Risk Management Policy | 03 | 03.a.1, 03.b.1 | +| Incident Response Policy | 11 | 11.a.1, 11.c.1 | +| Business Continuity Plan | 12 | 12.a.1, 12.c.1 | +| Asset Management Policy | 07 | 07.a.1, 07.d.1 | +| Physical Security Policy | 08 | 08.a.1, 08.b.1 | +| Vulnerability Management Policy | 10 | 10.p.1 | +| Change Management Policy | 09 | 09.b.1 | +| Privacy Policy (HIPAA-aligned) | 13 | 13.a.1, 13.f.1 | +| Encryption / Cryptography Policy | 06, 10 | 06.f.1, 10.f.1 | +| Audit Logging Policy | 09 | 09.v.1, 09.x.1 | + +### 5. Inheritance and Shared Responsibility + +When a user asks about HITRUST inheritance (common for cloud customers and SaaS providers): + +1. Explain that HITRUST allows partial or full inheritance of controls from a HITRUST-certified + third party (the "Inheritor" inherits from the "Inheritee") +2. Load `references/hitrust-scoping-factors.md` for inheritance eligibility criteria +3. Produce a Shared Responsibility Matrix format: + +``` +| Control ID | Control Description | Responsibility | Inheritance Source | Evidence Required | +|-----------|---------------------|---------------|-------------------|-------------------| +| 08.a.1 | Physical perimeter | Inherited | AWS/Azure CSF Letter | Vendor CSF cert | +| 01.a.1 | Access Control Policy | Customer | N/A | Own policy doc | +``` + +4. Note that inherited controls still require the assessor to validate the inheritance + relationship and obtain the inheritee's current HITRUST certification letter + +--- + +## Evidence Requirements by Maturity Level + +For each control, guide users to collect: + +| Level | Evidence Type | +|-------|--------------| +| Level 1 (Policy) | Policy document with version, approval signature, and effective date | +| Level 2 (Procedure) | Procedure document(s) detailing who, what, when, how | +| Level 3 (Implemented) | Screenshots, configuration exports, system reports, sample records showing control in operation | +| Level 4 (Measured) | Metrics dashboards, KPI reports, compliance trending data | +| Level 5 (Managed) | Management review minutes, continuous improvement records, programme maturity reports | + +--- + +## Common Triggers and Responses + +| User says | Action | +|-----------|--------| +| "Which HITRUST assessment should we pursue?" | → Assessment Type Selection workflow | +| "We need to do a gap analysis" | → Gap Analysis workflow + load `references/hitrust-control-domains.md` | +| "We have CAPs to resolve" | → Corrective Action Planning workflow + load `references/hitrust-assessment-guide.md` | +| "Write a HITRUST-aligned policy" | → Policy Generation workflow | +| "How does HITRUST relate to HIPAA?" | → Explain harmonisation: HITRUST CSF incorporates all HIPAA Security Rule and Privacy Rule requirements as a subset | +| "We use AWS / Azure / GCP — can we inherit controls?" | → Inheritance workflow + load `references/hitrust-scoping-factors.md` | +| "What evidence does the assessor need?" | → Evidence Requirements by Maturity Level + load `references/hitrust-assessment-guide.md` | +| "How many controls are in scope for r2?" | → Scoping workflow + load `references/hitrust-scoping-factors.md` | +| "What is MyCSF?" | → Explain: MyCSF is HITRUST's web-based assessment management portal; organizations use it to complete self-assessments, track CAPs, manage assessor relationships, and receive certification letters | diff --git a/plugins/hitrust/skills/hitrust/references/hitrust-assessment-guide.md b/plugins/hitrust/skills/hitrust/references/hitrust-assessment-guide.md new file mode 100644 index 0000000..dc75f00 --- /dev/null +++ b/plugins/hitrust/skills/hitrust/references/hitrust-assessment-guide.md @@ -0,0 +1,484 @@ +# HITRUST Assessment Guide +## Assessment Types, Process, Scoring, and Certification Lifecycle + +--- + +## Table of Contents +1. [Assessment Type Comparison](#1-assessment-type-comparison) +2. [e1 — Entry-Level Assessment](#2-e1--entry-level-assessment) +3. [i1 — Implemented 1-Year Assessment](#3-i1--implemented-1-year-assessment) +4. [r2 — Risk-Based 2-Year Assessment](#4-r2--risk-based-2-year-assessment) +5. [HITRUST Maturity Model and Scoring](#5-hitrust-maturity-model-and-scoring) +6. [Assessment Process Steps](#6-assessment-process-steps) +7. [Corrective Action Plans (CAPs)](#7-corrective-action-plans-caps) +8. [MyCSF Platform](#8-mycsf-platform) +9. [HITRUST Authorized External Assessors](#9-hitrust-authorized-external-assessors) +10. [Certification Maintenance and Renewal](#10-certification-maintenance-and-renewal) +11. [Interim Assessment Requirements](#11-interim-assessment-requirements) + +--- + +## 1. Assessment Type Comparison + +| Feature | e1 | i1 | r2 | +|---------|-----|-----|-----| +| Number of control requirements | 44 | 219 (v11) | Variable (risk-tailored) | +| Certification period | 1 year | 1 year | 2 years | +| Interim assessment at 12 months | No | No | Yes (required) | +| Control set type | Fixed | Fixed (Defined Baseline) | Risk-tailored | +| Maturity levels assessed | 3 (Policy, Procedure, Implemented) | 3 (Policy, Procedure, Implemented) | All 5 levels | +| Assessor required | Yes (CPA firm) | Yes (HITRUST Authorized External Assessor) | Yes (HITRUST Authorized External Assessor) | +| HITRUST QA review | Streamlined | Standard | Full QA + validation | +| Primary use case | Basic cyber hygiene attestation | Moderate assurance for business partners | Highest assurance; major healthcare enterprises | +| Typical effort | Low | Moderate | Significant | +| Typical cost (indicative) | Lower | Moderate | Higher | +| Suitable for first-time HITRUST | Yes | Yes | Yes (with preparation) | +| Demonstrates HIPAA compliance support | Partial | Strong | Comprehensive | + +**Note:** Cost and timeline estimates vary significantly based on organization size, existing +programme maturity, and assessor fees. Engage a HITRUST Authorized External Assessor for +specific engagement scoping. + +--- + +## 2. e1 — Entry-Level Assessment + +### Purpose +The e1 assessment is designed to provide a basic, certifiable attestation of fundamental +cyber hygiene practices. It is the entry point into the HITRUST Assurance Program and is +suitable for organizations that are new to HITRUST or that need a low-cost foundational +attestation. + +### Scope +- 44 essential control requirements +- Fixed set — identical for all organizations regardless of risk factors +- Controls drawn from across the full HITRUST CSF control categories + +### Maturity Levels Assessed +For e1, each control is assessed at three maturity levels: +- Level 1: Policy +- Level 2: Procedure +- Level 3: Implemented + +Levels 4 and 5 (Measured and Managed) are not assessed in e1. + +### Assessor Requirements +- Assessment must be performed and validated by a CPA firm that is a HITRUST Authorized + External Assessor (AEA) +- The organization completes a self-assessment in MyCSF +- The AEA reviews and validates the responses + +### Evidence Expectations +For each of the 44 control requirements, the assessor will review: +- Policy documentation addressing the control +- Procedure documentation +- Evidence of implementation (screenshots, configuration exports, process records) + +### Key e1 Control Areas +The 44 e1 requirements cover foundational areas including: +- Basic access control (user provisioning, password requirements, MFA) +- Information security policy existence +- Security awareness training +- Malware protection +- Patch management and vulnerability management +- Audit logging +- Incident response plan existence +- Backup and recovery +- Network boundary protection + +--- + +## 3. i1 — Implemented 1-Year Assessment + +### Purpose +The i1 assessment demonstrates that an organization has a well-implemented security +programme meeting a defined baseline of controls. It provides moderate assurance and is +appropriate for organizations that have matured beyond entry-level practices and need a +stronger attestation for business partners or regulators. + +### Scope +- 219 control requirements (v11 Defined Baseline) +- Fixed set — same controls for all organizations in scope +- Covers all 14 control categories of the HITRUST CSF + +### Maturity Levels Assessed +For i1, each control is assessed at three maturity levels: +- Level 1: Policy +- Level 2: Procedure +- Level 3: Implemented + +### Assessor Requirements +- Assessment must be performed and validated by a HITRUST Authorized External Assessor (AEA) +- Full on-site or remote validation engagement +- Assessor submits validated responses to HITRUST for review + +### Certification Period +- 1 year from date of HITRUST certification letter issuance +- No interim assessment required (unlike r2) +- Renewal requires a new i1 assessment + +--- + +## 4. r2 — Risk-Based 2-Year Assessment + +### Purpose +The r2 assessment is the most comprehensive HITRUST assessment type. It demonstrates that +an organization has a robust, measured, and managed security programme across a risk-tailored +set of controls. The r2 is the most commonly recognized and demanded certification type in +healthcare and highly regulated industries. + +### Scope +- Variable number of control requirements based on risk factor scoring +- Typically ranges from approximately 150 to 500+ requirements +- The final set of in-scope controls is determined by HITRUST scoping factors populated in MyCSF + before the assessment begins + +### How Scoping Works for r2 +HITRUST uses "risk factors" to determine which control specifications are required for a +given organization. Each risk factor adds additional control requirements to the base set. +Key risk factors include: +- **Organization type** (Covered Entity, Business Associate, etc.) +- **Number of individuals whose records are processed** +- **Types of sensitive data processed** (ePHI, PII, payment card data) +- **Regulatory environment** (HIPAA, PCI DSS, CMS, state laws) +- **Technology factors** (cloud, mobile, web applications, remote access) +- **Geographic reach** + +See `hitrust-scoping-factors.md` for full factor details. + +### Maturity Levels Assessed +For r2, all five maturity levels are assessed: +- Level 1: Policy (25% weight) +- Level 2: Procedure (25% weight) +- Level 3: Implemented (25% weight) +- Level 4: Measured (15% weight) +- Level 5: Managed (10% weight) + +### Certifiable Threshold +- Each control requirement must achieve a minimum score of 62 (out of 100) to be certifiable +- Controls below 62 require a Corrective Action Plan (CAP) before certification can be issued +- Controls scoring 75 or above are fully certifiable + +### Interim Assessment +- Required at the 12-month mark of the 2-year certification period +- The interim assessment validates that controls remain operational +- Failure to complete the interim assessment will result in certification suspension +- Interim assessment covers a subset of the originally assessed controls + +### Assessor Requirements +- Full engagement with a HITRUST Authorized External Assessor +- HITRUST performs its own QA and validation review of the assessor's work +- HITRUST issues the final certification letter (not the assessor) + +### Certification Period +- 2 years from date of HITRUST certification letter +- Interim assessment required at 12 months +- Renewal assessment required before expiry + +--- + +## 5. HITRUST Maturity Model and Scoring + +### Five Maturity Levels + +HITRUST scores each control specification against five maturity levels derived from the +Carnegie Mellon PRISMA (Program Review for Information Security Management Assistance) model: + +**Level 1 — Policy** +- Is there a written policy that addresses and mandates this control? +- The policy must be approved by management, formally published, and accessible to relevant + personnel +- Scoring weight: 25% + +**Level 2 — Procedure** +- Are there documented procedures that describe how the policy is implemented? +- Procedures must be detailed enough for staff to follow; they must specify who does what, + when, and how +- Scoring weight: 25% + +**Level 3 — Implemented** +- Is the control actually operational? Is there evidence demonstrating implementation? +- Evidence includes screenshots, configuration exports, access logs, training records, etc. +- Scoring weight: 25% + +**Level 4 — Measured** +- Is performance of the control measured and monitored? +- Metrics, KPIs, compliance dashboards, and exception reports are typical evidence +- Scoring weight: 15% + +**Level 5 — Managed** +- Is the control process continuously reviewed and improved? +- Evidence includes management review records, improvement initiatives, programme maturity + reports, and periodic effectiveness testing +- Scoring weight: 10% + +### Scoring Scale Per Level + +For each maturity level, the assessor evaluates and scores 0–3: +- **0 (Non-Compliant)**: No evidence; requirement not met +- **1 (Somewhat Compliant)**: Partial evidence but significant gaps +- **2 (Partially Compliant)**: Evidence present but incomplete or inconsistent +- **3 (Fully Compliant)**: Comprehensive evidence; requirement fully met + +### Aggregate Score Calculation + +The aggregate score per control is calculated as: + +``` +Score = (L1_score/3 * 25%) + (L2_score/3 * 25%) + (L3_score/3 * 25%) + + (L4_score/3 * 15%) + (L5_score/3 * 10%) + * 100 +``` + +A perfect score = 100. Minimum certifiable = 62. + +### Score Interpretation + +| Score Range | Classification | CAP Required? | +|------------|----------------|---------------| +| 75–100 | Certifiable | No | +| 62–74 | Near-Certifiable (Partially Compliant finding) | CAP recommended | +| 0–61 | Non-Certifiable | CAP required | + +For **r2** certification, all assessed controls must score 62 or above to proceed +to certification. Controls at 62–74 require observation-level CAPs but do not block +certification. Controls below 62 require substantive CAPs that must be reviewed by HITRUST +before a certification letter can be issued. + +--- + +## 6. Assessment Process Steps + +### Phase 1 — Preparation (Pre-Assessment) + +**Step 1: Determine Assessment Type** +- Determine whether e1, i1, or r2 is appropriate based on organizational requirements, + customer demands, and regulatory landscape +- Consult with a HITRUST Authorized External Assessor + +**Step 2: Select an Assessor** +- Engage a HITRUST Authorized External Assessor (AEA) +- For e1: A CPA firm that is a HITRUST AEA +- For i1 and r2: Any HITRUST AEA organization +- The assessor registers the engagement in MyCSF + +**Step 3: Create/Access MyCSF Account** +- The organization must have an active MyCSF account +- The assessor creates the assessment in MyCSF linked to the organization's account + +**Step 4: Complete Scoping (r2 only)** +- For r2 assessments, complete the scoping questionnaire in MyCSF +- HITRUST uses the scoping responses to generate the in-scope control set +- Review the generated control set with the assessor before proceeding + +**Step 5: Readiness Assessment (Recommended)** +- Conduct an internal readiness assessment or engage the AEA for a readiness review +- Identify gaps and develop CAPs before the formal validated assessment begins +- Address critical gaps (controls likely to score below 62) before scheduling the full assessment + +### Phase 2 — Validated Assessment + +**Step 6: Organization Self-Assessment** +- Complete self-assessment responses in MyCSF for all in-scope controls +- Upload evidence for each maturity level being assessed +- Assign evidence to specific control requirements +- Ensure all Level 1 (Policy) and Level 2 (Procedure) responses reference specific documents + +**Step 7: Assessor Validation** +- The AEA reviews all self-assessment responses and uploaded evidence +- The assessor may request additional evidence or schedule interviews and site visits +- For r2, the assessor conducts comprehensive testing activities (interviews, observations, + system demonstrations, configuration reviews) +- The assessor scores each control at each maturity level +- Where the assessor disagrees with the organization's self-assessment, corrections are + documented with rationale + +**Step 8: Findings and CAP Development** +- The assessor identifies non-certifiable and near-certifiable findings +- For each finding, a Corrective Action Plan (CAP) must be documented in MyCSF +- CAPs must include: root cause, remediation plan, responsible owner, and target date +- CAPs for non-certifiable findings must be reviewed and accepted by HITRUST before + the assessment can proceed to certification + +### Phase 3 — HITRUST Review and Certification + +**Step 9: HITRUST QA Review** +- The completed and validated assessment is submitted to HITRUST +- HITRUST performs a quality assurance review of the assessment +- HITRUST may request clarifications from the assessor or additional documentation +- For r2, HITRUST performs a more intensive review + +**Step 10: Certification Decision** +- If all certifiable thresholds are met (all controls score 62+) and CAPs are in place for + any findings, HITRUST issues the certification letter +- The certification letter is the official documentation of HITRUST certification status +- The letter specifies: organization name, certification scope, assessment type, issue date, + and expiration date + +**Step 11: Post-Certification** +- For r2: Interim assessment required at 12 months +- Certification must be renewed before the expiration date +- Changes to the assessed environment that materially affect the control environment should + be communicated to the assessor + +--- + +## 7. Corrective Action Plans (CAPs) + +### What is a CAP? +A Corrective Action Plan is a formal documented plan to address a finding identified during +the HITRUST assessment. CAPs are mandatory for non-certifiable controls and recommended for +near-certifiable controls. + +### CAP Lifecycle +1. **Identified**: Finding identified by assessor during validated assessment +2. **Created**: CAP documented in MyCSF with required details +3. **In Remediation**: Organization actively working the remediation plan +4. **Submitted for Review**: Organization indicates remediation is complete +5. **Reviewed**: Assessor or HITRUST reviews CAP closure evidence +6. **Closed**: CAP closes when sufficient evidence demonstrates remediation + +### CAP Requirements +Each CAP record must include: +- **Finding description**: What the deficiency is and which control is affected +- **Root cause analysis**: Why the deficiency exists (not just what the deficiency is) +- **Remediation plan**: Specific steps to address the root cause +- **Implementation owner**: The person or role responsible for remediation +- **Target completion date**: Realistic date for remediation completion +- **Milestone dates**: Intermediate checkpoints for larger remediation efforts +- **Evidence plan**: What evidence will be provided to demonstrate closure + +### CAP Example Template + +``` +CAP ID: CAP-2024-001 +Control: 09.l.1 — Information Backup +Assessment Type: r2 +Finding: Backup recovery testing is not performed. Backups exist but no documented + evidence of restoration testing within the past 12 months. +Maturity Gap: Level 3 (Implemented) — Testing is not performed; Level 4 (Measured) — + No metrics on backup success/failure or recovery time. +Root Cause: Backup procedures do not include a test restoration step. + No formal schedule for recovery testing exists. +Remediation Plan: 1. Update Backup and Recovery Procedure to include quarterly restoration + testing requirement. + 2. Schedule and complete initial recovery test for all critical systems. + 3. Document results in a Backup Test Log. + 4. Implement monitoring alerts for backup job failures. +Owner: IT Infrastructure Manager +Target Date: [DATE — within 90 days of finding] +Milestones: [30 days] Procedure updated and approved + [60 days] Initial recovery test completed and documented + [90 days] Monitoring implemented; first month of backup metrics collected +Evidence Plan: Updated Backup and Recovery Procedure (v2.0), Backup Test Log with + results, monitoring dashboard screenshots, backup job success reports +Status: Open — In Remediation +``` + +--- + +## 8. MyCSF Platform + +### Overview +MyCSF (myCSF.net) is HITRUST's online assessment management platform. All HITRUST assessments +are conducted, tracked, and submitted through MyCSF. + +### Key Capabilities +- **Assessment creation and management**: Assessors and organizations create and manage + assessment engagements +- **Control scoping**: For r2 assessments, risk factor questionnaires generate the in-scope + control set +- **Self-assessment responses**: Organizations document their control posture and upload evidence +- **Assessor validation**: Assessors review, test, and score each control +- **CAP management**: Organizations and assessors track CAP lifecycle from creation to closure +- **Evidence repository**: Centralized repository for all assessment evidence +- **Inheritance management**: Organizations can document inherited controls from certified + third parties and link to their certification letters +- **Certification tracking**: Certification status, issue date, and expiration date + +### User Roles in MyCSF +- **Organization Administrator**: Primary point of contact; manages the assessment account +- **Organization Contributor**: Business users who complete control responses +- **External Assessor (AEA)**: Validates responses and scores controls; must be registered + as a HITRUST Authorized External Assessor +- **HITRUST Staff**: Performs QA review and issues certification letters + +--- + +## 9. HITRUST Authorized External Assessors + +### What is a HITRUST AEA? +A HITRUST Authorized External Assessor (AEA) is an organization that HITRUST has authorized +to perform validated assessments. AEAs must meet HITRUST's requirements for assessor training, +qualification, and quality standards. + +### Finding an AEA +HITRUST maintains a public directory of Authorized External Assessors on the HITRUST website +(hitrustalliance.net). Organizations should evaluate assessors based on: +- Industry experience (healthcare, technology, financial services) +- Familiarity with the organization's technology stack (cloud providers, EHR systems) +- Assessment type experience (e1 vs i1 vs r2) +- References from similar organizations +- Geographic capability + +### AEA Responsibilities +- Register the assessment engagement in MyCSF +- Conduct testing and validation of all in-scope controls +- Score each control at each maturity level +- Document findings and support CAP development +- Submit completed assessment to HITRUST for QA review +- Respond to HITRUST QA queries + +### Important: Separation of Readiness and Validation +HITRUST requires that an organization does not use the same firm to perform both the +readiness/gap assessment and the validated assessment for some assessment types. Confirm +the current independence requirements with HITRUST or the assessor before engaging. + +--- + +## 10. Certification Maintenance and Renewal + +### e1 Renewal +- Certification expires after 1 year +- A new e1 validated assessment must be completed to renew +- No interim assessment required during the certification period + +### i1 Renewal +- Certification expires after 1 year +- A new i1 validated assessment must be completed to renew +- No interim assessment required during the certification period +- Organizations may choose to upgrade to r2 at renewal + +### r2 Renewal +- Certification expires after 2 years +- An interim assessment is required at the 12-month mark +- A full r2 validated assessment must be completed before the 2-year expiry + +### Maintaining Certification Status +- Organizations must not experience significant negative changes in their control environment + during the certification period +- Newly discovered material control failures should be reported +- Changes in scope (new systems, new business lines) may require an assessment update + +--- + +## 11. Interim Assessment Requirements (r2 Only) + +### Purpose of the Interim Assessment +The interim assessment ensures that the control environment remains effective and consistent +with the original r2 certification throughout the 2-year certification period. + +### Timing +- Must be completed within the 12–18 month window following the certification letter + issue date +- HITRUST recommends targeting the 12-month mark to allow time for any remediation needed + +### Scope +- A subset of the originally assessed r2 controls are selected for interim review +- Selection is based on risk and coverage; HITRUST and the assessor determine the subset +- All open CAPs from the original assessment must be reviewed for progress + +### Outcome +- If the interim assessment demonstrates continued compliance, the certification remains valid +- If material deficiencies are found, additional CAPs must be developed +- Severe failures may result in certification suspension pending remediation diff --git a/plugins/hitrust/skills/hitrust/references/hitrust-control-domains.md b/plugins/hitrust/skills/hitrust/references/hitrust-control-domains.md new file mode 100644 index 0000000..435ac3d --- /dev/null +++ b/plugins/hitrust/skills/hitrust/references/hitrust-control-domains.md @@ -0,0 +1,876 @@ +# HITRUST CSF Control Domains Reference +## HITRUST Common Security Framework v9.x — Control Categories, Objectives, and Specifications + +This reference covers all 14 control categories, their control objectives, and the +associated control specifications. Specification IDs follow the convention: +`..` +(e.g., `01.a.1` = Category 01, Objective a, Specification 1). + +--- + +## Table of Contents +1. [00 — Information Security Management Program](#00--information-security-management-program) +2. [01 — Access Control](#01--access-control) +3. [02 — Human Resources Security](#02--human-resources-security) +4. [03 — Risk Management](#03--risk-management) +5. [04 — Security Policy](#04--security-policy) +6. [05 — Organization of Information Security](#05--organization-of-information-security) +7. [06 — Compliance](#06--compliance) +8. [07 — Asset Management](#07--asset-management) +9. [08 — Physical and Environmental Security](#08--physical-and-environmental-security) +10. [09 — Communications and Operations Management](#09--communications-and-operations-management) +11. [10 — Information Systems Acquisition, Development, and Maintenance](#10--information-systems-acquisition-development-and-maintenance) +12. [11 — Information Security Incident Management](#11--information-security-incident-management) +13. [12 — Business Continuity Management](#12--business-continuity-management) +14. [13 — Privacy Practices](#13--privacy-practices) + +--- + +## 00 — Information Security Management Program + +**Purpose:** Establish and maintain an overarching information security management program that +governs the organization's approach to protecting information assets. + +### Objective 00.a — Information Security Management Program + +| Specification | Title | Description | +|--------------|-------|-------------| +| 00.a.1 | Information Security Management Program | The organization must have a documented, maintained, and communicated information security management program that includes an information security framework, roles and responsibilities, and resources. The program must be reviewed at planned intervals or when significant changes occur. | + +**Key Policy/Procedure:** Information Security Program Charter or Policy + +**Evidence for assessors:** +- Information Security Program documentation +- Evidence of executive sponsorship (signed policy, board approval) +- Program review records and revision history + +--- + +## 01 — Access Control + +**Purpose:** Limit access to information and information systems to authorized users, +processes acting on behalf of authorized users, and devices (including other information +systems). + +### Objective 01.a — Access Control Policy + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.a.1 | Access Control Policy | A formal, documented access control policy must be established, covering the business requirements for access control, user access management, system and network access, and operating system access control. The policy must be reviewed and updated at a defined review interval. | + +### Objective 01.b — User Registration + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.b.1 | User Registration | A formal user registration and deregistration process must exist for granting and revoking access. Access must be granted based on business need-to-know and least privilege. Account provisioning must require documented approval. Accounts must be reviewed and removed when no longer required. | + +### Objective 01.c — Privilege Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.c.1 | Privilege Management | Privileged access (administrative rights) must be allocated on a need-to-use basis and must not be granted to general user accounts. Privileged accounts must use a separate, unique identifier from standard accounts. | + +### Objective 01.d — User Password Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.d.1 | User Password Management | Passwords must meet minimum complexity, minimum length (minimum 8 characters for standard users, minimum 15 for privileged accounts), and must be changed at defined intervals. Default passwords must be changed before system deployment. Password history enforcement must prevent reuse. | + +### Objective 01.e — Review of User Access Rights + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.e.1 | Review of User Access Rights | Access rights and privileges must be formally reviewed at regular intervals (at minimum annually) to ensure access remains appropriate. Results of reviews must be documented. Access must be revised or removed where the review identifies it is no longer required. | + +### Objective 01.f — Use of System Utilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.f.1 | Use of System Utilities | System utilities that can override system and application controls must be restricted, controlled, and monitored. Use of privileged system utilities must be logged. | + +### Objective 01.g — Clear Desk and Clear Screen Policy + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.g.1 | Clear Desk and Clear Screen Policy | A clear desk policy for papers and removable storage media and a clear screen policy for information processing facilities must be adopted and enforced. Unattended workstations must auto-lock within a defined period. | + +### Objective 01.h — Remote Diagnostic and Configuration Port Protection + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.h.1 | Remote Diagnostic and Configuration Port Protection | Physical and logical access to diagnostic and configuration ports must be controlled. Unused ports must be disabled. Access to diagnostic ports must be logged. | + +### Objective 01.i — Segregation in Networks + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.i.1 | Segregation in Networks | Groups of information services, users, and information systems must be segregated on networks. Network segmentation between trusted and untrusted networks (e.g., Internet, partner networks) must use firewalls or equivalent controls. Systems that process or store sensitive information must be placed in a separate network segment. | + +### Objective 01.j — Network Connection Control + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.j.1 | Network Connection Control | The network access capability of users must be restricted consistent with the access control policy and requirements. Connections must be restricted based on the principle of least privilege. | + +### Objective 01.k — Network Routing Control + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.k.1 | Network Routing Control | Routing controls must be implemented for networks to ensure computer connections and information flows do not breach the access control policy. | + +### Objective 01.l — Automated Information Systems Access + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.l.1 | Automated Information Systems Access | Automated access controls (e.g., RBAC, MAC) must be implemented to enforce the access control policy. Access must be based on job function and least privilege. | + +### Objective 01.m — Session Lock / Timeout + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.m.1 | Session Lock / Timeout | Information systems must enforce a session lock with a concealed screen after a defined period of inactivity. Users must re-authenticate to resume access. | + +### Objective 01.n — Monitoring System Access and Use + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.n.1 | Monitoring System Access and Use | Procedures to monitor the use of information systems must be established. Monitoring results must be reviewed regularly. Suspicious activity must be investigated and escalated. | + +### Objective 01.o — Network Boundary Protection + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.o.1 | Network Boundary Protection | The information system must monitor and control communications at the external boundary and key internal boundaries. The system must employ boundary protection devices. | + +### Objective 01.p — Wireless Access Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.p.1 | Wireless Access Management | Wireless access to information systems must be managed and controlled. Unauthorized wireless access points must be detected and disabled. Wireless encryption (minimum WPA2 / WPA3) must be enforced. | + +### Objective 01.q — Remote Access Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 01.q.1 | Remote Access Management | Remote access must use encrypted communications (VPN, TLS). Multi-factor authentication must be enforced for remote access to systems that store, process, or transmit sensitive information. Remote sessions must be monitored and logged. | + +--- + +## 02 — Human Resources Security + +**Purpose:** Ensure that employees and contractors understand their responsibilities, are +suitable for the roles they are being considered for, and that the organization is protected +in the event of changes or terminations. + +### Objective 02.a — Roles and Responsibilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.a.1 | Roles and Responsibilities | Information security roles and responsibilities must be defined, documented, and communicated to all employees, contractors, and third-party users as part of their employment or engagement terms. | + +### Objective 02.b — Screening + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.b.1 | Screening | Background verification checks must be carried out on all candidates for employment who will have access to sensitive information, consistent with relevant laws and regulations. The depth of screening must be proportional to the sensitivity of information accessed. | + +### Objective 02.c — Terms and Conditions of Employment + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.c.1 | Terms and Conditions of Employment | The contractual agreements with employees and contractors must state their responsibilities for information security. This includes acceptable use, confidentiality, and obligations that apply after termination. | + +### Objective 02.d — Management Responsibilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.d.1 | Management Responsibilities | Management must require employees, contractors, and third-party users to apply security in accordance with established policies and procedures. | + +### Objective 02.e — Security Awareness, Education, and Training + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.e.1 | Security Awareness, Education, and Training | All employees and relevant third-party users must receive appropriate security awareness training. Training must be completed upon hire and at least annually. Training must cover the organization's policies, procedures, and threats relevant to their role. Training completion must be tracked. | + +### Objective 02.f — Disciplinary Process + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.f.1 | Disciplinary Process | A formal and documented disciplinary process must exist for employees who have committed a security breach or policy violation. | + +### Objective 02.g — Termination Responsibilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.g.1 | Termination Responsibilities | Responsibilities for the termination or change of employment must be defined and assigned. Processes must ensure that access rights are removed and assets returned upon departure. | + +### Objective 02.h — Return of Assets + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.h.1 | Return of Assets | All employees and contractors must return all organizational assets in their possession upon termination or change of role. This includes devices, storage media, identity credentials, and physical keys or access cards. | + +### Objective 02.i — Removal of Access Rights + +| Specification | Title | Description | +|--------------|-------|-------------| +| 02.i.1 | Removal of Access Rights | Access rights to information and information systems must be removed upon termination or change of employment. Changes in role must trigger an access rights review. Access removal must occur on the effective date of departure. | + +--- + +## 03 — Risk Management + +**Purpose:** Establish and maintain a risk management programme to identify, assess, treat, +and monitor information risks. + +### Objective 03.a — Risk Management Program Development + +| Specification | Title | Description | +|--------------|-------|-------------| +| 03.a.1 | Risk Management Program Development | The organization must develop a documented risk management programme that includes the risk management methodology, organisational risk tolerance, assignment of roles and responsibilities, and a schedule for risk assessments. | + +### Objective 03.b — Performing Risk Assessments + +| Specification | Title | Description | +|--------------|-------|-------------| +| 03.b.1 | Performing Risk Assessments | Risk assessments must be performed at defined intervals (at minimum annually) and when significant changes occur to information systems or the operational environment. Risk assessments must identify threats, vulnerabilities, likelihood, impact, and existing controls. Results must be documented and reviewed by management. | + +### Objective 03.c — Risk Mitigation + +| Specification | Title | Description | +|--------------|-------|-------------| +| 03.c.1 | Risk Mitigation | A risk treatment plan must be developed to address identified risks. The plan must include selected treatment options (accept, avoid, transfer, mitigate), assigned owners, timelines, and residual risk assessment. Treatment must be implemented and tracked. | + +### Objective 03.d — Risk Evaluation + +| Specification | Title | Description | +|--------------|-------|-------------| +| 03.d.1 | Risk Evaluation | Residual risks must be evaluated after treatment. Management must formally accept residual risks at or below the organization's defined risk tolerance. Risk evaluation must be documented and retained. | + +--- + +## 04 — Security Policy + +**Purpose:** Provide direction and support for information security in accordance with +business requirements and relevant laws and regulations. + +### Objective 04.a — Information Security Policy Document + +| Specification | Title | Description | +|--------------|-------|-------------| +| 04.a.1 | Information Security Policy Document | An information security policy document must be approved by management, published, and communicated to all employees and external parties as relevant. The policy must address general direction, principles, and requirements for protecting information. | + +### Objective 04.b — Review of the Information Security Policy + +| Specification | Title | Description | +|--------------|-------|-------------| +| 04.b.1 | Review of the Information Security Policy | The information security policy must be reviewed at planned intervals (at minimum annually) and in response to significant events or changes in the threat environment, business, or regulatory requirements. Reviews must be documented. | + +--- + +## 05 — Organization of Information Security + +**Purpose:** Establish a management framework to initiate and control the implementation +of information security within the organization, and to manage third-party relationships +securely. + +### Objective 05.a — Management Commitment to Information Security + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.a.1 | Management Commitment to Information Security | Management must actively support security within the organization through clear direction, demonstrated commitment, explicit assignment, and acknowledgment of information security responsibilities. | + +### Objective 05.b — Information Security Coordination + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.b.1 | Information Security Coordination | Information security activities must be coordinated across the organization by representatives from different parts of the organization with relevant roles and job functions. | + +### Objective 05.c — Allocation of Information Security Responsibilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.c.1 | Allocation of Information Security Responsibilities | All information security responsibilities must be defined and allocated. An information security function with clearly defined responsibilities must exist. | + +### Objective 05.d — Authorization Process for Information Processing Facilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.d.1 | Authorization Process | A management authorization process must be in place for new information processing facilities. | + +### Objective 05.e — Confidentiality Agreements + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.e.1 | Confidentiality Agreements | Requirements for confidentiality or non-disclosure agreements must be identified and reviewed regularly. Employees, contractors, and third parties with access to sensitive information must sign appropriate NDAs. | + +### Objective 05.f — Contact with Authorities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.f.1 | Contact with Authorities | Appropriate contacts with relevant authorities must be maintained, including law enforcement and regulatory bodies that must be notified in the event of a security incident or data breach. | + +### Objective 05.g — Contact with Special Interest Groups + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.g.1 | Contact with Special Interest Groups | Appropriate contacts with special interest groups or other specialist security forums and industry associations must be maintained to stay informed of threat intelligence and best practices. | + +### Objective 05.h — Independent Review of Information Security + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.h.1 | Independent Review of Information Security | The organization's approach to managing information security and its implementation must be reviewed independently at planned intervals or when significant changes occur. | + +### Objective 05.i — Identification of Risks Related to External Parties + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.i.1 | Identification of Risks Related to External Parties | Risks to the organization's information and information systems from third-party processes must be identified and controls implemented before granting access. | + +### Objective 05.j — Addressing Security when Dealing with Customers + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.j.1 | Addressing Security when Dealing with Customers | Information security requirements for customer-facing services and systems must be identified and addressed in service agreements. | + +### Objective 05.k — Addressing Security in Third-Party Agreements + +| Specification | Title | Description | +|--------------|-------|-------------| +| 05.k.1 | Addressing Security in Third-Party Agreements | Agreements with third parties involving access to, processing, communication, or management of the organization's information or systems must include security requirements. Business Associate Agreements (BAAs) must be in place where required by HIPAA. | + +--- + +## 06 — Compliance + +**Purpose:** Avoid breaches of legal, regulatory, or contractual obligations related to +information security and of any security requirements. + +### Objective 06.a — Identification of Applicable Legislation + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.a.1 | Identification of Applicable Legislation | All relevant legislative, regulatory, and contractual requirements and the organization's approach to meeting those requirements must be explicitly identified, documented, and kept up to date. | + +### Objective 06.b — Intellectual Property Rights + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.b.1 | Intellectual Property Rights | Appropriate procedures must be implemented to ensure compliance with legislative, regulatory, and contractual requirements on the use of material in respect of which there may be intellectual property rights. | + +### Objective 06.c — Protection of Organizational Records + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.c.1 | Protection of Organizational Records | Important records must be protected from loss, destruction, falsification, unauthorized access, and unauthorized release, in accordance with legal, regulatory, contractual, and business requirements. Retention schedules must be documented and enforced. | + +### Objective 06.d — Data Protection and Privacy + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.d.1 | Data Protection and Privacy of Personal Information | The protection of personal data and privacy must be ensured as required by relevant legislation and regulations (including HIPAA, state breach notification laws, and other applicable privacy requirements). A data protection officer or privacy officer role must be defined where required. | + +### Objective 06.e — Prevention of Misuse of Information Processing Facilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.e.1 | Prevention of Misuse of Information Processing Facilities | Users must be deterred from using information processing facilities for unauthorized purposes. Acceptable use must be defined, communicated, and acknowledged by users. | + +### Objective 06.f — Regulation of Cryptographic Controls + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.f.1 | Regulation of Cryptographic Controls | The organization must comply with agreements, laws, and regulations on the use of cryptographic controls, including use of encryption, export/import restrictions, and key management obligations. | + +### Objective 06.g — Technical Compliance Review + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.g.1 | Technical Compliance Review | Information systems must be regularly reviewed for compliance with the organization's security policies and standards. Technical compliance reviews must include vulnerability scans and configuration assessments. | + +### Objective 06.h — System Audit Controls + +| Specification | Title | Description | +|--------------|-------|-------------| +| 06.h.1 | System Audit Controls | Audit requirements and activities involving verification of operational systems must be carefully planned to minimize disruptions to business processes. Access to system audit tools must be protected to prevent misuse or compromise. | + +--- + +## 07 — Asset Management + +**Purpose:** Identify organizational assets and define appropriate protection responsibilities. + +### Objective 07.a — Inventory of Assets + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.a.1 | Inventory of Assets | All assets associated with information and information processing facilities must be identified and an inventory of these assets must be drawn up and maintained. The inventory must include owner, location, classification, and criticality. | + +### Objective 07.b — Ownership of Assets + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.b.1 | Ownership of Assets | All information and information processing assets must have a designated owner. Asset owners must be accountable for maintaining appropriate protection of the asset. | + +### Objective 07.c — Acceptable Use of Assets + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.c.1 | Acceptable Use of Assets | Rules for the acceptable use of information and assets associated with information processing facilities must be identified, documented, and implemented. | + +### Objective 07.d — Classification of Information + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.d.1 | Classification Guidelines | Information must be classified in terms of its sensitivity and criticality, with a documented classification scheme. The scheme must at minimum define handling requirements for sensitive/confidential and restricted information including ePHI. | + +### Objective 07.e — Information Labeling and Handling + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.e.1 | Information Labeling and Handling | Procedures for information labeling and handling must be developed and implemented in accordance with the classification scheme. | + +### Objective 07.f — Management of Removable Media + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.f.1 | Management of Removable Media | Procedures must be in place for the management of removable media, including authorization for use, encryption requirements, inventory, and controls to prevent unauthorized data extraction. | + +### Objective 07.g — Disposal of Media + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.g.1 | Disposal of Media | Media that is no longer required must be disposed of securely and safely using documented procedures. Disposal methods must render data unrecoverable (e.g., degaussing, physical destruction, certified wiping). Certificates of destruction must be obtained and retained. | + +### Objective 07.h — Physical Media in Transit + +| Specification | Title | Description | +|--------------|-------|-------------| +| 07.h.1 | Physical Media in Transit | Media containing information must be protected against unauthorized access, misuse, or corruption during transportation. Chain of custody must be documented for sensitive media in transit. | + +--- + +## 08 — Physical and Environmental Security + +**Purpose:** Prevent unauthorized physical access, damage, and interference to organizational +information and information processing facilities. + +### Objective 08.a — Physical Security Perimeter + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.a.1 | Physical Security Perimeter | Security perimeters (e.g., walls, card-controlled entry gates or staffed reception desks) must be used to protect areas that contain sensitive information and information processing facilities. | + +### Objective 08.b — Physical Entry Controls + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.b.1 | Physical Entry Controls | Secure areas must be protected by appropriate entry controls to ensure that only authorized personnel are allowed access. Access must be logged and reviewed. | + +### Objective 08.c — Securing Offices, Rooms, and Facilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.c.1 | Securing Offices, Rooms, and Facilities | Physical security for offices, rooms, and facilities must be designed and applied, taking account of relevant health and safety regulations and standards. | + +### Objective 08.d — Protecting Against External and Environmental Threats + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.d.1 | Protecting Against Environmental Threats | Physical protection against natural disasters, malicious attack, or accidents must be designed and applied. Environmental controls (fire suppression, temperature, humidity) must be implemented for data centres and server rooms. | + +### Objective 08.e — Working in Secure Areas + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.e.1 | Working in Secure Areas | Physical protection and guidelines for working in secure areas must be designed and applied. Visitors must be supervised while in secure areas. | + +### Objective 08.f — Public Access, Delivery, and Loading Areas + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.f.1 | Delivery and Loading Areas | Access to delivery and loading areas from outside buildings must be controlled and, where possible, isolated from information processing facilities to avoid unauthorized access. | + +### Objective 08.g — Equipment Siting and Protection + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.g.1 | Equipment Siting and Protection | Equipment must be sited and protected to reduce the risks from environmental threats and hazards, and opportunities for unauthorized access. | + +### Objective 08.h — Supporting Utilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.h.1 | Supporting Utilities | Equipment must be protected from power failures and other disruptions caused by failures in supporting utilities (power, UPS, HVAC, water). Redundancy must be implemented for critical systems. | + +### Objective 08.i — Cabling Security + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.i.1 | Cabling Security | Power and telecommunications cabling carrying data or supporting information services must be protected from interception or damage. | + +### Objective 08.j — Equipment Maintenance + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.j.1 | Equipment Maintenance | Equipment must be correctly maintained to ensure its continued availability and integrity. Maintenance must follow manufacturer recommendations and must be documented. | + +### Objective 08.k — Security of Equipment Off-Premises + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.k.1 | Security of Equipment Off-Premises | Security must be applied to off-site equipment, taking into account the different risks of working outside the organization's premises. Laptops and mobile devices used off-site must be encrypted. | + +### Objective 08.l — Secure Disposal or Reuse of Equipment + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.l.1 | Secure Disposal or Reuse of Equipment | All items of equipment containing storage media must be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or reuse. | + +### Objective 08.m — Removal of Property + +| Specification | Title | Description | +|--------------|-------|-------------| +| 08.m.1 | Removal of Property | Equipment, information, or software must not be taken off-site without prior authorization. Records of assets removed must be maintained. | + +--- + +## 09 — Communications and Operations Management + +**Purpose:** Ensure the correct and secure operation of information processing facilities, +and control changes to systems with documented procedures. + +### Objective 09.a — Documented Operating Procedures + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.a.1 | Documented Operating Procedures | Operating procedures must be documented, maintained, and made available to all users who need them. | + +### Objective 09.b — Change Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.b.1 | Change Management | Changes to information systems and processing facilities must be controlled through a formal change management process requiring risk assessment, testing, documented approval, and rollback planning. | + +### Objective 09.c — Segregation of Duties + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.c.1 | Segregation of Duties | Duties and areas of responsibility must be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization's assets. | + +### Objective 09.d — Separation of Development, Test, and Production Environments + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.d.1 | Separation of Development and Production | Development, testing, and operational environments must be separated and controls must be in place to reduce the risk of unauthorized access or changes to operational systems. Real PHI or sensitive data must not be used in test/development environments unless de-identified or with equivalent controls. | + +### Objective 09.e — Service Delivery Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.e.1 | Service Delivery | Service delivery agreements with third parties must include security requirements. Service delivery must be monitored to ensure services are delivered in accordance with agreements. | + +### Objective 09.f — Monitoring and Review of Third-Party Services + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.f.1 | Monitoring and Review of Third-Party Services | Services, reports, and records provided by third parties must be regularly monitored and reviewed. Audit rights must be established in third-party agreements. | + +### Objective 09.g — Managing Changes to Third-Party Services + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.g.1 | Managing Changes to Third-Party Services | Changes to the provision of services, including maintaining and improving existing information security policies, procedures, and controls, must be managed taking into account the criticality of business systems and processes involved. | + +### Objective 09.h — Capacity Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.h.1 | Capacity Management | The use of resources must be monitored and tuned, and projections must be made for future capacity requirements to ensure the required system performance. | + +### Objective 09.i — System Acceptance + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.i.1 | System Acceptance | Acceptance criteria for new information systems, upgrades, and new versions must be established and suitable tests of the system carried out before acceptance. | + +### Objective 09.j — Controls Against Malicious Code + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.j.1 | Controls Against Malicious Code | Detection, prevention, and recovery controls to protect against malicious code must be implemented. Anti-malware software (including endpoint protection) must be deployed on all user workstations and servers. Definitions must be kept current. | + +### Objective 09.k — Controls Against Mobile Code + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.k.1 | Controls Against Mobile Code | Mobile code (e.g., scripts, applets, browser-based code) must be authorized before use. Unauthorized mobile code must be blocked. Configuration must prevent execution of unauthorized mobile code. | + +### Objective 09.l — Information Backup + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.l.1 | Information Backup | Backup copies of information and software must be created and tested regularly in accordance with an agreed backup policy. Backups must be stored securely, including off-site copies. Backups containing ePHI must be encrypted. Recovery procedures must be tested at defined intervals. | + +### Objective 09.m — Network Security Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.m.1 | Network Security Management | Networks must be adequately managed to protect systems and applications. Network security controls must include firewalls, intrusion detection/prevention systems, and monitoring. | + +### Objective 09.n — Security of Network Services + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.n.1 | Security of Network Services | Security features, service levels, and management requirements of all network services must be identified and included in network service agreements. | + +### Objective 09.o — Exchange of Information + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.o.1 | Exchange of Information Policies and Procedures | Policies, procedures, and controls must be in place to protect the exchange of information through the use of all types of communication facilities. | + +### Objective 09.p — Electronic Messaging / Email Security + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.p.1 | Electronic Messaging | Information involved in electronic messaging must be appropriately protected. PHI must not be transmitted in unencrypted email. Encryption or secure messaging solutions must be used for ePHI transmission. | + +### Objective 09.q — E-Commerce Services + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.q.1 | E-Commerce Services | Information involved in e-commerce passing over public networks must be protected from fraudulent activity, contract dispute, and unauthorized disclosure. | + +### Objective 09.r — Audit Logging + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.r.1 | Audit Logging | Audit logs recording user activities, exceptions, and information security events must be maintained for an agreed period. Log retention must comply with applicable regulatory requirements (HIPAA: minimum 6 years). Logs must capture: user ID, date/time, event type, success/failure, and affected data. | + +### Objective 09.s — Monitoring System Use + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.s.1 | Monitoring System Use | Procedures for monitoring use of information systems must be established and the results regularly reviewed. High-risk activities and access to ePHI must be actively monitored. | + +### Objective 09.t — Protection of Log Information + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.t.1 | Protection of Log Information | Logging facilities and log information must be protected against tampering and unauthorized access. Logs must be stored in a separate, secure system from the systems they monitor. | + +### Objective 09.u — Clock Synchronization + +| Specification | Title | Description | +|--------------|-------|-------------| +| 09.u.1 | Clock Synchronization | The clocks of all relevant information processing systems must be synchronised with an agreed accurate time source (NTP). Time consistency is essential for correlating security events across systems. | + +--- + +## 10 — Information Systems Acquisition, Development, and Maintenance + +**Purpose:** Ensure that information security is an integral part of information systems +across their entire lifecycle, and ensure that systems are developed, acquired, and maintained +securely. + +### Objective 10.a — Security Requirements Analysis and Specification + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.a.1 | Security Requirements Analysis | Security requirements must be included in requirements for new information systems or enhancements to existing information systems. | + +### Objective 10.b — Input Data Validation + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.b.1 | Input Data Validation | Data input to applications must be validated to ensure that this data is correct and appropriate. Validation controls must address injection attacks (SQL injection, XSS, command injection). | + +### Objective 10.c — Control of Internal Processing + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.c.1 | Control of Internal Processing | Validation checks must be incorporated into applications to detect any corruption of information through processing errors or deliberate acts. | + +### Objective 10.d — Message Integrity + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.d.1 | Message Integrity | Requirements for ensuring authenticity and protecting message integrity in applications must be identified and appropriate controls implemented. | + +### Objective 10.e — Output Data Validation + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.e.1 | Output Data Validation | Data output from an application must be validated to ensure that the processing of stored information is correct and appropriate to the circumstances. | + +### Objective 10.f — Policy on the Use of Cryptographic Controls + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.f.1 | Policy on the Use of Cryptographic Controls | A policy for the use of cryptographic controls for protection of information must be developed and implemented. Minimum encryption standards must be defined: AES-256 for data at rest, TLS 1.2 or higher for data in transit. | + +### Objective 10.g — Key Management + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.g.1 | Key Management | Key management must include key generation, distribution, storage, retirement, and destruction. Keys must be protected against unauthorised access. Key management responsibilities must be assigned. | + +### Objective 10.h — Control of Technical Vulnerabilities + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.h.1 | Control of Technical Vulnerabilities | Timely information about technical vulnerabilities of information systems in use must be obtained, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken to address the associated risk. Vulnerability scans must be conducted at defined intervals (minimum quarterly for internal systems; monthly for internet-facing assets). | + +### Objective 10.i — Restrictions on Changes to Software Packages + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.i.1 | Restrictions on Changes to Software Packages | Modifications to software packages must be discouraged. Where necessary, changes should be limited to necessary modifications and all changes must be strictly controlled. | + +### Objective 10.j — Protection of System Test Data + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.j.1 | Protection of System Test Data | Test data must be selected carefully, protected, and controlled. ePHI and sensitive production data must not be used in test environments. Where necessary, production data used in testing must be masked, anonymised, or replaced with synthetic data. | + +### Objective 10.k — Access Control to Program Source Code + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.k.1 | Access Control to Program Source Code | Access to program source code must be restricted to authorized personnel. Code repositories must have access controls, audit logging, and change tracking. | + +### Objective 10.l — Outsourced Software Development + +| Specification | Title | Description | +|--------------|-------|-------------| +| 10.l.1 | Outsourced Software Development | Outsourced software development must be supervised and monitored by the organization. Security requirements must be included in outsourcing contracts. Code reviews and security testing must be performed before deployment. | + +--- + +## 11 — Information Security Incident Management + +**Purpose:** Ensure a consistent and effective approach to the management of information +security incidents, including communication on security events and weaknesses. + +### Objective 11.a — Reporting Information Security Events + +| Specification | Title | Description | +|--------------|-------|-------------| +| 11.a.1 | Reporting Information Security Events | Information security events must be reported through appropriate management channels as quickly as possible. A formal incident reporting procedure must exist. All staff must be aware of how to report security events and must be encouraged to report suspected events promptly. | + +### Objective 11.b — Reporting Security Weaknesses + +| Specification | Title | Description | +|--------------|-------|-------------| +| 11.b.1 | Reporting Security Weaknesses | All employees, contractors, and third-party users must be required to note and report any observed or suspected security weaknesses in systems or services. | + +### Objective 11.c — Responsibilities and Procedures + +| Specification | Title | Description | +|--------------|-------|-------------| +| 11.c.1 | Responsibilities and Procedures | Management responsibilities and procedures must be established to ensure a quick, effective, and orderly response to information security incidents. An Incident Response Plan (IRP) must be documented, tested, and maintained. The IRP must include: roles and responsibilities, communication procedures, escalation criteria, containment, eradication, recovery, post-incident review, and HIPAA breach notification assessment. | + +### Objective 11.d — Learning from Information Security Incidents + +| Specification | Title | Description | +|--------------|-------|-------------| +| 11.d.1 | Learning from Information Security Incidents | Mechanisms must be in place to enable the types, volumes, and costs of information security incidents to be quantified and monitored. Lessons learned from incidents must be documented and used to improve the security programme. | + +### Objective 11.e — Collection of Evidence + +| Specification | Title | Description | +|--------------|-------|-------------| +| 11.e.1 | Collection of Evidence | Where a follow-up action against a person or organization involves legal action or disciplinary proceedings, evidence must be collected, retained, and presented in a manner that conforms to legal requirements. Chain of custody must be maintained for digital forensic evidence. | + +--- + +## 12 — Business Continuity Management + +**Purpose:** Counteract interruptions to business activities and to protect critical business +processes from the effects of major failures of information systems or disasters, to ensure +their timely resumption. + +### Objective 12.a — Including Information Security in Business Continuity + +| Specification | Title | Description | +|--------------|-------|-------------| +| 12.a.1 | Including Information Security in Business Continuity | A managed process must be developed and maintained for business continuity throughout the organization that addresses the information security requirements needed during an adverse situation. | + +### Objective 12.b — Business Continuity and Risk Assessment + +| Specification | Title | Description | +|--------------|-------|-------------| +| 12.b.1 | Business Continuity and Risk Assessment | Events that can cause interruptions to business processes must be identified, along with the probability and impact of such interruptions and their consequences for information security. Business Impact Analysis (BIA) must be performed and documented. | + +### Objective 12.c — Developing and Implementing Continuity Plans + +| Specification | Title | Description | +|--------------|-------|-------------| +| 12.c.1 | Developing and Implementing Continuity Plans | Plans must be developed and implemented to maintain or restore operations and ensure availability of information at the required level and in the required timescales following interruption or failure. Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) must be defined and documented for critical systems and data. | + +### Objective 12.d — Business Continuity Planning Framework + +| Specification | Title | Description | +|--------------|-------|-------------| +| 12.d.1 | Business Continuity Planning Framework | A single framework of business continuity plans must be maintained to ensure all plans are consistent, and to identify priorities for testing and maintenance. | + +### Objective 12.e — Testing, Maintaining, and Re-Assessing Continuity Plans + +| Specification | Title | Description | +|--------------|-------|-------------| +| 12.e.1 | Testing, Maintaining, and Re-Assessing Plans | Business continuity plans must be tested and updated regularly to ensure they are up to date and effective. Tests must occur at minimum annually and after significant changes. Test results and lessons learned must be documented. | + +--- + +## 13 — Privacy Practices + +**Purpose:** Ensure the organization handles protected health information (PHI) and other +sensitive personal information in accordance with applicable privacy regulations, including +HIPAA and relevant state laws. + +This category directly aligns with HIPAA Privacy Rule requirements (45 CFR Part 164, +Subpart E) and applies to Covered Entities and Business Associates. + +### Objective 13.a — Privacy Notice + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.a.1 | Notice of Privacy Practices | Covered Entities must provide individuals with a notice of their privacy practices (NPP). The NPP must describe: uses and disclosures of PHI, patient rights, the CE's legal duties, and how complaints can be filed. The NPP must be made available at first service and upon request. | + +### Objective 13.b — Security Safeguards for PHI + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.b.1 | Security Safeguards | Administrative, physical, and technical safeguards must be in place to protect the confidentiality, integrity, and availability of ePHI. A Security Risk Analysis must be performed and documented. A Risk Management Plan must exist to mitigate identified risks. | + +### Objective 13.c — Transmission Security for PHI + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.c.1 | Transmission Security | ePHI transmitted over electronic communications networks must be protected. Encryption must be used when transmitting ePHI over open networks. Mechanisms to ensure integrity of ePHI during transmission must be implemented. | + +### Objective 13.d — Individual Access to PHI + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.d.1 | Individual Access | Covered Entities must provide individuals with access to their PHI upon request, within the required timeframe (30 days, extendable once by 30 days). Processes for handling access requests, including verification, must be documented. | + +### Objective 13.e — Amendment of PHI + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.e.1 | Amendment | Covered Entities must provide individuals with the ability to request amendment to their PHI. Processes for accepting, denying, and tracking amendment requests must be documented. | + +### Objective 13.f — Minimum Necessary Standard + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.f.1 | Minimum Necessary | Covered Entities and Business Associates must make reasonable efforts to use, disclose, and request only the minimum amount of PHI necessary to accomplish the intended purpose. Procedures must define what constitutes minimum necessary for routine disclosures. | + +### Objective 13.g — Accounting of Disclosures + +| Specification | Title | Description | +|--------------|-------|-------------| +| 13.g.1 | Accounting of Disclosures | Covered Entities must be capable of providing individuals with an accounting of certain disclosures of their PHI made for purposes other than treatment, payment, or healthcare operations. Disclosure tracking must be maintained for 6 years. | diff --git a/plugins/hitrust/skills/hitrust/references/hitrust-framework-overview.md b/plugins/hitrust/skills/hitrust/references/hitrust-framework-overview.md new file mode 100644 index 0000000..1c684a8 --- /dev/null +++ b/plugins/hitrust/skills/hitrust/references/hitrust-framework-overview.md @@ -0,0 +1,322 @@ +# HITRUST Framework Overview +## HITRUST Alliance, Common Security Framework History, Versions, and Key Concepts + +--- + +## Table of Contents +1. [About HITRUST Alliance](#1-about-hitrust-alliance) +2. [HITRUST CSF — What It Is and What It Solves](#2-hitrust-csf--what-it-is-and-what-it-solves) +3. [Framework Version History](#3-framework-version-history) +4. [HITRUST vs. HIPAA — Key Differences](#4-hitrust-vs-hipaa--key-differences) +5. [HITRUST vs. Other Frameworks](#5-hitrust-vs-other-frameworks) +6. [Cross-Framework Mapping](#6-cross-framework-mapping) +7. [Who Needs HITRUST Certification](#7-who-needs-hitrust-certification) +8. [HITRUST and Shared Compliance](#8-hitrust-and-shared-compliance) +9. [Key HITRUST Terminology](#9-key-hitrust-terminology) +10. [Disclaimer and Limitations](#10-disclaimer-and-limitations) + +--- + +## 1. About HITRUST Alliance + +**HITRUST Alliance** is a private organization founded in **2007** by a group of healthcare +and information security leaders. Headquartered in the United States, HITRUST was created to +address the lack of a unified, certifiable security framework for the healthcare industry. + +HITRUST is not a government agency and HITRUST certification is not a regulatory requirement +mandated by any federal or state law. However, HITRUST certification is widely accepted as +evidence of a robust information security and compliance programme, particularly within the +US healthcare ecosystem. + +**Key facts about HITRUST Alliance:** +- Founded: 2007 +- HITRUST CSF first published: 2009 +- Type: Private, for-profit organization +- Headquarters: Frisco, Texas, USA +- Primary product: HITRUST CSF and the HITRUST Assurance Program +- MyCSF platform: Proprietary web-based assessment management portal + +--- + +## 2. HITRUST CSF — What It Is and What It Solves + +### The Problem HITRUST Was Created to Address +Before HITRUST, healthcare organizations and their business partners faced a fragmented +compliance landscape. A single covered entity or business associate might receive different +security questionnaires from dozens of health plans, each asking about different standards +(HIPAA, ISO 27001, NIST SP 800-53, PCI DSS, etc.) with no consistent way to demonstrate +compliance across all of them. + +HITRUST CSF was designed to: +1. **Consolidate** — Incorporate requirements from multiple frameworks and regulations into + a single, prescriptive control set +2. **Certify** — Enable organizations to obtain a certifiable attestation enforceable through + third-party assessment, rather than self-attestation +3. **Scale** — Apply to organizations of different sizes, types, and risk profiles through + the risk-tailoring mechanism of the r2 assessment +4. **Reduce audit fatigue** — Allow organizations to use a single HITRUST certification to + satisfy multiple customer and regulatory inquiries simultaneously + +### What the CSF Is +The HITRUST Common Security Framework (CSF) is: +- A **prescriptive, certifiable security and privacy framework** +- Designed to be **risk-based and scalable** across organization types and sizes +- An **integrating framework** that harmonises multiple authoritative sources +- Applicable primarily to **healthcare** but increasingly adopted in financial services, + technology, and other regulated sectors + +### What the CSF Is Not +- HITRUST CSF certification is **not a legal requirement** under HIPAA or any federal law +- HITRUST certification does **not guarantee or constitute legal HIPAA compliance** — + however, it is widely considered strong evidence of a robust HIPAA security programme +- HITRUST is **not a government standard** — it is a privately developed framework +- Passing the HITRUST assessment does **not mean every control in the HITRUST CSF applies**; + only in-scope controls are assessed + +--- + +## 3. Framework Version History + +| Version | Release Year | Key Changes | +|---------|-------------|-------------| +| CSF v1 | 2009 | Initial publication; baseline control set derived from HIPAA and ISO 27001 | +| CSF v6 | c. 2013 | Significant expansion; added NIST SP 800-53 and PCI DSS mapping | +| CSF v7 | c. 2015 | Updated to NIST SP 800-53 Rev 4; expanded third-party assurance controls | +| CSF v8 | c. 2017 | Significant structural update; added CMS ARS mapping; cloud-specific controls | +| CSF v9.x | 2018–2022 | Long-running stable version; widely deployed; 14 categories, 49 objectives, 156 specifications | +| CSF v9.6.2 | 2022 | Most recent v9.x maintenance release; widely used at time of v11 introduction | +| CSF v10 | 2022 | Transitional release; not widely deployed before v11 superseded it | +| CSF v11 | January 2023 | Current version; reorganised control structure; introduced/clarified e1/i1/r2 tiers; enhanced CMMC 2.0 and NIST SP 800-171 alignment | + +### CSF v9.x vs. CSF v11 +The transition from v9.x to v11 primarily affected: +- Internal organisation and numbering of some controls +- Enhanced prescriptive implementation guidance (telling organizations not just what to do + but how) +- Stronger alignment with CMMC 2.0, NIST SP 800-171, and NIST CSF 2.0 +- Clarification of i1 as a distinct "Defined Baseline" assessment (fixed 219 controls) +- Improved cross-framework attribution (each control cited against its source frameworks) + +Organizations that completed a v9.x assessment and are renewing can transition to v11 +requirements through normal renewal. Assessors can advise on specific control changes. + +--- + +## 4. HITRUST vs. HIPAA — Key Differences + +This is one of the most frequently asked questions about HITRUST. + +| Dimension | HIPAA | HITRUST CSF | +|-----------|-------|-------------| +| Type | Federal law and regulation | Private, voluntary framework | +| Enforcer | HHS Office for Civil Rights (OCR) | HITRUST Alliance (private) | +| Mandatory? | Yes — for Covered Entities and Business Associates | No — voluntary; often required by contracts | +| Prescriptiveness | Principle-based (does not specify specific technologies) | Prescriptive (specifies specific encryption standards, password lengths, etc.) | +| Certification | No formal certification exists (OCR enforces through audits and complaints) | Formal 1-year or 2-year certification letter from HITRUST | +| Scope | US Covered Entities and Business Associates | Any organization; primarily healthcare | +| Self-assessment | HIPAA risk analysis is required but no validated assessment mandated | Validated assessment by external assessor required | +| Audit trail | OCR audits and complaint investigations | MyCSF platform; HITRUST-endorsed certification | + +### Critical Point: HITRUST Does Not Equal Full HIPAA Compliance +HITRUST incorporates HIPAA Security Rule and Privacy Rule requirements. However: +- Certification covers the in-scope controls based on risk factors — not necessarily + every HIPAA requirement +- HIPAA obligations exist regardless of certification status +- HITRUST certification may be used as evidence of a robust security programme in the + event of an OCR investigation but does not provide legal immunity +- Organizations must still maintain BAAs, provide NPPs, respond to patient rights requests, + and meet all HIPAA obligations independent of their HITRUST certification + +--- + +## 5. HITRUST vs. Other Frameworks + +### HITRUST vs. SOC 2 + +| Dimension | HITRUST r2 | SOC 2 Type 2 | +|-----------|-----------|--------------| +| Standard setter | HITRUST Alliance | AICPA | +| Framework type | Prescriptive, certification-based | Principles-based, audit-based | +| Controls | Prescriptive specifications with maturity scoring | Organization-designed controls mapped to Trust Services Criteria | +| Report output | Certification letter | SOC 2 Type 2 Audit Report | +| Certification period | 2 years (r2) | 12-month period typically | +| Healthcare-specific | Strong HIPAA alignment | General (Privacy TSC not healthcare-specific) | +| Market recognition | Strong in healthcare | Strong across technology and services sectors | +| Customer interpretation | Pass/fail certification | Requires reading the report for nuance | +| Inheritance | Formal inheritance program | No standardised inheritance mechanism | + +### HITRUST vs. ISO 27001 + +| Dimension | HITRUST r2 | ISO 27001:2022 | +|-----------|-----------|----------------| +| Standard setter | HITRUST Alliance | ISO / IEC | +| Framework type | Prescriptive risk-based | Management system (principled; risk-based) | +| Certification body | HITRUST Alliance | Accredited ISO certification bodies | +| Healthcare specificity | High — HIPAA baked in | General; healthcare extensions via ISO 27799 | +| Prescriptiveness | High — specific technical requirements | Moderate — controls in Annex A but organisation defines implementation | +| Certificate | HITRUST certification letter | ISO 27001 certificate from accredited CB | +| Global recognition | Primarily US healthcare | Global | + +### HITRUST vs. NIST SP 800-53 + +| Dimension | HITRUST CSF | NIST SP 800-53 Rev 5 | +|-----------|--------------------|-----------------------| +| Type | Certifiable private framework | US government control catalogue | +| Mandatory? | Voluntary / contractual | Mandatory for US federal agencies; widely adopted by contractors | +| Certification | HITRUST certification letter | FedRAMP Authorization, StateRAMP, or self-attestation | +| HITRUST relationship | CSF maps to NIST SP 800-53 | Source framework mapped into CSF | +| Healthcare use | Primary healthcare market | Used by healthcare where CMS ARS applies | + +--- + +## 6. Cross-Framework Mapping + +HITRUST CSF controls are attributed to their source frameworks. For each HITRUST control +specification, HITRUST publishes the corresponding requirement(s) in the authoritative +source frameworks. + +### Sample Cross-Framework Mapping + +| HITRUST Control | HITRUST Category | HIPAA Ref | NIST 800-53 | ISO 27001:2022 | +|----------------|-----------------|-----------|-------------|----------------| +| 01.a.1 Access Control Policy | 01 — Access Control | 164.312(a)(1) | AC-1 | A.5.15 | +| 01.b.1 User Registration | 01 — Access Control | 164.312(a)(2)(i) | AC-2 | A.5.15, A.5.16 | +| 01.c.1 Privilege Management | 01 — Access Control | 164.312(a)(1) | AC-2(1), AC-6 | A.5.15, A.5.18 | +| 01.d.1 Password Management | 01 — Access Control | 164.312(d) | IA-5 | A.5.17 | +| 01.q.1 Remote Access | 01 — Access Control | 164.312(a)(2)(ii) | AC-17, IA-3 | A.6.7 | +| 03.b.1 Risk Assessment | 03 — Risk Management | 164.308(a)(1)(ii)(A) | RA-3 | Clause 6.1 | +| 09.j.1 Malware Controls | 09 — Ops Management | 164.308(a)(5)(ii)(B) | SI-3 | A.8.7 | +| 09.l.1 Backup | 09 — Ops Management | 164.308(a)(7)(ii)(A) | CP-9 | A.8.13 | +| 09.r.1 Audit Logging | 09 — Ops Management | 164.312(b) | AU-2, AU-3 | A.8.15 | +| 10.f.1 Cryptography Policy | 10 — SDLC | 164.312(a)(2)(iv) | SC-8, SC-28 | A.8.24 | +| 11.c.1 Incident Response | 11 — Incident Mgmt | 164.308(a)(6), 164.314(a)(2)(i)(C) | IR-1, IR-4 | A.5.24–A.5.28 | +| 12.c.1 Business Continuity | 12 — BCP | 164.308(a)(7) | CP-2, CP-4 | A.5.29–A.5.30 | +| 13.a.1 Privacy Notice | 13 — Privacy | 164.520 | PT-1 | N/A (privacy) | +| 13.f.1 Minimum Necessary | 13 — Privacy | 164.502(b) | PT-3 | N/A (privacy) | + +**Note:** These mappings are representative examples. The full cross-framework mapping is +maintained by HITRUST and published in the MyCSF platform and HITRUST CSF documentation. +Always refer to the current HITRUST CSF version for authoritative mappings. + +--- + +## 7. Who Needs HITRUST Certification + +HITRUST certification is not mandated by law, but it is increasingly required by contract +in the US healthcare ecosystem. + +### Organizations That Commonly Need HITRUST Certification + +**Healthcare Providers and Health Systems** +- Hospital systems and integrated delivery networks +- Physician groups and clinics +- Specialty care providers with significant electronic health record (EHR) usage +- Home health and long-term care organizations + +**Health Plans and Payers** +- Commercial health insurers +- Managed care organizations +- Self-insured employer health plans (where they act as plan administrators and process ePHI) +- Medicare Advantage plans + +**Business Associates** +- Health IT vendors (EHR companies, health information exchanges) +- Revenue cycle management companies +- Healthcare analytics and data companies +- Cloud service providers processing ePHI +- Medical billing and coding companies +- IT services providers with access to ePHI + +**Why Organizations Pursue HITRUST Certification** +1. **Customer requirement**: Largest health plans and hospital systems increasingly require + their vendors to hold HITRUST certification (commonly r2) as a condition of doing business +2. **Competitive differentiation**: HITRUST certification differentiates vendors in a + competitive healthcare market +3. **Audit fatigue reduction**: A HITRUST certification letter can satisfy multiple security + questionnaires simultaneously +4. **Internal programme improvement**: The assessment process itself drives security + programme maturity +5. **Regulatory alignment**: Demonstrates comprehensive HIPAA security controls implementation + +### Organizations That May Not Need HITRUST +- Organizations outsidethehealthcare industry with no HIPAA obligations and no customer + requirements for HITRUST (may find SOC 2 or ISO 27001 more appropriate) +- Very small providers with minimal electronic data processing (may find HIPAA risk analysis + sufficient without full HITRUST certification) +- Organizations where the cost of certification outweighs the business benefit + +--- + +## 8. HITRUST and Shared Compliance + +### Using HITRUST to Satisfy Multiple Frameworks + +Because HITRUST CSF harmonises multiple frameworks, a robust HITRUST r2 certification +generally provides evidence relevant to compliance with: +- HIPAA Security Rule — Strong coverage; HITRUST CSF was built around HIPAA requirements +- SOC 2 Trust Services Criteria — Significant overlap, particularly Security (CC) criteria +- ISO 27001 — Meaningful overlap in technical controls; governance approach differs +- NIST CSF — Strong functional mapping; HITRUST has published official NIST CSF mappings +- PCI DSS — If PCI scoping factors are included; specific PCI controls may supplement + +### What HITRUST Certification Supports (but Does Not Replace) +- HIPAA risk analysis: OCR requires a specific, documented risk analysis; HITRUST Category 03 + covers risk management broadly but the organisation must maintain a HIPAA-specific risk + analysis document +- Business Associate Agreements: BAAs are a legal requirement under HIPAA; the existence of + a BAA is not replaced by HITRUST certification +- Breach notification obligations: HITRUST certification does not alter the legal obligation + to notify affected individuals, HHS, and media under HIPAA's Breach Notification Rule + +--- + +## 9. Key HITRUST Terminology + +| Term | Definition | +|------|-----------| +| **HITRUST Alliance** | Private organization that owns and maintains the HITRUST CSF and the Assurance Program | +| **HITRUST CSF** | Common Security Framework — the framework document containing all control categories, objectives, and specifications | +| **MyCSF** | HITRUST's online assessment management portal (myCSF.net) | +| **e1** | Entry-Level assessment; 44 fixed control requirements; 1-year certification | +| **i1** | Implemented, 1-Year assessment; 219 Defined Baseline controls; 1-year certification | +| **r2** | Risk-Based, 2-Year assessment; variable risk-tailored controls; 2-year certification | +| **AEA** | Authorized External Assessor — an organization approved by HITRUST to conduct validated assessments | +| **CAP** | Corrective Action Plan — a documented remediation plan for a non-certifiable or near-certifiable finding | +| **Certification Letter** | The official document issued by HITRUST certifying the organization's compliance status, scope, and certification period | +| **Control Category** | One of the 14 high-level groupings of controls in HITRUST CSF v9.x (00–13) | +| **Control Objective** | Sub-division within a control category (e.g., 01.a — Access Control Policy) | +| **Control Specification** | The specific prescriptive requirement (e.g., 01.a.1) | +| **Defined Baseline (dB)** | The fixed set of 219 controls used for i1 assessment in CSF v11 | +| **Inheritance** | A mechanism where an organization receives credit for controls that are the responsibility of a certified third-party service provider | +| **Inheritee** | The HITRUST-certified organization whose controls are being inherited | +| **Inheritor** | The organization that benefits from inheriting controls from the Inheritee | +| **Maturity Level** | One of the five levels (Policy, Procedure, Implemented, Measured, Managed) at which each control is assessed | +| **Non-Certifiable Finding** | A control scoring below 62 out of 100; a CAP is required before certification can proceed | +| **Near-Certifiable Finding** | A control scoring 62–74; a CAP is recommended; does not block certification | +| **Certifiable** | A control scoring 75 or above; no CAP required | +| **Risk Factor** | An organizational characteristic (e.g., cloud usage, large record volume) that activates additional r2 control requirements | +| **Scoping Questionnaire** | The MyCSF questionnaire that determines which r2 controls apply to a specific organization | +| **Validated Assessment** | The formal HITRUST assessment conducted with an AEA in which the assessor validates and scores the organization's responses | +| **Readiness Assessment** | An optional pre-assessment activity (gap assessment) to identify and address weaknesses before the validated assessment | +| **Interim Assessment** | A required mid-certification assessment at 12 months for r2 certifications | +| **Shared Responsibility Matrix** | Documentation that maps inherited vs. customer-owned controls in third-party service arrangements | + +--- + +## 10. Disclaimer and Limitations + +This reference document is maintained for use within the HITRUST skill context and reflects +information from official HITRUST published materials as of the knowledge cutoff. + +**Important limitations:** +- HITRUST CSF requirements, assessment processes, and scoring thresholds are updated by + HITRUST Alliance and may change. Always consult the current published version of the + HITRUST CSF and the MyCSF platform for authoritative requirements. +- This document does not constitute official HITRUST guidance. For authoritative guidance, + consult: HITRUST Alliance (hitrustalliance.net), published HITRUST CSF documentation, + and a HITRUST Authorized External Assessor. +- Control specification numbers, names, and details are based on the HITRUST CSF v9.x + structure and may differ in CSF v11. Verify against the current MyCSF framework for active + assessments. +- HITRUST certification does not constitute legal advice on regulatory compliance. + Organizations must consult qualified legal counsel for HIPAA compliance determinations. diff --git a/plugins/hitrust/skills/hitrust/references/hitrust-scoping-factors.md b/plugins/hitrust/skills/hitrust/references/hitrust-scoping-factors.md new file mode 100644 index 0000000..49bc3ce --- /dev/null +++ b/plugins/hitrust/skills/hitrust/references/hitrust-scoping-factors.md @@ -0,0 +1,402 @@ +# HITRUST Scoping Factors Reference +## r2 Assessment Scoping, Risk Factors, Inheritance, and Control Selection + +--- + +## Table of Contents +1. [Overview of r2 Scoping](#1-overview-of-r2-scoping) +2. [HITRUST Risk Factors](#2-hitrust-risk-factors) +3. [Scoping Questionnaire Categories](#3-scoping-questionnaire-categories) +4. [Organization Type Factors](#4-organization-type-factors) +5. [Data Volume and Sensitivity Factors](#5-data-volume-and-sensitivity-factors) +6. [Technology and Infrastructure Factors](#6-technology-and-infrastructure-factors) +7. [Regulatory and Compliance Factors](#7-regulatory-and-compliance-factors) +8. [HITRUST Inheritance Program](#8-hitrust-inheritance-program) +9. [System Scoping — What is In-Scope](#9-system-scoping--what-is-in-scope) +10. [Scoping Decisions and Documentation](#10-scoping-decisions-and-documentation) + +--- + +## 1. Overview of r2 Scoping + +The r2 (Risk-Based 2-Year) assessment is specifically designed to be risk-tailored. Unlike +the e1 and i1 assessments, which use a fixed set of controls for all organizations, the r2 +assessment determines which of the 156 HITRUST CSF control specifications apply to a given +organization based on its unique risk profile. + +### How Scoping Works +1. The organization and assessor complete the scoping questionnaire in MyCSF before beginning + the assessment +2. HITRUST uses the questionnaire responses to generate the specific set of in-scope control + requirements for that organization +3. Each risk factor activates additional control specifications relevant to that factor +4. The final in-scope control set is locked before the assessment begins + +### Base Control Set +All r2 assessments begin with a base set of control specifications that apply to every +organization regardless of risk factors. These cover fundamental security practices across +all 14 control categories. The base set is non-negotiable. + +### Additional Controls from Risk Factors +Organizations with additional risk factors (e.g., internet-facing systems, cloud infrastructure, +large PHI volumes, specific regulatory requirements) will have additional control specifications +added to their base set. + +--- + +## 2. HITRUST Risk Factors + +HITRUST organises its risk factors into several groups. Each risk factor corresponds to a set +of additional control specifications that become required when that factor is present. + +Risk factors operate cumulatively — if multiple factors apply, all their associated +controls are added to the in-scope set, with no duplication. + +### Risk Factor Categories + +| Factor Category | Description | Controls Impact | +|----------------|-------------|-----------------| +| Organization type | CE, BA, sub-BA, payer, provider, etc. | Activates HIPAA-specific controls | +| Record volume | Number of individual records in the system | Higher volumes add proportionally more controls | +| Business programmes | Services offered (billing, telecoms, email, etc.) | Service-specific controls | +| Regulatory requirements | Applicable regulations beyond HIPAA | Activates regulation-specific controls | +| Technology infrastructure | Cloud, mobile, web apps, remote access, BYOD | Technology-specific controls | +| Data sensitivity | Types of data (ePHI, PII, payment data, financial) | Data-type-specific controls | +| Geographic operations | Multi-state, international | Jurisdiction-specific controls | + +--- + +## 3. Scoping Questionnaire Categories + +The MyCSF scoping questionnaire covers the following areas. Organizations must complete all +sections accurately — scoping responses are reviewed by the assessor and by HITRUST. + +### Section A — Organization Profile +- Organization type (healthcare provider, health plan, healthcare clearinghouse, business + associate, sub-business associate, non-healthcare) +- Primary business activities +- Number of employees +- Number of covered locations / facilities + +### Section B — Data Holdings +- Types of personally identifiable information (PII) held +- Whether ePHI is stored, processed, or transmitted +- Whether payment card data (CHD/SAD) is stored, processed, or transmitted +- Number of individuals whose records are held +- Physical vs. electronic records breakdown + +### Section C — Business Activities / Services +- Whether the organization provides billing services, claims processing, revenue cycle +- Whether the organization operates a call centre +- Whether the organization provides telemedicine or telehealth services +- Whether the organization operates a pharmacy or conducts pharmaceutical research +- Whether the organization provides laboratory services + +### Section D — Technology Infrastructure +- Whether the organization uses public cloud infrastructure (IaaS, PaaS) +- Whether the organization uses SaaS applications for processing of sensitive data +- Whether the organization has internet-facing applications or portals +- Whether employees use mobile devices (corporate-issued or BYOD) to access sensitive data +- Whether remote access to internal systems is provided to employees or third parties +- Whether the organization uses point-of-sale (POS) systems +- Whether wireless networks are in use + +### Section E — Regulatory Requirements +- HIPAA / HITECH applicability +- PCI DSS applicability +- CMS ARS applicability +- State-specific requirements (e.g., California CMIA, Texas HIPAA equivalent) +- GDPR or other international privacy law applicability +- FTC oversight +- FERPA (educational records) +- 42 CFR Part 2 (substance use disorder records) + +### Section F — Third Parties and Vendors +- Whether the organization relies on third-party service providers with access to sensitive data +- Number of business associates or subcontractors with access to ePHI +- Whether third parties have network access or remote access to internal systems + +--- + +## 4. Organization Type Factors + +The organization type is one of the most significant scoping factors. Different organization +types have different regulatory obligations and risk profiles. + +| Organization Type | HITRUST Classification | Regulatory Context | +|------------------|----------------------|-------------------| +| Healthcare Provider | Covered Entity (CE) | HIPAA Privacy Rule, Security Rule, Breach Notification Rule | +| Health Plan / Payer | Covered Entity (CE) | HIPAA Privacy Rule, Security Rule, Breach Notification Rule | +| Healthcare Clearinghouse | Covered Entity (CE) | HIPAA Privacy Rule, Security Rule | +| Business Associate (direct) | Business Associate (BA) | HIPAA Security Rule in full; Privacy Rule via BAA | +| Sub-Business Associate | Sub-BA | HIPAA obligations flow through BA agreement | +| Non-Healthcare (pursuing HITRUST) | Other | Framework harmonisation and voluntary adoption | + +### Healthcare Provider +- All Privacy Rule controls relevant (Category 13 — Privacy Practices in full) +- Patient rights obligations (access, amendment, accounting of disclosures, NPP) +- Minimum necessary standard applies to all disclosures + +### Health Plan / Payer +- Full Privacy Rule and Security Rule applicability +- Marketing and fundraising restrictions +- Employer plan exceptions may apply + +### Business Associate +- Security Rule applies in full +- Portions of the Privacy Rule apply via BAA terms +- Must flow down obligations to sub-BAs +- Must report breaches and security incidents to the Covered Entity within contract terms + (typically 60 days; HITRUST recommends and best practice is 30 days or sooner) + +--- + +## 5. Data Volume and Sensitivity Factors + +### Record Volume Tiers + +HITRUST uses approximate record volume thresholds to calibrate the control scope. Higher +volumes generally correspond to more prescriptive control requirements. + +| Volume Tier | Approximate Range | Impact on Controls | +|------------|-------------------|--------------------| +| Minimal | Fewer than 25,000 individuals | Base control set | +| Small | 25,000 – 100,000 individuals | Incremental controls for monitoring and access | +| Medium | 100,000 – 500,000 individuals | Additional controls for data protection and third-party management | +| Large | 500,000 – 2,000,000 individuals | Broader controls across all categories | +| Very Large | More than 2,000,000 individuals | Maximum scope; all relevant controls activated | + +**Note:** Record volume thresholds in the actual HITRUST scoping questionnaire should be +confirmed in MyCSF. HITRUST may update these thresholds between framework versions. + +### Sensitive Data Types + +The presence of specific data types activates corresponding control requirements: + +| Data Type | Activated Control Areas | +|-----------|------------------------| +| ePHI (electronic Protected Health Information) | Category 13 (Privacy); strengthened Category 01 and 09 controls | +| PII (Personally Identifiable Information) | Category 06.d; privacy breach procedures | +| Payment Card Data (PAN / SAD) | PCI DSS-aligned controls in Categories 01, 09, 10 | +| Financial account information | Additional access and transfer controls | +| Substance use disorder records (42 CFR Part 2) | Heightened prohibition on re-disclosure | +| Psychotherapy notes | Additional access restriction controls | +| Genetic information (GINA) | Additional privacy protections | +| Records of minors | Parental access and consent controls | + +--- + +## 6. Technology and Infrastructure Factors + +Technology risk factors add specific technical controls to the r2 scope. + +### Cloud Infrastructure (IaaS/PaaS) + +If the organization uses public cloud infrastructure (e.g., AWS, Microsoft Azure, Google Cloud) +to store, process, or transmit sensitive data, the following additional controls are commonly +activated: + +- Cloud configuration management and hardening (Category 09) +- Cloud-specific access control (multi-factor authentication, IAM policies) (Category 01) +- Virtual network boundary protection (Category 01.i) +- Cloud asset inventory (Category 07) +- Key management for cloud encryption (Category 10.g) +- Data residency and sovereignty considerations (Category 06) +- Shared responsibility clarity and documentation + +**Inheritance consideration:** If a cloud provider (e.g., AWS) holds a HITRUST certification +covering the infrastructure services used, the organization may be able to inherit applicable +controls. See Section 8 — Inheritance. + +### SaaS Applications + +If the organization uses SaaS applications to process sensitive data: +- Vendor security review requirements (Category 05.k) +- BAA or equivalent agreement requirements (if SaaS vendor processes ePHI) +- Third-party access and connection controls (Category 01.q) +- SaaS configuration management + +### Internet-Facing Applications and Web Portals + +If the organization operates internet-facing systems (patient portals, web apps, APIs): +- Web application security controls (Category 10.b — input validation, OWASP Top 10 mitigations) +- External vulnerability scanning (Category 06.g, Category 10.h) +- WAF or equivalent controls for internet-facing applications +- API security controls (authentication, authorisation, rate limiting) +- Annual penetration testing requirement (minimum) + +### Mobile Devices + +If employees or contractors use mobile devices (corporate-issued or BYOD) to access +sensitive data: +- Mobile Device Management (MDM) requirements (Category 01.p) +- Remote wipe capability +- Mobile device encryption +- BYOD policy and acceptable use +- Application controls preventing data leakage from mobile applications + +### Remote Access + +If remote access to internal systems is provided: +- VPN or equivalent encrypted remote access (Category 01.q) +- Multi-factor authentication for remote access mandatory +- Remote session monitoring and logging +- Remote access usage policy + +### Wireless Networks + +If wireless networks are in use in locations where sensitive data is accessed: +- Wireless encryption (minimum WPA2 / WPA3) (Category 01.p) +- Rogue access point detection +- Separation of guest and corporate wireless networks +- Wireless access logging + +--- + +## 7. Regulatory and Compliance Factors + +Each regulatory requirement that applies to the organization may activate additional control +specifications or strengthen existing requirements. + +### HIPAA / HITECH +- Activates all relevant HIPAA Security Rule controls across Categories 01, 07, 09, 10 +- Activates all Privacy Practices controls (Category 13) +- Activates Breach Notification Rule requirements in Category 11 +- HITECH increases penalties and adds Meaningful Use requirements + +### PCI DSS +- If the organization stores, processes, or transmits payment card data +- Activates additional access control, encryption, and monitoring requirements +- Requires quarterly external vulnerability scans +- Requires annual penetration testing +- Requires network segmentation between PCI and non-PCI environments + +### CMS Acceptable Risk Safeguards (ARS) +- Applies to organizations processing Medicare, Medicaid, or other CMS data +- Activates NIST SP 800-53 alignment controls beyond standard HIPAA requirements +- Typically adds controls in Categories 01, 03, 06, and 09 + +### 42 CFR Part 2 (Substance Use Disorder Records) +- More restrictive than HIPAA for records relating to substance use disorder treatment +- Prohibits most re-disclosures without patient consent +- Activates heightened access restriction and disclosure controls + +### State Privacy Laws +- Various states (e.g., California, New York, Texas) have enacted health privacy laws that + may be more stringent than HIPAA in certain respects +- California Confidentiality of Medical Information Act (CMIA) may activate additional + controls beyond HIPAA + +--- + +## 8. HITRUST Inheritance Program + +### What is Inheritance? +HITRUST inheritance allows an organization (the "Inheritor") to inherit responsibility for +certain HITRUST controls from a third-party service provider (the "Inheritee") that is +currently HITRUST certified. This recognizes that in cloud and outsourced service arrangements, +the service provider bears responsibility for some controls. + +### How Inheritance Works +1. The Inheritee must hold a current HITRUST certification letter that covers the controls + being inherited +2. The Inheritee provides their HITRUST certification letter to the Inheritor +3. The Inheritor documents the inherited controls in MyCSF and links the certification letter + as evidence +4. The assessor validates the inheritance relationship: + - Confirms the Inheritee has a valid, unexpired certification + - Confirms the certification scope covers the controls being inherited + - Confirms the contractual relationship (e.g., BAA or service agreement) is in place +5. Inherited controls receive credit toward the Inheritor's assessment + +### Inheritance Limitations +- Inheritance is only available for controls that the service provider is operationally + responsible for +- Controls that are the customer's responsibility cannot be inherited (e.g., customer's + own access control policy) +- Partial inheritance is possible where the provider controls some but not all aspects + of a requirement +- The Inheritor remains responsible for ensuring the service agreement addresses security + obligations + +### Common Inheritance Scenarios + +| Inheritee | What Can Typically Be Inherited | +|-----------|--------------------------------| +| AWS (if HITRUST certified for scope) | Physical security (Category 08), data centre environmental controls (Category 08.d-h), hardware maintenance (08.j) | +| Microsoft Azure (if HITRUST certified) | Physical security, network infrastructure controls, core IaaS controls | +| Epic (EHR vendor, if certified) | Application-level controls specific to Epic's SaaS scope | +| Hosting / colocation provider (if certified) | Data centre physical security, power, HVAC | + +### Shared Responsibility Matrix Format + +When documenting inheritance: + +``` +| Control ID | Control Title | Responsibility | Inheritance Source | Certificate ID | Expiry | +|-----------|--------------|---------------|-------------------|---------------|--------| +| 08.a.1 | Physical Security Perimeter | Fully Inherited | AWS-HITRUST | [Cert #] | [Date] | +| 08.b.1 | Physical Entry Controls | Fully Inherited | AWS-HITRUST | [Cert #] | [Date] | +| 01.a.1 | Access Control Policy | Customer | N/A | N/A | N/A | +| 09.l.1 | Information Backup | Shared | AWS (infrastructure); Customer (data backup config) | [Cert #] | [Date] | +``` + +--- + +## 9. System Scoping — What is In-Scope + +### In-Scope System Definition + +For a HITRUST assessment, the "system" or "environment" in scope must be clearly defined. +This is analogous to the "system boundary" in other frameworks (e.g., FedRAMP System +Security Plan boundary). + +**Systems that are typically in scope:** +- Systems that store, process, or transmit ePHI or other sensitive data being assessed +- Systems that directly support, protect, or manage in-scope systems (security tools, + identity providers, network infrastructure connecting in-scope systems) +- Third-party systems with direct access to in-scope data + +**Systems that may be out of scope (with documented justification):** +- Systems with no access to or impact on the sensitive data environment +- Fully isolated business units or subsidiaries with separate data environments +- Systems for which controls are fully inherited from a certified third party + +### Scope Documentation +The scope of the assessment must be documented and agreed upon between the organization +and the assessor before the assessment begins. Scope documentation must include: +- Description of the system or environment +- Boundaries (logical and physical) +- Data types in scope +- Locations in scope +- Key systems and applications +- Third-party components + +--- + +## 10. Scoping Decisions and Documentation + +### Common Scoping Mistakes to Avoid + +| Mistake | Risk | Mitigation | +|---------|------|-----------| +| Excluding systems that have direct connectivity to in-scope data | Assessor may expand scope; controls gaps may exist | Map all data flows before finalizing scope | +| Over-scoping to include systems with no access to sensitive data | Increases cost and effort unnecessarily | Document scope exclusions with rationale | +| Inaccurately answering scoping questionnaire | HITRUST may reject or question the assessment | Complete questionnaire with the assessor; document rationale | +| Not considering cloud infrastructure | Cloud controls may be absent | Inventory all cloud services in use before scoping | +| Ignoring sub-processors | Third-party chain creates unaccounted risk | Map all third parties with access to in-scope data | + +### Scope Change During Assessment +If the scope must change during the assessment (e.g., a new system is identified as in-scope): +- Notify the assessor immediately +- Assessor and organization must agree on how to handle the change +- Significant scope changes may require restarting certain assessment activities +- HITRUST should be informed of material scope changes + +### Scoping for Inherited Controls +Controls that are fully inherited do not need to be actively assessed by the organization, but: +- The inheritance must be documented in MyCSF +- The certification letter from the Inheritee must be available and current +- The assessor must validate the inheritance +- Missing or expired inheritance documentation will result in the controls falling to + the organization's own assessment scope diff --git a/plugins/iso13485/.claude-plugin/plugin.json b/plugins/iso13485/.claude-plugin/plugin.json new file mode 100644 index 0000000..afb1976 --- /dev/null +++ b/plugins/iso13485/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "iso13485", + "description": "ISO 13485:2016 medical device quality management system advisor — gap analysis, design control guidance, regulatory mapping (EU MDR, FDA 21 CFR Part 820), document generation, nonconformance management, and certification readiness for medical device manufacturers and suppliers.", + "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": [ + "iso13485", + "medical-devices", + "qms", + "quality-management", + "mdr", + "fda-820", + "design-controls", + "grc", + "compliance", + "regulatory" + ] +} diff --git a/plugins/iso13485/skills/iso13485/SKILL.md b/plugins/iso13485/skills/iso13485/SKILL.md new file mode 100644 index 0000000..d1a72e3 --- /dev/null +++ b/plugins/iso13485/skills/iso13485/SKILL.md @@ -0,0 +1,829 @@ +--- +name: iso13485 +description: > + Expert ISO 13485:2016 medical device quality management system (QMS) advisor. + Use this skill whenever a user asks about ISO 13485, medical device QMS, medical + device compliance, or any of the following: gap analysis against ISO 13485:2016, + design and development controls, risk management for medical devices, design history + file (DHF), device master record (DMR), device history record (DHR), technical file, + medical device file, regulatory submissions, FDA 21 CFR Part 820, EU MDR 2017/745, + EU IVDR 2017/746, CE marking, 510(k), PMA, CAPA, nonconforming product, complaint + handling, post-market surveillance, vigilance reporting, sterile medical devices, + implantable devices, supplier controls for medical devices, UDI, traceability, + process validation, sterilisation validation, notified body audit preparation, + ISO 13485 certification readiness, or any quality management topic specific to the + medical device industry. Trigger even if the user does not say "skill" — any + ISO 13485 or medical device QMS question should use this skill. +--- + +# ISO 13485:2016 Medical Device QMS Skill + +You are an expert ISO 13485:2016 Lead Auditor and medical device Quality Management System (QMS) implementation consultant. You assist **medical device manufacturers, component suppliers, contract manufacturers, authorized representatives, importers, and distributors** with implementing, maintaining, and certifying a QMS that satisfies ISO 13485:2016 and associated regulatory requirements. + +You have authoritative knowledge of: +- ISO 13485:2016 full clause and sub-clause requirements +- Regulatory alignments: EU MDR 2017/745, EU IVDR 2017/746, FDA 21 CFR Part 820 (QSR / QMSR), Health Canada SOR/98-282, TGA (Australia), MHLW (Japan), NMPA (China) +- Supporting standards: ISO 14971:2019 (risk management), IEC 62304 (software lifecycle), IEC 62366 (usability), ISO 14155 (clinical investigation), ISO 11135/11137/11607 (sterilisation) +- MDSAP (Medical Device Single Audit Program) audit approach +- IMDRF guidelines and frameworks + +--- + +## How to Respond + +Always clarify the organisation's role in the supply chain if not stated. Roles with different clause applicability: +- **Manufacturer** (designs and manufactures devices) — all clauses apply +- **Contract manufacturer** (manufactures to customer spec, no design authority) — Clause 7.3 may not apply +- **Supplier / component manufacturer** — typically implements a subset relevant to supplied items +- **Authorised representative / importer / distributor** — Clause 7.5 (distribution/storage) and 8.2.2 (complaints) apply; other clauses as agreed + +Match output to task type: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Clause \| Requirement \| Status (Red/Amber/Green) \| Evidence Needed \| Gap Notes | +| Policy / procedure generation | Full structured document with document control block | +| Clause guidance | Purpose → What to implement → Evidence required → Audit tips → Common pitfalls | +| Design control guidance | Phase-by-phase DHF requirements with inputs, outputs, reviews | +| CAPA / nonconformance | Structured investigation template | +| Risk management | ISO 14971 aligned risk register table | +| Regulatory mapping | Cross-reference table: ISO 13485 clause ↔ regulatory requirement | +| Certification readiness | Checklist with RAG status and evidence references | +| General question | Clear, concise prose with clause citations | + +Always cite the specific clause (e.g., Clause 7.3.3, 8.2.2) in all outputs. + +--- + +## Standard Overview + +**ISO 13485:2016** was published on **1 March 2016**, replacing ISO 13485:2003. It specifies requirements for a quality management system where an organisation needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and applicable regulatory requirements. + +> ISO 13485:2016 does NOT follow the ISO High Level Structure (Annex SL). It retains the structure of ISO 9001:2008 (Clauses 1–8) with medical device-specific additions and modifications. It is therefore NOT structurally interchangeable with ISO 9001:2015 or ISO 27001:2022. + +### Who It Applies To + +ISO 13485:2016 explicitly applies to organisations involved in one or more stages of the medical device lifecycle: +- Design and development of medical devices +- Production (including manufacture, assembly, packaging, labelling) +- Storage and distribution +- Installation and servicing +- Decommissioning and disposal of medical devices +- Design, development, and provision of associated activities (sterilisation services, clinical services, distribution services) + +### Key Differences from ISO 9001:2008 / ISO 9001:2015 + +| Topic | ISO 9001 | ISO 13485:2016 | +|-------|---------|----------------| +| Structure | HLS (2015) or 8-clause (2008) | 8-clause (mirrors 9001:2008) | +| Customer satisfaction | Explicit improvement goal | Maintained but less emphasis — regulatory compliance primary | +| Continual improvement | Explicit requirement | "Maintain" effectiveness of QMS — not necessarily "continual improvement" | +| Risk-based thinking | Broadly applies | Specific to product safety and performance; links to ISO 14971 | +| Medical device file | Not applicable | Mandatory (Clause 4.2.3) | +| Design controls | Clause 7.3 | Clause 7.3 with additional sub-clauses (transfer, DHF) | +| Sterile device requirements | Not applicable | Clauses 7.5.2, 7.5.5, 7.5.7 | +| Implantable device requirements | Not applicable | Enhanced traceability (7.5.9), records retention | +| Regulatory authority reporting | Not applicable | Clause 8.2.3 — mandatory vigilance reporting obligation | +| Feedback | 8.2.1 | Formal feedback system required; feeds post-market surveillance | +| Complaint handling | 8.2.2 (lighter) | 8.2.2 — detailed complaint procedure; records mandatory | + +--- + +## Clause Structure — Full Breakdown + +### Clause 4 — Quality Management System + +#### 4.1 General Requirements +The organisation shall establish, document, implement, and maintain a QMS and maintain its effectiveness. + +Key requirements: +- Identify QMS processes, their sequence, and interactions +- Determine criteria and methods to control processes +- Ensure availability of resources and information +- Monitor, measure (where applicable), and analyse processes +- Implement actions to achieve planned results and maintain effectiveness +- **If outsourced processes affect product conformity, they must be controlled** +- The type and extent of outsourced process control must be documented + +#### 4.2 Documentation Requirements + +**4.2.1 General** — The QMS documentation shall include: +- Documented quality policy and quality objectives +- Quality manual (see 4.2.2) +- Documented procedures required by the standard (mandatory procedures: 13 explicit) +- Documents needed to plan, operate, and control processes +- Records required by the standard +- Any additional documentation required by regulatory authorities in the markets where the device is sold + +**4.2.2 Quality Manual** — The quality manual shall include: +- Scope of QMS, including any exclusions and justification +- Documented procedures or reference to them +- Description of interaction between QMS processes + +**4.2.3 Medical Device File** — For each medical device type or family, a file shall be maintained or referenced containing documents to demonstrate conformity to requirements. May include: +- Device description and intended use +- Labelling (including instructions for use) +- Design and development files (DHF / technical file) +- Specifications for production, packaging, storage, handling +- Measurement and monitoring procedures +- Traceability records +- Installation and servicing procedures (if applicable) + +**4.2.4 Control of Documents** — Documented procedure required. Controls shall provide for: +- Document approval before issue +- Document review, update, and re-approval +- Changes and current revision status identified +- Relevant versions at point of use +- Documents remain legible and identifiable +- External documents identified and controlled +- Obsolete documents marked and prevented from unintended use +- Retention period of documents specified in local regulatory requirements noted + +**4.2.5 Control of Records** — Documented procedure required. Records shall: +- Remain legible, readily identifiable, and retrievable +- Be protected against deterioration, damage, or loss +- Retention period: minimum design lifetime of device plus 2 years (or as required by regulation — typically at least 5 years for non-implantable, 15 years for implantable devices in EU) +- If electronic, ensure data integrity and access controls + +--- + +### Clause 5 — Management Responsibility + +#### 5.1 Management Commitment +Top management shall provide evidence of commitment by: +- Communicating regulatory and customer requirements +- Establishing quality policy +- Establishing quality objectives +- Conducting management reviews +- Ensuring availability of resources + +#### 5.2 Customer Focus +Top management shall ensure customer requirements are determined and met with the aim of enhancing customer satisfaction, subject to regulatory requirements. + +#### 5.3 Quality Policy +Top management shall establish a quality policy that: +- Is appropriate to the purpose of the organisation +- Includes a commitment to comply with requirements and maintain QMS effectiveness +- Provides framework for establishing and reviewing quality objectives +- Is communicated and understood within the organisation +- Is reviewed for continuing suitability + +#### 5.4 Planning + +**5.4.1 Quality Objectives** — Top management shall ensure measurable quality objectives are established at relevant functions and levels. Quality objectives shall be consistent with the quality policy. + +**5.4.2 QMS Planning** — Top management shall ensure planning maintains QMS integrity when changes are implemented. + +#### 5.5 Responsibility, Authority, and Communication + +**5.5.1 Responsibility and Authority** — Top management shall define and communicate roles, responsibilities, and authorities. Personnel performing quality-affecting activities shall have independence and authority. + +**5.5.2 Management Representative** — Top management shall designate a member (may be multi-role) who shall: +- Ensure processes are established, implemented, and maintained +- Report to top management on QMS performance and need for improvement +- Promote awareness of regulatory and customer requirements throughout the organisation + +**5.5.3 Internal Communication** — Top management shall establish appropriate communication processes regarding QMS effectiveness. + +#### 5.6 Management Review + +**5.6.1 General** — Top management shall review the QMS at planned intervals (typically annually or more frequently if regulatory requirements or quality trends warrant). Records of management reviews shall be maintained. + +**5.6.2 Review Input** — Input shall include: +- Results of audits (internal and external/regulatory) +- Customer feedback +- Process performance and product conformity +- Status of preventive and corrective actions +- Follow-up actions from previous management reviews +- Changes affecting the QMS (regulatory, product, process) +- Recommendations for improvement +- New or revised regulatory requirements +- Applicable new or revised standards + +**5.6.3 Review Output** — Output shall include decisions and actions related to: +- Improvement needed to maintain the effectiveness of the QMS +- Improvement of product related to customer and regulatory requirements +- Resource needs + +--- + +### Clause 6 — Resource Management + +#### 6.1 Provision of Resources +Determine and provide resources needed to implement and maintain the QMS and maintain its effectiveness, and meet regulatory and customer requirements. + +#### 6.2 Human Resources +Personnel performing work affecting product quality shall be competent on the basis of appropriate education, training, skills, and experience. The organisation shall: +- Determine necessary competence +- Provide training or take other actions to achieve necessary competence +- Evaluate effectiveness of training/actions taken +- Ensure awareness of the relevance and importance of activities and how they contribute to quality objectives +- Maintain records of education, training, skills, and experience + +#### 6.3 Infrastructure +Determine, provide, and maintain infrastructure including buildings, workspace, process equipment (hardware and software), and supporting services (transport, communication, IT). Maintenance activities and records required. + +#### 6.4 Work Environment and Contamination Control + +**6.4.1 Work Environment** — Determine and manage work environment needed for product conformity. Where environmental conditions affect product quality, the organisation shall document requirements and monitor/control/record these conditions (temperature, humidity, cleanliness levels, sterility, particulate counts). + +**6.4.2 Contamination Control** — Document arrangements for controlling contamination of product or work environment. For sterile devices: establish documented requirements for cleanliness of product during production (if not cleaned by organisation in manufacturing), maintenance of cleanliness, and control of contaminated or potentially contaminated product. + +--- + +### Clause 7 — Product Realization + +#### 7.1 Planning of Product Realization +Plan and develop processes needed for product realization. Planning shall include: +- Quality objectives, requirements for product +- Process, documents, and resources specific to the product +- Required verification, validation, monitoring, measurement, inspection, and test activities +- Records to provide evidence of conformity +- Traceability requirements (risk management outputs per ISO 14971 must be referenced) + +**Risk management** — Document requirements for risk management consistent with ISO 14971 (or equivalent regulatory requirement). Records of risk management activities shall be maintained. + +#### 7.2 Customer-Related Processes + +**7.2.1 Determination of Requirements Related to Product** — Determine: +- Customer requirements (including delivery and post-delivery requirements) +- Requirements not stated by customer but necessary for intended or known use +- Statutory and regulatory requirements applicable to the product +- Additional requirements determined by the organisation (e.g., standards) + +**7.2.2 Review of Requirements Related to Product** — Review before committing to supply product shall ensure: +- Product requirements are defined and documented +- Contract/order requirements are resolved where different from previous expressions +- Organisation has ability to meet defined requirements +- Records of review results and actions arising maintained + +**7.2.3 Customer Communication** — Determine and implement arrangements for product information, enquiries, orders including amendments, and customer feedback including complaints. + +#### 7.3 Design and Development + +> Note: An organisation may exclude Clause 7.3 ONLY if design and development activities are not performed (e.g., a contract manufacturer with no design authority). Exclusions must be documented and justified in the quality manual. Regulatory authorities may not permit this exclusion depending on jurisdiction. + +**7.3.1 General** — The organisation shall document procedures for design and development. + +**7.3.2 Design and Development Planning** — Plan and control design and development. Planning shall document: +- Design and development stages +- Review, verification, and validation activities at each stage +- Responsibilities and authorities for design and development +- Methods to maintain traceability of design and development outputs to inputs +- Required resources including necessary competence of personnel + +Planning shall be updated as design and development evolves. + +**7.3.3 Design and Development Inputs** — Inputs relating to product requirements shall include: +- Functional, performance, usability, and safety requirements (per ISO 62366) +- Applicable regulatory requirements and standards +- Risk management outputs (hazards, risk controls per ISO 14971) +- Information from previous similar designs (if applicable) +- Other requirements essential for design and development +- Inputs shall be reviewed for adequacy. Incomplete, ambiguous, or conflicting requirements resolved +- Records of design and development inputs maintained + +**7.3.4 Design and Development Outputs** — Outputs shall: +- Meet design and development input requirements +- Provide appropriate information for purchasing, production, and service provision +- Contain or reference product acceptance criteria +- Specify characteristics essential for safe and proper use of product +- Records of design and development outputs maintained + +**7.3.5 Design and Development Review** — Systematic reviews at suitable stages shall: +- Evaluate ability to meet requirements +- Identify problems and propose actions +- Include representatives of relevant functions concerned by the stage reviewed +- Include risk management results (ISO 14971 outputs) +- Records maintained including results of review and participants + +**7.3.6 Design and Development Verification** — Verification performed per planned arrangements to ensure outputs meet input requirements. Records of verification results including identification of product under examination, methods used, results, and conclusions maintained. + +**7.3.7 Design and Development Validation** — Validation performed per planned arrangements to ensure resulting product meets the requirements for the specified application or intended use. Where practicable, validation shall be completed prior to delivery or implementation. Records maintained including results, identification of product, methods, results, and conclusions. +- For medical devices: clinical evaluation (per EU MDR Art. 61 or FDA IDE/PMA/510(k)) must align with design validation records. + +**7.3.8 Design and Development Transfer** — The organisation shall document procedures for transferring design and development outputs to manufacturing. Ensure design output is verified as suitable for manufacturing before becoming routine production. Records of transfer results maintained. + +**7.3.9 Control of Design and Development Changes** — Changes shall be: +- Identified and records maintained +- Reviewed, verified, validated (as appropriate), and approved before implementation +- Review shall include evaluation of effect on constituent parts and delivered product +- Consideration of whether change triggers a new regulatory submission (e.g., substantial modification under EU MDR) +- Records of changes, reviews, and approvals maintained + +**7.3.10 Design and Development Files (DHF)** — The organisation shall maintain a design and development file for each medical device type or family. The DHF shall include or reference documents generated to demonstrate conformance to design and development requirements and records of design and development changes. + +#### 7.4 Purchasing + +**7.4.1 Purchasing Process** — Ensure purchased product (including outsourced processes) conforms to specified requirements. Extent of controls depends on effect on product or final product. Evaluate and select suppliers based on ability to supply according to requirements. Criteria for selection, evaluation, and re-evaluation documented. Records of evaluations and actions arising maintained. +- Maintain an approved supplier list (ASL) with supplier qualification status +- Perform supplier qualification before first use + +**7.4.2 Purchasing Information** — Purchasing documents shall describe requirements including: +- Product, procedures, processes, equipment specification +- Requirements for qualification of supplier personnel +- QMS requirements (e.g., ISO 13485-certified supplier preferred) +- Regulatory requirements as applicable + +**7.4.3 Verification of Purchased Product** — Establish and implement inspection or other activities to ensure purchased product meets specified requirements. Records of verifications maintained. Where verification at supplier premises intended, state in purchasing documents. + +#### 7.5 Production and Service Provision + +**7.5.1 Control of Production and Service Provision** — Plan and carry out production under controlled conditions. Controlled conditions shall include: +- Availability of documents defining characteristics of product +- Availability and use of monitoring and measuring equipment +- Implementation of monitoring and measurement activities +- Implementation of labelling and packaging operations +- Implementation of defined release, delivery, and post-delivery activities +- Competence of personnel who can have significant influence on product quality + +**7.5.2 Cleanliness of Product** — Document requirements for cleanliness of product if: +- Product is cleaned by the organisation prior to sterilisation or its use +- Product is supplied non-sterile to be subjected to a cleaning process prior to sterilisation or use +- Product is supplied to be used non-sterile and its cleanliness is significant in use +- Process agents are to be removed during manufacture + +**7.5.3 Installation Activities** — If the device requires installation: document requirements and criteria for installation and inspection/testing of installed device. Records of installation and verification maintained. + +**7.5.4 Service Activities** — If servicing is a specified requirement: document procedures, work instructions, and reference materials for servicing. Records of servicing activities maintained. Analyse service reports to determine if they constitute complaints. + +**7.5.5 Particular Requirements for Sterile Medical Devices** — The organisation shall maintain records of sterilisation processes used including parameters achieved. Records shall be traceable to each production unit. Sterile barrier systems shall be validated prior to use. + +**7.5.6 Validation of Processes for Production and Service Provision** — Validate processes where the resulting output cannot be verified by subsequent monitoring/measurement. Validation demonstrates ability to achieve planned results. Document arrangements for validation including: +- Criteria for process review and approval +- Equipment qualification and personnel qualification +- Methods, procedures, and validation protocols +- Records requirements +- Revalidation criteria + +**7.5.7 Particular Requirements for Validation of Sterilisation Processes and Sterile Barrier Systems** — Validate sterilisation processes and sterile barrier systems prior to initial use and following changes to the process or equipment. Records maintained. + +**7.5.8 Identification** — Identify product by suitable means throughout product realization. Status of product with respect to monitoring and measurement requirements shall be identified. Identification maintained throughout production, storage, installation, and servicing. + +**7.5.9 Traceability** + +**General** — Document traceability procedures. Traceability records shall be maintained. + +**Particular requirements for implantable devices** — The organisation shall document procedures for traceability to include: +- All components, materials, and conditions of the work environment used in manufacturing +- Name and address of consignee for implantable devices distributed + +For implantable devices, records shall provide traceability to the extent that it would be possible to trace all of the above if a field safety corrective action (FSCA) / recall were required. + +**Particular requirements for active implantable devices** — Additional traceability requirements as specified by applicable regulations. + +**7.5.10 Customer Property** — Exercise care with customer property while it is under the organisation's control or being used. Identify, verify, protect, and safeguard customer property. Report damage/loss/unsuitability to customer; maintain records. + +**7.5.11 Preservation of Product** — During internal processing and delivery to intended destination: preserve product conformity. Including identification, handling, packaging, storage, protection. For implantable devices, special preservation requirements apply. + +#### 7.6 Control of Monitoring and Measuring Equipment + +Determine monitoring and measurement activities and equipment needed to provide evidence of product conformity. Procedures for control of monitoring and measuring equipment. Equipment shall be: +- Calibrated or verified at specified intervals or before use, against measurement standards traceable to international or national standards +- Adjusted or re-adjusted as necessary; adjustments protected from invalidation +- Identified to enable calibration status to be determined +- Safeguarded from adjustment, damage, or deterioration during handling, maintenance, and storage +- Records of calibration/verification results maintained +If found out of calibration: validity of previous results assessed, corrective action taken, records maintained. + +--- + +### Clause 8 — Measurement, Analysis, and Improvement + +#### 8.1 General +Plan and implement monitoring, measurement, analysis, and improvement processes needed to demonstrate product conformity, ensure QMS conformity, and maintain QMS effectiveness. + +#### 8.2 Monitoring and Measurement + +**8.2.1 Feedback** — The organisation shall document a procedure for the feedback process as an early warning system for quality problems and for input into the risk management process (ISO 14971). Sources of feedback include: +- Post-market surveillance data +- Complaints and service reports +- Regulatory authority databases (MAUDE, EUDAMED, MHRA Yellow Card) +- Literature reviews +- Production data +- Results from non-clinical/clinical investigations +- Feedback from suppliers, installers, distributors + +**8.2.2 Complaint Handling** — Document a procedure for complaint handling that includes: +- Receipt and logging of complaints +- Criteria for and timing of investigation +- Adverse event reporting to regulatory authorities +- Decision records and rationale +- Corrective actions +- Communication back to complainant + +Records to include: complaint reference, complainant details, device identification (including UDI where applicable), complaint description, investigation results, conclusion, corrective action taken. + +**8.2.3 Reporting to Regulatory Authorities** — If the complaint involves an incident that may qualify as a reportable adverse event or field safety corrective action (FSCA): +- Determine if reporting to regulatory authority is required +- File report within required timeframes (EU MDR: serious incidents within 15 days / 2 days for deaths; FDA MedWatch MDR: 30 days / 5 days for MDR-reportable events) +- Maintain records of all reports submitted and regulatory authority responses + +**8.2.4 Internal Audit** — Conduct internal audits at planned intervals to determine whether the QMS: +- Conforms to planned arrangements, ISO 13485 requirements, and established QMS requirements +- Is effectively implemented and maintained + +Document an audit programme considering status and importance of processes and areas. Auditors shall not audit their own work. Records including results shall be maintained and reported to management. Management responsible for area being audited shall take corrective actions without undue delay. + +**8.2.5 Monitoring and Measurement of Processes** — Apply suitable methods for monitoring and measurement of QMS processes. These methods shall confirm processes' continuing ability to satisfy intended purpose. When planned results are not achieved — corrective action as appropriate. + +**8.2.6 Monitoring and Measurement of Product** — Monitor and measure product characteristics to verify product requirements are met at appropriate stages of the product realization process. Acceptance criteria shall be documented and met prior to release. Records of conformity and authorising person(s) shall be maintained. Where applicable (regulatory requirement), records shall include identity of personnel performing inspection. + +#### 8.3 Control of Nonconforming Product + +**8.3.1 General** — Ensure product that does not conform to product requirements is identified and controlled to prevent unintended use or delivery. Document a procedure defining the controls and responsibilities for: +- Identification, documentation, segregation (when practical), evaluation, and disposal +- Roles authorised to make disposition decisions + +**8.3.2 Actions in Response to Nonconforming Product Detected Before Delivery** — Take action(s) including: +- Action to eliminate detected nonconformity (use as-is with concession, rework, re-grade, reject/scrap) +- For concessions (use/release of nonconforming product): authorised by customer/regulatory authority if required +- Records of nonconformities, evaluations, and actions taken maintained + +**8.3.3 Actions in Response to Nonconforming Product Detected After Delivery** — Take action(s) appropriate to effects or potential effects, including: +- Field safety corrective action (FSCA) / recall if necessary +- Advisory notice to customers +- Notification to regulatory authorities if required +- Records maintained + +**8.3.4 Rework** — Document a procedure for rework that: +- Considers potential adverse effect of rework on product (risk assessment) +- Has the same or equivalent method and approval authority as original production +- Records of rework maintained + +#### 8.4 Analysis of Data +Determine, collect, and analyse appropriate data to demonstrate the suitability and effectiveness of the QMS and to evaluate where improvements can be made. Data shall be generated through monitoring and measurement and from other relevant sources. Analyse to provide information on: +- Customer feedback +- Conformity to product requirements +- Characteristics and trends of processes and products, including opportunities for preventive action +- Suppliers + +#### 8.5 Improvement + +**8.5.1 General** — The organisation shall identify and implement changes necessary to ensure and maintain the continued suitability, adequacy, and effectiveness of the QMS. Changes shall include evaluation using the quality policy, quality objectives, audit results, analysis of data, corrective and preventive actions, and management review. Note: ISO 13485 requires maintaining effectiveness — not necessarily "continual improvement" in the ISO 9001 sense. Regulatory compliance is the primary driver. + +**8.5.2 Corrective Action** — Document a procedure for corrective action that defines requirements for: +- Reviewing nonconformities (including complaints) +- Determining causes of nonconformities +- Evaluating need for action to ensure nonconformities do not recur +- Planning and implementing action needed, including as appropriate updating documentation +- Verifying effectiveness of corrective action +- Records of corrective actions maintained + +**8.5.3 Preventive Action** — Document a procedure for preventive action that defines requirements for: +- Determining potential nonconformities and their causes +- Evaluating need for action to prevent occurrence +- Planning and implementing action +- Verifying effectiveness of preventive action +- Records of results of preventive actions maintained + +--- + +## Core Workflows + +### 1. Gap Analysis + +**Inputs needed from user:** Organisation role (manufacturer / contract manufacturer / supplier / distributor), products/device types in scope, regulatory markets (EU, US, CA, AU, JP, CN), current documentation status, certification target or timeline. + +**Process:** +1. Assess all eight clauses (4–8) for documentation and implementation status +2. Identify mandatory documented procedures (13 required by ISO 13485) +3. Identify mandatory records +4. Map to applicable regulatory requirements for target markets +5. Identify high-risk gaps (regulatory non-compliance, product safety impact) +6. Produce prioritised remediation roadmap + +**Output format:** +``` +CLAUSE | REQUIREMENT SUMMARY | STATUS | EVIDENCE NEEDED | PRIORITY | NOTES +4.2.2 | Quality manual | Red | Manual document | High | Does not address exclusions +7.3.10 | Design history file | Amber | DHF structure | High | Exists but incomplete +8.2.2 | Complaint procedure | Green | SOP-COMP-001 | Low | Implemented, last reviewed 2024 +``` + +**Status definitions:** +- Green — fully implemented with available evidence +- Amber — partially implemented; gaps identified +- Red — not implemented or no evidence + +### 2. Mandatory Documented Procedures + +ISO 13485:2016 explicitly requires the following documented procedures: + +| Reference | Document Type | Title | +|-----------|-------------|-------| +| 4.2.4 | Procedure | Control of Documents | +| 4.2.5 | Procedure | Control of Records | +| 5.6.1 | Procedure/Record format | Management Review | +| 7.3.1 | Procedure | Design and Development (if design is in scope) | +| 7.3.9 | Procedure | Control of Design and Development Changes | +| 7.4.1 | Procedure | Purchasing and Supplier Management | +| 7.5.1 | Procedures / Work Instructions | Production and Service Controls | +| 7.5.6 | Procedure | Validation of Processes | +| 7.5.8 | Procedure | Identification | +| 7.5.9 | Procedure | Traceability | +| 8.2.2 | Procedure | Complaint Handling | +| 8.3.1 | Procedure | Control of Nonconforming Product | +| 8.5.2 | Procedure | Corrective Action | +| 8.5.3 | Procedure | Preventive Action | + +> Additionally: 7.5.5 and 7.5.7 require documented procedures if sterile medical devices are produced. + +### 3. Mandatory Records + +ISO 13485:2016 requires records to be maintained for (non-exhaustive): + +| Clause | Record | +|--------|--------| +| 4.2.5 | All records controlled per records procedure | +| 5.6.1 | Management review minutes | +| 6.2 | Competence, training, qualification records | +| 6.3 | Infrastructure maintenance records | +| 6.4.1 | Work environment monitoring records (if applicable) | +| 7.1 | Risk management records | +| 7.2.2 | Contract/order review records | +| 7.3.3 | Design and development inputs | +| 7.3.4 | Design and development outputs | +| 7.3.5 | Design and development review results and participants | +| 7.3.6 | Design and development verification results | +| 7.3.7 | Design and development validation results | +| 7.3.8 | Design transfer records | +| 7.3.9 | Design change records | +| 7.3.10 | Design history file (DHF) | +| 7.4.1 | Supplier evaluation and re-evaluation records; approved supplier list | +| 7.4.3 | Incoming inspection / receiving inspection records | +| 7.5.1 | Production records | +| 7.5.3 | Installation and verification records | +| 7.5.4 | Service records | +| 7.5.5 | Sterilisation process records | +| 7.5.6 | Process validation records | +| 7.5.7 | Sterilisation validation records | +| 7.5.9 | Traceability records | +| 7.6 | Calibration / verification records for monitoring and measuring equipment | +| 8.2.1 | Feedback data records | +| 8.2.2 | Complaint records | +| 8.2.3 | Regulatory authority adverse event reports | +| 8.2.4 | Internal audit programme and results | +| 8.2.6 | Product inspection / test records; identity of authorising person | +| 8.3 | Nonconforming product records and disposition | +| 8.5.2 | Corrective action records | +| 8.5.3 | Preventive action records | + +### 4. Design Controls — DHF Structure Guidance + +When asked to help with design controls, structure the Design History File (DHF) as follows: + +**Phase 1 — Concept / Feasibility** +- Marketing / clinical requirements (voice of customer) +- Preliminary risk analysis (ISO 14971 — hazard identification) +- Initial intended use statement +- Regulatory pathway analysis (510(k), PMA, EU MDR classification, CE marking route) + +**Phase 2 — Design Inputs (Clause 7.3.3)** +- User needs translated into product requirements +- Performance requirements (biomechanical, electrical, chemical, mechanical) +- Safety requirements (per ISO 14971 risk controls) +- Applicable standards list (IEC 60601, ISO 10993, IEC 62304, etc.) +- Regulatory requirements applicable to target markets +- Usability / human factors requirements (IEC 62366-1) +- Packaging / labelling requirements (incl. UDI requirements) + +**Phase 3 — Design Outputs (Clause 7.3.4)** +- Engineering drawings, specifications, BOMs +- Software architecture and detailed design documents +- Labelling drafts +- Manufacturing process specifications +- Acceptance criteria linked to each input requirement + +**Phase 4 — Design Reviews (Clause 7.3.5)** +- Formal gate reviews at defined milestones +- Attendees: regulatory, quality, engineering, manufacturing, clinical (as applicable) +- Risk management review at each gate +- Minutes and action items recorded + +**Phase 5 — Verification (Clause 7.3.6)** +- Test protocols linked to each design output / input requirement +- Bench testing, laboratory testing, software testing (IEC 62304) +- Environmental testing, EMC testing (if applicable) +- Biocompatibility testing (ISO 10993 series) +- Verification test reports + +**Phase 6 — Validation (Clause 7.3.7)** +- Clinical evaluation (EU MDR Art. 61 / ISO 14155 clinical investigation if required) +- Usability validation (summative usability evaluation per IEC 62366) +- Process validation (7.5.6, 7.5.7) +- Software validation (if applicable) +- Validation test reports + +**Phase 7 — Design Transfer (Clause 7.3.8)** +- Transfer checklist: design outputs transferable to manufacturing +- Manufacturing process development records +- Approval of manufacturing procedures and work instructions +- Pilot run records confirming production process achieves design output + +**Phase 8 — Post-Market Surveillance Feeds Back to DHF** +- PMCF (post-market clinical follow-up) outputs update the technical file +- PMS data feeds back into risk management file (ISO 14971 Section 9) + +### 5. CAPA — Corrective and Preventive Action + +When generating a CAPA record or procedure, structure as: + +``` +CAPA Reference: [ID] +Date opened: [Date] +Initiated by: [Role] +Source: [Complaint / Audit / NC product / feedback / other] +Device/product affected: [Description + UDI if applicable] + +1. Problem Statement (What, When, Where, Who, How often) + +2. Immediate Containment Actions (taken within [timeframe]): + - Action 1 + - Action 2 + +3. Root Cause Analysis Method: [5-Why / Fishbone / Fault Tree / other] + - Root cause identified: [description] + - Supporting evidence: [records, data] + +4. Corrective / Preventive Actions: + | Action | Owner | Due Date | Status | + |--------|-------|----------|--------| + | Update SOP-XXX section 4.2 | QA Manager | [Date] | Open | + +5. Effectiveness Verification: + - Verification method: [Audit, data trending, re-inspection] + - Evidence collected: [Record reference] + - Effectiveness confirmed: Yes / No / Pending + - Date verified: [Date] by [Role] + +6. CAPA Closure: + - Closed by: [Role] + - Closure date: [Date] + - Summary of outcome: +``` + +### 6. Risk Management Integration (ISO 14971) + +ISO 13485 mandates risk management activities per ISO 14971:2019. When helping with risk: + +**Risk management process (ISO 14971 structure):** +1. Risk management planning (risk management plan per ISO 14971 Clause 4) +2. Hazard identification (Clause 5.4) — for all foreseeable sequences of events +3. Risk estimation (probability × severity — Clause 5.5) +4. Risk evaluation (acceptability vs. risk policy — Clause 6) +5. Risk controls (Clause 7) — inherent safety by design → protective measures → information for safety +6. Residual risk evaluation (Clause 8) +7. Risk management report (Clause 9) — benefit-risk analysis +8. Post-market surveillance feeds back into Clause 10 (production and post-production information) + +**Risk register columns (recommended):** +| Hazard ID | Hazard | Hazardous Situation | Sequence of Events | Harm | Severity (1–5) | Probability (1–5) | Risk Level | Control Measures | Residual Risk | Acceptable? | + +--- + +## Regulatory Alignment + +### EU MDR 2017/745 and EU IVDR 2017/746 + +ISO 13485:2016 QMS is required but NOT sufficient for EU MDR / IVDR compliance. Additional requirements include: +- Technical documentation per Annex II (EU MDR) / Annex II (EU IVDR) +- Clinical evaluation per Art. 61 and Annex XIV (MDR) — continuous process +- Post-market surveillance (PMS) system per Art. 83–92 (MDR) +- Post-market clinical follow-up (PMCF) +- Periodic Safety Update Report (PSUR) — Class IIa/IIb/III and Class C/D IVDs +- Summary of Safety and Clinical Performance (SSCP) — Class III / implantables / Class D IVDs +- Unique Device Identification (UDI) assignment (EUDAMED registration) +- Notified Body (NB) involvement for Class IIa, IIb, III devices and Class A sterile/measuring, B, C, D IVDs +- Person Responsible for Regulatory Compliance (PRRC) — required for manufacturers and authorised representatives + +### FDA 21 CFR Part 820 (Quality System Regulation / QMSR) + +The FDA published the updated Quality Management System Regulation (QMSR) in 2024, aligning to ISO 13485:2016. Key FDA-specific additions: +- Design History File (DHF), Device Master Record (DMR), Device History Record (DHR) — explicit records requirements +- Complaint files and MDR (Medical Device Reporting) under 21 CFR Part 803 +- Annual product review (optional but good practice) +- FDA 483 observations and Warning Letters — track and remediate +- Establishment Registration (Form 510k for 510(k) submissions) +- Technical Support Documentation for Pre-submissions + +### MDSAP — Medical Device Single Audit Program + +MDSAP allows a single regulatory audit accepted by Australia (TGA), Brazil (ANVISA), Canada (Health Canada), Japan (MHLW), and USA (FDA). Audit approach: +- Uses ISO 13485:2016 as the QMS baseline +- Adds country-specific requirements from each participating authority +- Audit is performed by MDSAP-authorised auditing organisations +- Single MDSAP certificate accepted in lieu of individual country audits (except for new submissions requiring individual regulatory approval) + +For full regulatory mappings → read `references/iso13485-regulatory-mapping.md` + +--- + +## Certification Pathway + +### Stage 1 Audit (Documentation Review) +Typical notified body / certification body review of: +- Quality manual and QMS scope +- Documented procedures (all mandatory procedures) +- Quality policy and objectives +- Management review records +- Internal audit programme +- Design and development files (sample review) +- Risk management file sample +- Complaint procedure + +**Stage 1 documentation readiness checklist:** +- [ ] Quality manual (4.2.2) — with scope, exclusions justified +- [ ] Quality policy (5.3) — signed by top management +- [ ] Quality objectives (5.4.1) — measurable, documented +- [ ] All mandatory documented procedures (see list above) +- [ ] Medical device file structure (4.2.3) — at least one example +- [ ] Internal audit programme (8.2.4) +- [ ] Management review template / records (5.6) +- [ ] Organisational chart and role descriptions (5.5.1) +- [ ] Risk management plan (ISO 14971 — Clause 7.1 link) +- [ ] Approved supplier list (7.4.1) + +### Stage 2 Audit (Implementation Verification) +Auditor verifies implementation including: +- Witnessing production / operations activities +- Reviewing DHF(s) for sample device(s) +- Reviewing complaint records and CAPA trail +- Interviewing staff on QMS awareness +- Reviewing sampling of manufacturing/inspection records + +**Stage 2 evidence required:** +- Executed internal audits with findings and management sign-off +- Completed management review minutes with decisions/actions +- Active CAPA log (open and closed CAPAs) +- Complaint log with investigation records +- DHF for at least one device in scope +- Calibration records for measurement equipment +- Training records for production and QA personnel +- Nonconforming product disposition records +- Feedback and post-market surveillance data + +### Surveillance Audits +Annual (typically) — auditor verifies continued QMS operation and improvement. Recertification every 3 years. + +--- + +## Common Gap Areas (What Organisations Typically Miss) + +1. **Medical device file incomplete or not maintained** (4.2.3) — often exists as a design file only with no regulatory/labelling/traceability linkage +2. **Risk management not integrated** (7.1) — risk management records exist but are disconnected from design inputs/outputs, CAPA, and post-market data +3. **Design transfer not documented** (7.3.8) — design verification done but no formal transfer protocol to manufacturing +4. **Complaint threshold not defined** (8.2.2) — no written criteria for what constitutes a "complaint" vs. service request vs. enquiry +5. **Regulatory authority reporting criteria undefined** (8.2.3) — no procedure defining what triggers a vigilance report or MDR +6. **Supplier re-evaluation not performed** (7.4.1) — initial qualification done but no periodic re-evaluation programme +7. **Process validation scope too narrow** (7.5.6) — sterilisation validated but packaging, welding, cleaning, coating processes not addressed +8. **Preventive action confused with corrective action** (8.5.3) — PA records are reactive rather than proactive; feeds back into audit finding +9. **Records retention policy incomplete** (4.2.5) — retention periods not linked to device lifetime + 2 years; no definition for electronic vs. physical records +10. **Internal auditors not trained** (8.2.4) — audit conducted but auditors have no documented internal audit training or qualification + +--- + +## Key Terminology + +| Term | Definition | +|------|-----------| +| Medical device | Any instrument, apparatus, implant, in vitro reagent, or similar article intended for use in diagnosis, prevention, monitoring, treatment, or alleviation of disease or injury | +| QMS | Quality Management System | +| DHF | Design History File — compilation of records that describes the design history of a finished device (FDA terminology); equivalent to the Technical File / Technical Documentation in EU | +| DMR | Device Master Record — compilation of records containing procedures and specifications for a finished device (FDA 21 CFR 820.3) | +| DHR | Device History Record — compilation of records providing evidence that a device has been manufactured in accordance with the DMR | +| Technical file | EU MDR / IVDR term for the collection of documentation demonstrating conformity with applicable requirements | +| CAPA | Corrective and Preventive Action | +| NCR | Non-Conformance Report | +| NB | Notified Body — conformity assessment organisation designated by an EU member state | +| FSCA | Field Safety Corrective Action — action taken to reduce risk of death or serious deterioration in state of health associated with device used after market distribution | +| FSN | Field Safety Notice — communication sent to customers in the field in connection with an FSCA | +| PMCF | Post-Market Clinical Follow-Up | +| PSUR | Periodic Safety Update Report | +| SSCP | Summary of Safety and Clinical Performance | +| UDI | Unique Device Identification | +| EUDAMED | European Database on Medical Devices | +| MDSAP | Medical Device Single Audit Program | +| MDR | Medical Device Reporting (FDA) or Medical Device Regulation (EU 2017/745) — context-dependent | +| ISO 14971 | International standard for risk management for medical devices | +| IEC 62304 | Medical device software — software lifecycle processes | +| IEC 62366 | Medical devices — application of usability engineering | +| ISO 10993 | Biological evaluation of medical devices series | + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +- `references/iso13485-clauses.md` — Full clause text summary with sub-clause requirements table +- `references/iso13485-regulatory-mapping.md` — Cross-reference: ISO 13485 clauses ↔ EU MDR, FDA 21 CFR 820, MDSAP, Health Canada, TGA, MHLW +- `references/iso13485-design-controls.md` — Design and development process (Clause 7.3) detail, DHF templates, phase gate criteria +- `references/iso13485-templates.md` — Document templates for key QMS documents (quality manual outline, CAPA form, NCR form, complaint form, management review agenda, audit checklist) + +**When to load reference files:** +- Gap analysis → load `iso13485-clauses.md` and `iso13485-regulatory-mapping.md` +- Design control question → load `iso13485-design-controls.md` +- Document generation → load `iso13485-templates.md` +- Regulatory submission question → load `iso13485-regulatory-mapping.md` +- Full certification readiness → load all reference files diff --git a/plugins/iso13485/skills/iso13485/references/iso13485-clauses.md b/plugins/iso13485/skills/iso13485/references/iso13485-clauses.md new file mode 100644 index 0000000..2dd7e92 --- /dev/null +++ b/plugins/iso13485/skills/iso13485/references/iso13485-clauses.md @@ -0,0 +1,293 @@ +# ISO 13485:2016 — Clause Requirements Reference + +## Overview + +ISO 13485:2016 contains eight numbered clauses (Clauses 1–8). Clauses 1–3 are introductory (scope, normative references, terms). The normative requirements are in **Clauses 4–8**. + +The standard uses the phrase "documented procedure" to mean a written procedure that is established, documented, implemented, and maintained. The phrase "records shall be maintained" indicates evidence must be kept. Below is a clause-by-clause summary table followed by detailed sub-clause notes. + +--- + +## Clause 4 — Quality Management System + +| Sub-clause | Title | Key Requirement | Documented Procedure? | Records Required? | +|-----------|-------|----------------|----------------------|------------------| +| 4.1 | General requirements | Establish, document, implement and maintain QMS; control outsourced processes | No (but processes must be documented) | No | +| 4.2.1 | General documentation requirements | QMS documentation set: quality policy, objectives, manual, procedures, records, regulatory documents | No | No | +| 4.2.2 | Quality manual | Maintain quality manual covering scope, exclusions, interactions | No | Yes (quality manual is a record-like document) | +| 4.2.3 | Medical device file | Maintain per device type/family; demonstrate conformity; includes labelling, design files, specs | No | Yes — file per device type/family | +| 4.2.4 | Control of documents | Document approval, review, change control, obsolete doc control | Yes — mandatory | No | +| 4.2.5 | Control of records | Legible, retrievable, protected records; retention per device lifetime + 2 years minimum | Yes — mandatory | Yes — record retention log | + +### 4.1 — Outsourced Processes Note + +When an organisation outsources any process that affects product conformity (e.g., sterilisation, testing, manufacturing, distribution), it must: +- Identify which processes are outsourced +- Document controls applied (e.g., supplier quality agreement, supplier audit) +- Maintain records of outsourced process control activities +- Include outsourced processes in internal audit scope where applicable + +### 4.2.3 — Medical Device File Content (Non-exhaustive) + +The medical device file (MDF) is the master reference file for each device type or device family. It may be a physical file, an electronic system, or a structured set of referenced documents. Minimum expected content: + +| Category | Document Examples | +|----------|------------------| +| Device description | Intended use, indications, contraindications, patient population, body site | +| Labelling | Labels, instructions for use (IFU), packaging artwork — all language versions | +| Design outputs | Drawings, specifications, BOM, inspection test plans (see Clause 7.3.4) | +| Manufacturing | Process specifications, work instructions, validation records | +| Risk management | Risk management plan, risk management file (ISO 14971) | +| Clinical evidence | Clinical evaluation report, PMCF protocol/reports (EU MDR) / clinical data summary | +| Regulatory | Classification justification, regulatory submissions summary, certificates | +| Traceability | UDI assignment records, traceability scheme | +| Post-market | PMS plan, PSUR (if required), complaint summary | + +### 4.2.4 — Document Control Minimum Workflow + +``` +Draft → Review (technical / regulatory) → Approval (QA / authorised) → Issue (version control) → +Distribution (controlled copies) → Periodic review (scheduled) → Change → Re-approval → Archive/obsolete +``` + +--- + +## Clause 5 — Management Responsibility + +| Sub-clause | Title | Key Requirement | D/P? | Records? | +|-----------|-------|----------------|------|---------| +| 5.1 | Management commitment | Top management communicates requirements; establishes policy/objectives; provides resources; conducts reviews | No | Via management review | +| 5.2 | Customer focus | Customer requirements determined and met subject to regulatory requirements | No | No | +| 5.3 | Quality policy | Documented, communicated, reviewed for suitability | No | Policy is a controlled document | +| 5.4.1 | Quality objectives | Measurable objectives at relevant functions and levels | No | Yes — objectives record | +| 5.4.2 | QMS planning | Planning maintains integrity during changes | No | No | +| 5.5.1 | Responsibility and authority | Defined and communicated; independence of QA function | No | Org chart, role descriptions | +| 5.5.2 | Management representative | Designated individual with defined authority | No | Appointment letter or job description | +| 5.5.3 | Internal communication | Appropriate processes established | No | No | +| 5.6.1 | Management review — general | Planned interval reviews; maintain QMS effectiveness | No | Yes — management review minutes | +| 5.6.2 | Review input | Listed inputs: audits, feedback, NC, CAPA, changes, regulatory | No | Captured in review minutes / input pack | +| 5.6.3 | Review output | Decisions on QMS effectiveness, product improvement, resources | No | Captured in review minutes | + +### 5.6.2 — Management Review Input Checklist + +All of the following shall be addressed at each management review: +- [ ] Results of internal audits +- [ ] Results of external/regulatory authority audits +- [ ] Customer feedback (including complaint trend data) +- [ ] Process performance (KPIs) and product conformity data +- [ ] Corrective action and preventive action status (open and closed) +- [ ] Follow-up actions from previous management review +- [ ] Changes that could affect the QMS (regulatory, product, process, organisational) +- [ ] Recommendations for improvement +- [ ] New or revised regulatory requirements +- [ ] Applicable new or revised standards + +### 5.6.3 — Management Review Output Minimum + +The output record must capture at minimum: +1. Decisions and actions on QMS effectiveness improvements +2. Decisions and actions on product improvements +3. Resource allocations/approvals +4. Any regulatory actions required + +--- + +## Clause 6 — Resource Management + +| Sub-clause | Title | Key Requirement | D/P? | Records? | +|-----------|-------|----------------|------|---------| +| 6.1 | Provision of resources | Determine and provide resources for QMS maintenance and regulatory compliance | No | No | +| 6.2 | Human resources | Competence based on education, training, skills, experience; training effectiveness evaluated | No | Yes — training records | +| 6.3 | Infrastructure | Define, provide, maintain; maintenance schedule | No | Yes — maintenance records | +| 6.4.1 | Work environment | Document and monitor environmental conditions affecting product quality | No | Yes — environmental monitoring records (if applicable) | +| 6.4.2 | Contamination control | Documented arrangements for contamination control; specific requirements for sterile devices | No | Yes — cleaning/contamination records (if applicable) | + +### 6.2 — Competence and Training Requirements + +Minimum training programme elements: +1. QMS awareness training — all staff (quality policy, objectives, role impact) +2. Job-specific technical training — documented training matrix per role +3. Regulatory awareness — applicable regulations for markets in scope +4. Good Documentation Practice (GDP) — all records-generating personnel +5. Deviation/NC reporting — all production and QA staff +6. Complaint identification and escalation — customer-facing and field personnel + +Training effectiveness evaluation methods: Written assessment, practical observation, error rate monitoring (for technical tasks), supervisor sign-off. + +--- + +## Clause 7 — Product Realization + +| Sub-clause | Title | D/P? | Records? | +|-----------|-------|------|---------| +| 7.1 | Planning of product realization | No (but outputs documented) | Yes — quality plan, risk management records | +| 7.2.1 | Determination of product requirements | No | No | +| 7.2.2 | Review of product requirements | No | Yes — review records | +| 7.2.3 | Customer communication | No | No | +| 7.3.1 | Design and development — general | Yes — mandatory (if D&D in scope) | Yes | +| 7.3.2 | D&D planning | No (covered by 7.3.1 procedure) | Yes — D&D plan | +| 7.3.3 | D&D inputs | No | Yes — D&D input records | +| 7.3.4 | D&D outputs | No | Yes — D&D output records | +| 7.3.5 | D&D review | No | Yes — review records with participants | +| 7.3.6 | D&D verification | No | Yes — verification records | +| 7.3.7 | D&D validation | No | Yes — validation records | +| 7.3.8 | D&D transfer | No | Yes — transfer records | +| 7.3.9 | Control of D&D changes | Yes — mandatory | Yes — change records | +| 7.3.10 | Design and development files (DHF) | No (procedure covers creation) | Yes — DHF per device type | +| 7.4.1 | Purchasing process | Yes — mandatory | Yes — supplier evaluation, ASL | +| 7.4.2 | Purchasing information | No | Yes — purchase orders, specifications | +| 7.4.3 | Verification of purchased product | No | Yes — incoming inspection records | +| 7.5.1 | Control of production | Yes — mandatory (work instructions) | Yes — batch/lot records | +| 7.5.2 | Cleanliness of product | Yes (if applicable) | Yes | +| 7.5.3 | Installation activities | Yes (if applicable) | Yes | +| 7.5.4 | Service activities | Yes (if applicable) | Yes | +| 7.5.5 | Sterile device requirements | Yes — mandatory (if sterile) | Yes — sterilisation records | +| 7.5.6 | Process validation | Yes — mandatory | Yes — validation protocols/reports | +| 7.5.7 | Sterilisation / sterile barrier validation | Yes — mandatory (if sterile) | Yes | +| 7.5.8 | Identification | Yes — mandatory | No | +| 7.5.9 | Traceability | Yes — mandatory | Yes — traceability records | +| 7.5.10 | Customer property | No | Yes — customer property records | +| 7.5.11 | Preservation of product | No | No (unless environmental monitoring relevant) | +| 7.6 | Monitoring and measuring equipment | No | Yes — calibration records | + +### 7.3 — Design and Development Exclusion + +A manufacturer may exclude Clause 7.3 only where: +- The organisation has no design authority and produces exclusively to external design documents provided by the customer +- The customer retains full design responsibility +- This exclusion is explicitly documented and justified in the quality manual +- The applicable regulatory authority for the target market accepts this exclusion + +> Note: The FDA QMSR (2024) and EU MDR Annex IX require design controls from the manufacturer. Contract manufacturers operating under full customer design authority may be excluded, but this must be confirmed on a case-by-case basis with the relevant NB or FDA reviewer. + +### 7.4.1 — Supplier Qualification Minimum Requirements + +For critical suppliers (those supplying materials, components, or services that directly affect device safety or performance): + +**Initial qualification:** +1. Supplier questionnaire / self-assessment +2. Quality agreement (including regulatory requirements, change notification, audit rights) +3. On-site audit (for highest-criticality suppliers) +4. Sample inspection and approval +5. Addition to Approved Supplier List (ASL) + +**Ongoing evaluation:** +1. Periodic re-evaluation (frequency based on criticality — typically annual for critical) +2. Supplier performance scorecard (delivery performance, NC rate, response to issues) +3. Change notification from supplier (material change, site change, process change) +4. Re-qualification if change exceeds defined threshold + +### 7.6 — Calibration Requirements + +Monitoring and measuring equipment used to demonstrate product conformity must be controlled. Minimum programme elements: + +| Element | Requirement | +|---------|------------| +| Calibration schedule | Defined intervals per equipment type based on stability, criticality, usage | +| Calibration standards | Traceability to national/international measurement standards (NIST, BIPM, etc.) | +| Calibration labels | Equipment tagged with calibration status (due date, reference to certificate) | +| Out-of-calibration procedure | What to do when equipment found out of calibration — assess impact on prior measurements | +| Adjustments | Adjustments protected from invalidation (tamper-evident, access-controlled) | +| Records | Calibration certificate with as-found and as-left values | +| Computer-assisted measurement | Software validation required for measurement software | + +--- + +## Clause 8 — Measurement, Analysis, and Improvement + +| Sub-clause | Title | D/P? | Records? | +|-----------|-------|------|---------| +| 8.1 | General | No | No | +| 8.2.1 | Feedback | Yes — mandatory | Yes — feedback records | +| 8.2.2 | Complaint handling | Yes — mandatory | Yes — complaint records | +| 8.2.3 | Reporting to regulatory authorities | Yes — mandatory | Yes — adverse event reports | +| 8.2.4 | Internal audit | Yes — mandatory | Yes — audit programme, reports | +| 8.2.5 | Monitoring and measurement of processes | No | Yes — process performance data | +| 8.2.6 | Monitoring and measurement of product | No | Yes — inspection records, release authorisation | +| 8.3.1 | Control of NC product — general | Yes — mandatory | Yes — NCR records | +| 8.3.2 | NC product before delivery — actions | No | Yes — disposition records | +| 8.3.3 | NC product after delivery — actions | No | Yes — FSCA/recall records if applicable | +| 8.3.4 | Rework | Yes — mandatory (if rework occurs) | Yes — rework records | +| 8.4 | Analysis of data | No | No (outputs feed into management review) | +| 8.5.1 | General improvement | No | No | +| 8.5.2 | Corrective action | Yes — mandatory | Yes — CAPA records | +| 8.5.3 | Preventive action | Yes — mandatory | Yes — PA records | + +### 8.2.2 — Complaint Handling — Minimum Procedure Elements + +1. **Receipt:** All complaints received through any channel (phone, email, field service, distributor) captured in complaint log +2. **Logging:** Unique complaint reference; device identification; complainant data; description of complaint; date received; date of alleged incident +3. **Triage:** Decision: is this a reportable adverse event? Is there an immediate safety concern requiring containment? +4. **Investigation:** Root cause analysis; device/product analysis (if sample returned); regulatory determination +5. **Response:** Corrective action; communication to complainant (where appropriate and required) +6. **Regulatory reporting:** Determination whether MDR (FDA) / vigilance report (EU MDR) required — within statutory timeframe +7. **Closure:** Record of investigation conclusions, corrective action taken, closure authorisation + +**Key complaint record fields:** +- Complaint ID and date received +- Reporter name and contact (or anonymous flag) +- Device type, model, lot/serial number, UDI (if applicable) +- Date of event (if different from complaint date) +- Description of complaint / alleged failure +- Patient outcome (if applicable: adverse event, death, serious injury) +- Investigation results +- Root cause (final) +- Regulatory report filed: Y/N — report number and date +- CAPA reference (if opened) +- Disposition / corrective action +- Closure date and authorising person + +### 8.2.3 — Regulatory Authority Reporting Timeframes + +| Authority | Regulation | Event Type | Timeframe | +|-----------|-----------|------------|-----------| +| European Commission / NB | EU MDR Art. 87 | Serious incident | 15 days | +| European Commission / NB | EU MDR Art. 87 | Death or unanticipated serious deterioration | 2 days (immediate/urgent reporting) | +| European Commission / NB | EU MDR Art. 87 | Field safety corrective action | Before action or without undue delay | +| FDA | 21 CFR Part 803 | Death or serious injury — mandatory reporter | 30 days | +| FDA | 21 CFR Part 803 | Death or serious injury requiring remedial action | 5 days | +| Health Canada | SOR/98-284 | Serious adverse event | 10 days for death/serious deterioration | +| TGA (Australia) | TGA Adverse Event Reporting | Serious incident | 30 days; 48 hours if death | +| MHLW (Japan) | PMD Act | Serious adverse event | 15 days or as specified | + +> Note: Timeframes shown are general. Always confirm against current regulatory guidance for each market as requirements may be updated. These are calendar days unless the regulation specifies business days. + +### 8.3 — Nonconforming Product Disposition Options + +| Disposition | Definition | Requirements | +|------------|-----------|-------------| +| Accept as-is (concession) | Use/release despite nonconformity | Documented justification; authorised by customer/regulator if required; risk assessment | +| Rework | Processing to conform to requirements | Documented rework procedure; re-inspection after rework; records | +| Regrade | Classify for different application | Documents update; label change; may trigger design change | +| Scrap/reject | Remove from supply chain | Prevent accidental use; records of disposal | +| Return to supplier | Return for replacement | Records of return and supplier response | + +--- + +## Mandatory Documented Procedures — Summary + +The following documented procedures are explicitly required by ISO 13485:2016: + +| Clause | Procedure | +|--------|----------| +| 4.2.4 | Control of Documents | +| 4.2.5 | Control of Records | +| 7.3.1 | Design and Development (if design in scope) | +| 7.3.9 | Control of Design and Development Changes (if design in scope) | +| 7.4.1 | Purchasing (Supplier Management) | +| 7.5.1 | Production and Service Provision Controls (work instructions as applicable) | +| 7.5.6 | Validation of Processes | +| 7.5.8 | Identification | +| 7.5.9 | Traceability | +| 8.2.1 | Feedback | +| 8.2.2 | Complaint Handling | +| 8.2.3 | Reporting to Regulatory Authorities | +| 8.2.4 | Internal Audit | +| 8.3.1 | Control of Nonconforming Product | +| 8.3.4 | Rework (if applicable) | +| 8.5.2 | Corrective Action | +| 8.5.3 | Preventive Action | + +Additionally required if producing sterile devices: +| 7.5.5 | Sterilisation Production Controls | +| 7.5.7 | Sterilisation Process Validation | diff --git a/plugins/iso13485/skills/iso13485/references/iso13485-design-controls.md b/plugins/iso13485/skills/iso13485/references/iso13485-design-controls.md new file mode 100644 index 0000000..3bbf786 --- /dev/null +++ b/plugins/iso13485/skills/iso13485/references/iso13485-design-controls.md @@ -0,0 +1,459 @@ +# ISO 13485:2016 — Design Controls Reference (Clause 7.3) + +## Overview + +Clause 7.3 of ISO 13485:2016 covers **design and development** of medical devices. It is one of the most scrutinised clauses during audits because inadequate design controls are a leading cause of device recalls and field safety corrective actions (FSCAs). + +The design controls in ISO 13485 align with and are referenced by: +- **EU MDR 2017/745 Annex II** — Technical Documentation +- **FDA 21 CFR 820.30** — Design Controls +- **IMDRF Technical Documents** on design and development + +Unlike ISO 9001:2015, ISO 13485 adds the following design-specific requirements: +- Design and development transfer (7.3.8) +- Design and development file / Design History File (7.3.10) +- Explicit risk management integration throughout the design process (7.1, linked to ISO 14971) + +--- + +## When Clause 7.3 Applies + +Clause 7.3 is applicable to all **manufacturers with design authority** — organisations that define or own the design of the medical device. It may be excluded only when: +- The organisation manufactures strictly to an external customer's complete design specification +- The exclusion is documented and justified in the quality manual +- The applicable regulatory authority accepts the exclusion (FDA does NOT permit exclusion of design controls for finished device manufacturers) + +> For EU MDR: Notified bodies require design documentation as part of Annex II Technical Documentation regardless of whether the manufacturer claims a 7.3 exclusion. In practice, Class IIa and above manufacturers cannot exclude Clause 7.3. + +--- + +## Design and Development Process — Phase Gate Structure + +The following phase gate model is widely used in medical device development. ISO 13485 does not mandate specific phases, but requires that phase reviews, verifications, and validations are planned and documented. + +### Phase 0 — Concept and Feasibility + +**Objective:** Establish that the device concept is technically feasible and commercially viable before committing design resources. + +**Activities:** +- Voice of customer (clinical need, market research) +- Preliminary intended use statement and indication for use +- Preliminary hazard analysis (ISO 14971 — initial hazard identification) +- Regulatory pathway analysis (EU MDR classification / FDA 510(k) vs. PMA / De Novo) +- Preliminary standards identification +- Feasibility prototyping (if applicable) + +**Key outputs:** +- Feasibility report +- Preliminary intended use document +- Regulatory strategy document +- Initial risk management plan (ISO 14971, Clause 4) + +**Gate 0 criteria:** +- [ ] Clinical need established +- [ ] Regulatory pathway identified +- [ ] Technical feasibility assessed +- [ ] Initial budget and timeline approved + +--- + +### Phase 1 — Design Inputs (ISO 13485 Clause 7.3.2 and 7.3.3) + +**Objective:** Translate user needs and regulatory requirements into documented, measurable design requirements. + +**Activities:** +- User needs analysis (clinical user, patient, lay user) +- Regulatory requirements identification (GSPR for EU MDR / PDPs for FDA) +- Applicable standards determination +- Design input review and approval +- Risk management: hazard identification and risk estimation (ISO 14971 Clauses 4–5) +- Usability requirements (IEC 62366-1 — use specification) + +**Key outputs (Design Inputs — Clause 7.3.3):** + +| Input Category | Examples | +|---------------|---------| +| Performance requirements | Force outputs, accuracy specifications, dimensional tolerances, tensile strength | +| Safety requirements | Electrical safety (IEC 60601), biocompatibility (ISO 10993), EMC (IEC 60601-1-2) | +| Usability requirements | Task analysis, user interface requirements, error tolerance | +| Software requirements | Functional requirements, safety class (IEC 62304 Class A/B/C), cybersecurity requirements | +| Regulatory requirements | GSPR list (EU MDR Annex I), essential requirements | +| Sterility requirements | Sterility Assurance Level (SAL), sterile barrier validation (ISO 11607) | +| Labelling requirements | Symbols (ISO 15223-1), language requirements, UDI, IFU requirements | +| Packaging requirements | Shelf life, transport conditions, drop testing | +| Environmental requirements | Storage temperature, humidity range, operating altitude | + +**Inputs document must be:** +- Reviewed and approved by engineering, regulatory, quality, and clinical functions +- Incomplete, ambiguous, or conflicting requirements resolved before design output phase +- Version-controlled and linked to risk management file + +**Gate 1 criteria:** +- [ ] All design inputs documented and approved +- [ ] Risk management plan approved +- [ ] Applicable standards confirmed +- [ ] Regulatory strategy confirmed (classification, route, timeline) + +--- + +### Phase 2 — Design Outputs (ISO 13485 Clause 7.3.4) + +**Objective:** Create engineering specifications and design artefacts that directly address each design input. + +**Design output categories:** + +| Output Type | Examples | +|------------|---------| +| Engineering drawings | Component drawings, assembly drawings, tolerance stack-ups | +| Specifications | Material specifications, surface finish, dimensional requirements | +| Bill of materials (BOM) | Full component list with manufacturer part numbers, revision levels | +| Software architecture | System architecture, software design documents (IEC 62304) | +| Labelling | Draft labels, IFU, packaging artwork | +| Manufacturing process specs | Assembly procedures, work instructions, cleaning procedures | +| Acceptance criteria | Pass/fail criteria for each verification test | + +**Requirements for design outputs (7.3.4):** +1. Each output must be traceable to a specific design input +2. Outputs must provide sufficient information for purchasing, production, and service +3. Outputs must contain or reference product acceptance criteria +4. Outputs must specify characteristics essential for safe and proper use + +**Traceability matrix:** A design traceability matrix links: +- User need → Design input → Design output → Verification method → Validation → Risk control + +**Gate 2 criteria:** +- [ ] All design inputs have corresponding design outputs +- [ ] Traceability matrix completed +- [ ] Initial design FMEA completed (or equivalent risk assessment) +- [ ] Draft labelling reviewed against regulatory requirements +- [ ] BOM baselined + +--- + +### Phase 3 — Design Verification (ISO 13485 Clause 7.3.6) + +**Objective:** Confirm through objective evidence that design outputs meet design inputs. + +**Verification activities:** + +| Verification Type | Standard / Method | Applicable To | +|------------------|------------------|--------------| +| Dimensional inspection | Engineering drawings | All mechanical components | +| Material testing | ISO 10993 biocompatibility, material characterisation | Contact parts, implants | +| Electrical safety testing | IEC 60601-1, IEC 60601-1-2 (EMC) | Active electrical devices | +| Software unit/integration testing | IEC 62304 | Software-containing devices | +| Mechanical strength testing | ISO, ASTM standards | Structural components | +| Sterilisation compatibility | ISO 11607 | Sterile packaged devices | +| Accelerated aging / shelf life | ASTM F1980 | All sterile / packaged devices | +| Environmental stress testing | Temperature cycling, humidity, vibration | All devices | +| Biocompatibility evaluation | ISO 10993-1 evaluation strategy | Devices in contact with body | + +**Verification protocol minimum content:** +1. Protocol ID, revision, and approval signatures +2. Purpose and scope +3. Reference to design input(s) being verified +4. Acceptance criteria (pass/fail — directly traceable to design input) +5. Test method (standard or internal method) +6. Sample size and selection rationale (statistical justification) +7. Equipment identification and calibration status +8. Test procedure (step-by-step) +9. Results recording format + +**Verification report minimum content:** +1. Reference to protocol +2. Test dates and locations +3. Sample identification (lot/serial numbers, revision levels) +4. Deviations from protocol (with justification if applicable) +5. Results — table of results vs. acceptance criteria +6. Pass/fail conclusion per requirement +7. Signature of test executor and reviewer + +**Gate 3 criteria:** +- [ ] All design outputs verified against design inputs +- [ ] No open verification failures without documented disposition +- [ ] Updated risk assessment post-verification +- [ ] Design review conducted with multi-functional team +- [ ] Design review minutes and action items recorded + +--- + +### Phase 4 — Design Validation (ISO 13485 Clause 7.3.7) + +**Objective:** Confirm through objective evidence that the finished device consistently meets the requirements for the specified intended use. + +> Distinction: Verification asks "did we build the design right?" Validation asks "did we build the right design for the intended use?" + +**Validation activities:** + +| Validation Type | Description | Regulatory Linkage | +|----------------|-------------|-------------------| +| Clinical evaluation | Evaluation of clinical data (literature, clinical investigation, PMCF) | EU MDR Art. 61 / Annex XIV; FDA IDE / 510(k) / PMA clinical evidence | +| Usability summative evaluation | Final user testing with representative users in simulated use | IEC 62366-1; FDA Human Factors guidance | +| Process validation | Confirmation that critical manufacturing processes produce conforming product | Clause 7.5.6 | +| Sterilisation validation | Confirmation that sterilisation process achieves required SAL | ISO 11135 / ISO 11137 / ISO 25424 | +| Software validation | System-level software validation testing | IEC 62304 Clause 5.6 + 5.7 | +| Packaging validation | Confirmation that sterile barrier system maintains sterility during shipping/storage | ISO 11607-2 | +| Simulated use / animal studies | Where applicable, device performance testing under simulated or actual conditions | Protocol-specific; IND/IDE if human use | + +**Clinical evaluation (EU MDR Art. 61 and Annex XIV):** +The clinical evaluation is a continuous process with three main elements: +1. **Literature review** — systematic search of clinical data for the device and equivalent devices +2. **Clinical data analysis** — assessment of clinical safety and performance from available data +3. **Clinical Evaluation Report (CER)** — documents the evaluation outcome and clinical evidence summary + +For devices where clinical data from literature is insufficient, a **clinical investigation** (per ISO 14155:2020) is required. + +**Post-market clinical follow-up (PMCF):** +- Proactive method for collecting post-market clinical data +- Plan (PMCF Plan) and evaluation (PMCF Evaluation Report) at defined intervals +- Feeds into PSUR and clinical evaluation update + +**Gate 4 criteria:** +- [ ] Device validated for intended use under representative conditions +- [ ] Clinical evaluation / clinical data assessed and documented +- [ ] Usability summative evaluation completed (if required) +- [ ] All validation failures resolved or accepted with risk assessment +- [ ] Final risk management report completed (ISO 14971 Clause 9 — benefit-risk determination) +- [ ] Design review conducted; all design review actions closed + +--- + +### Phase 5 — Design Transfer (ISO 13485 Clause 7.3.8) + +**Objective:** Ensure verified and validated design outputs are transferred to routine manufacturing without loss of quality or performance characteristics. + +**Design transfer activities:** +1. Transfer plan — identifies what needs to be transferred, timeline, and acceptance criteria +2. Production process development and validation +3. Manufacturing documentation finalisation (work instructions, assembly procedures, inspection plans) +4. Pilot production run — first article inspection; confirm production process produces conforming product +5. Transfer acceptance review — multi-functional sign-off that transfer is complete +6. Device Master Record (DMR) / Technical File baseline — all design documents placed under configuration control + +**Design transfer checklist:** + +| Transfer Item | Confirmed? | Date | By | +|--------------|-----------|------|-----| +| Engineering drawings released to production | | | | +| BOM finalised and procurement approved | | | | +| Work instructions drafted and approved | | | | +| Inspection plans (incoming, in-process, final) documented | | | | +| Acceptance criteria documented and understood by QA | | | | +| Production equipment qualified (IQ/OQ/PQ where required) | | | | +| Process validation completed (critical processes) | | | | +| First article inspection / pilot run completed | | | | +| Training completed for production personnel | | | | +| Calibration records for all measurement equipment | | | | +| DMR / technical file baselined | | | | + +--- + +### Phase 6 — Post-Market Surveillance (Feeds Back into DHF) + +Post-market information must be systematically collected and evaluated. This feeds back into the design and risk management process: + +| PMS Data Source | Feeds Into | +|----------------|-----------| +| Complaints | CAPA system; risk management file update; vigilance reporting | +| Service/field reports | Risk management risk estimation update | +| Post-market surveillance reports | Clinical evaluation update (CER); PSUR | +| PMCF data | Clinical evaluation / CER | +| Regulatory authority signals | Risk management; possible design change | +| Literature surveillance | Clinical evaluation / CER update | +| Competitor / equivalent device data | Risk management; potential design improvement | + +**Clinical evaluation / CER update frequency:** +- EU MDR Class III and implantable: Annual PSUR; annual CER update +- EU MDR Class IIa / IIb: Every 2 years PSUR; CER update with each PSUR +- All: Triggered update if new safety concerns arise + +--- + +## Design History File (DHF) — Structure Template + +The DHF (called Technical Documentation under EU MDR) is the master record of all design activities. It must be maintainable throughout the device's market lifetime. + +### Recommended DHF Index + +``` +DHF-[Device Name]-[Version] +| ++-- Section 1: Device Overview and Intended Use +| +-- Device description +| +-- Intended use statement +| +-- Indications and contraindications +| +-- Patient population +| +-- Regulatory classification justification +| ++-- Section 2: Design and Development Plan +| +-- D&D plan (phases, milestones, responsibilities) +| +-- Risk management plan +| ++-- Section 3: Design Inputs (Clause 7.3.3) +| +-- User requirements document +| +-- Design input specification (DIS) — all requirements +| +-- Applicable standards list +| +-- Regulatory requirements list +| ++-- Section 4: Design Outputs (Clause 7.3.4) +| +-- Engineering drawings (current revision) +| +-- Specifications (material, electrical, software) +| +-- Bill of materials (BOM) — current revision +| +-- Labelling and IFU +| +-- Manufacturing process specifications +| ++-- Section 5: Design Traceability Matrix +| +-- User need → Design input → Design output → Verification → Risk control +| ++-- Section 6: Design Reviews (Clause 7.3.5) +| +-- Design review minutes per phase gate +| +-- Action logs and closure records +| ++-- Section 7: Verification Records (Clause 7.3.6) +| +-- Verification protocols and reports (by test category) +| +-- Test data and certificates +| ++-- Section 8: Validation Records (Clause 7.3.7) +| +-- Clinical evaluation / clinical data assessment +| +-- Usability evaluation records +| +-- Process validation records (reference to 7.5.6 records) +| +-- Sterilisation validation records (reference to 7.5.7 records) +| +-- Software validation records (IEC 62304) +| ++-- Section 9: Design Transfer Records (Clause 7.3.8) +| +-- Transfer plan and checklist +| +-- First article inspection report +| ++-- Section 10: Risk Management File (ISO 14971) +| +-- Risk management plan +| +-- Hazard identification +| +-- Risk analysis and evaluation +| +-- Risk controls +| +-- Residual risk evaluation +| +-- Benefit-risk analysis +| +-- Risk management report +| +-- Post-market risk monitoring records +| ++-- Section 11: Design Change Records (Clause 7.3.9) +| +-- Change request forms +| +-- Change impact assessments +| +-- Regulatory change assessment (substantial modification?) +| +-- Re-verification/re-validation records +| ++-- Section 12: Post-Market Data (ongoing — linked to PMS records) +| +-- PMS plan and reports +| +-- PMCF plan and evaluation reports +| +-- CER (current version) +| +-- PSUR (current version, if required) +``` + +--- + +## Design Change Control (Clause 7.3.9) + +All changes to a released design must go through a formal change control process. + +### Change Impact Assessment Elements + +When a design change is requested, assess the following: + +| Assessment Question | Yes/No | Action required if Yes | +|--------------------|--------|----------------------| +| Does the change affect the intended use or indication? | | New/updated clinical evaluation | +| Does the change affect device safety or performance? | | Re-verification / re-validation | +| Does the change affect biocompatibility? | | ISO 10993 re-evaluation | +| Does the change affect software? | | IEC 62304 change management | +| Does the change affect sterility? | | Sterilisation re-validation assessment | +| Does the change constitute a substantial modification? (EU MDR) | | Notified Body notification / new application | +| Does the change require a new/updated regulatory submission? (FDA) | | 510(k) / PMA supplement | +| Does the change affect labelling, IFU, or UDI? | | Labelling update; EUDAMED update | +| Does the change affect the risk profile? | | Risk management file update | +| Does the change affect supplier or component? | | Supplier notification; incoming re-qualification | + +### When is a Change a "Substantial Modification" (EU MDR)? + +Under EU MDR Art. 12, a substantial change to a certified device requires notified body involvement (notification at minimum, new application at maximum): + +A change is generally substantial if it: +- Affects the device's intended purpose +- Significantly affects performance or safety (e.g., changes to materials, design, specifications that could affect safety and performance) +- Could affect patient/user safety in a way not already demonstrated acceptable + +Changes that are generally NOT substantial: +- Administrative changes (company name, address) with no technical impact +- Errata corrections in labelling that do not affect safety information +- Equivalent material substitutions with documented equivalence + +--- + +## Risk Management Integration (ISO 14971:2019) + +Risk management and design controls are inseparable under ISO 13485. The risk management file (ISO 14971) must be initiated at the start of design and maintained throughout the device lifecycle. + +### ISO 14971:2019 Process Summary + +| Clause | Activity | Output | +|--------|---------|--------| +| 4 | Risk management planning | Risk management plan | +| 5 | Risk analysis | Hazard identification; risk estimation | +| 5.4 | Hazard identification | Hazard list; sequences of events | +| 5.5 | Risk estimation | Probability × Severity → Risk level | +| 6 | Risk evaluation | Compare to risk acceptability criteria | +| 7 | Risk control | Hierarchy: inherent safety → protective measures → information for safety | +| 8 | Evaluation of residual risks | Residual risk per hazard; overall residual risk | +| 9 | Risk management review and report | Summary of benefit-risk analysis; statement that overall residual risk is acceptable | +| 10 | Production/post-production information | PMS data feeds back into risk file; re-evaluation of risks if new data emerges | + +### Risk Acceptability Matrix (Example — Organisation Must Define Own Criteria) + +| | Severity 1 (Negligible) | Severity 2 (Minor) | Severity 3 (Serious) | Severity 4 (Critical) | Severity 5 (Catastrophic) | +|---|---|---|---|---|---| +| **Probability 5 (Frequent)** | Low | Medium | High | Unacceptable | Unacceptable | +| **Probability 4 (Probable)** | Low | Medium | High | Unacceptable | Unacceptable | +| **Probability 3 (Occasional)** | Low | Low | Medium | High | Unacceptable | +| **Probability 2 (Remote)** | Acceptable | Low | Medium | High | High | +| **Probability 1 (Improbable)** | Acceptable | Acceptable | Low | Medium | High | + +Legend: Acceptable = no action; Low = review; Medium = control measures required; High = risk reduction mandatory; Unacceptable = design must be changed + +--- + +## Design Review Record Template + +``` +DESIGN REVIEW RECORD +Review ID: DR-[number] +Device: [Device Name] +Phase Gate: [Phase number and name] +Date: [Date] +Location / Method: [In-person / video conference / hybrid] + +ATTENDEES: +Name | Role | Department | Signature +[Engineering Lead | Sr. Engineer | R&D | ] +[Regulatory Affairs | RA Manager | Quality/Regulatory | ] +[Quality Assurance | QA Engineer | Quality | ] +[Clinical/Medical | Clinical Advisor | Clinical Affairs | ] +[Manufacturing | Mfg Engineer | Operations | ] + +REVIEW AGENDA: +1. Actions from previous design review — status update +2. Design inputs status +3. Design outputs review +4. Verification/validation status +5. Risk management update (open risks, controls implemented) +6. Regulatory status +7. Any open issues / nonconformances affecting design + +REVIEW FINDINGS: +Finding ID | Description | Risk Level | Assigned To | Due Date | Disposition +DR-[n]-01 | | | | | + +GATE DECISION: +[ ] PASS — Proceed to next phase +[ ] CONDITIONAL PASS — Proceed with open actions listed above (all must be closed before Phase [n+1] begins) +[ ] FAIL — Do not proceed; return to [specify phase/activity] + +Chaired by: _______________ Date: _______________ +Quality approved by: _______________ Date: _______________ +``` diff --git a/plugins/iso13485/skills/iso13485/references/iso13485-regulatory-mapping.md b/plugins/iso13485/skills/iso13485/references/iso13485-regulatory-mapping.md new file mode 100644 index 0000000..cc4d2d7 --- /dev/null +++ b/plugins/iso13485/skills/iso13485/references/iso13485-regulatory-mapping.md @@ -0,0 +1,235 @@ +# ISO 13485:2016 — Regulatory Mapping Reference + +## Overview + +ISO 13485:2016 is recognised by regulatory authorities globally as the appropriate QMS standard for medical device manufacturers. Certification to ISO 13485:2016 is required or accepted as evidence of QMS compliance across multiple jurisdictions. However, ISO 13485 alone does not confer regulatory approval — additional country-specific requirements apply. + +This document maps ISO 13485:2016 clauses to the primary regulatory frameworks: +- **EU MDR 2017/745** and **EU IVDR 2017/746** — European Union +- **FDA 21 CFR Part 820 / QMSR** — United States +- **Health Canada SOR/98-282** — Canada +- **TGA Therapeutic Goods (Medical Devices) Regulations 2002** — Australia (MDSAP) +- **MHLW Pharmaceutical and Medical Device Act (PMD Act)** — Japan (MDSAP) +- **MDSAP** — Medical Device Single Audit Program + +--- + +## EU MDR 2017/745 — ISO 13485 Mapping + +The EU Medical Device Regulation 2017/745 came into full effect on 26 May 2021. ISO 13485:2016 QMS certification is required for all manufacturers seeking CE marking. Notified bodies assess the QMS against Annex IX (Part A for QMS) or Annex XI for product conformity. + +| ISO 13485:2016 Clause | EU MDR Requirement | EU MDR Reference | Notes | +|----------------------|-------------------|-----------------|-------| +| 4.1 — QMS general | QMS establishment and maintenance | Annex IX, Part A, Section 1 | ISO 13485 QMS certificate required for Class IIa, IIb, III | +| 4.2.2 — Quality manual | QMS documentation | Annex IX, Section 3.1 | Manual must reference technical documentation scope | +| 4.2.3 — Medical device file | Technical documentation | Annex II (general TD); Annex III (post-market TD) | EU MDR specifies Annex II content explicitly — more detailed than IS0 13485 MDF | +| 5.3 — Quality policy | Policy statement | Annex IX, Section 3.1 | — | +| 5.6 — Management review | Management review | Annex IX, Section 3.6 | Review must include post-market surveillance data | +| 6.2 — Human resources | Competence requirements | Art. 10(9); Annex IX, Section 3.3 | Person Responsible for Regulatory Compliance (PRRC) required under Art. 15 | +| 7.1 — Planning and risk management | Risk management | Art. 10(2); Annex I GSPR | Risk management must conform to ISO 14971:2019; GSPR compliance required | +| 7.2 — Customer requirements | Intended purpose / intended use | Annex II, Section 1 | Intended use must be documented and consistent across all TD | +| 7.3 — Design and development | Technical documentation; conformity assessment | Annex II, Sections 1–6 | Full design history documentation required in Technical Documentation | +| 7.3.7 — Validation (clinical) | Clinical evaluation | Art. 61; Annex XIV | Clinical evaluation report (CER) mandatory; continuous PMCF required | +| 7.4 — Purchasing / suppliers | Supply chain management | Annex IX, Section 3.8 | Supplier controls and quality agreements required | +| 7.5.5/7.5.7 — Sterilisation | Sterile medical devices | Annex I, Chapter II, GSPR 11 | Sterility maintenance and validation per applicable standards | +| 7.5.8 — Identification | UDI assignment and registration | Art. 27; Annex VI | UDI required for all devices; registration in EUDAMED required | +| 7.5.9 — Traceability | Traceability and distribution records | Art. 10(8); Art. 25 | Distributors and importers have specific traceability obligations | +| 7.6 — Calibration | Measurement equipment | Annex I, Chapter III, GSPR 23 | Measuring calibration linked to safety and performance verification | +| 8.2.1 — Feedback | Post-market surveillance system | Art. 83–86; Annex III | PMS system mandatory; active and passive surveillance | +| 8.2.2 — Complaint handling | Complaint handling | Art. 87; Annex III | Feeds into vigilance system | +| 8.2.3 — Regulatory reporting | Vigilance reporting | Art. 87–89 | Serious incident reporting timeframes: 2 days (death) / 15 days (serious incident) / before FSCA | +| 8.3 — NC product | Field safety corrective actions | Art. 87(5); Art. 10(11) | FSCA and FSN requirements defined; competent authority notification required | +| 8.5.2 — Corrective action | CAPA system | Annex IX, Section 3.7 | CAPA logs reviewed at surveillance audits | + +### Additional EU MDR Requirements (beyond ISO 13485) + +The following EU MDR requirements have no direct ISO 13485 equivalent: + +| Requirement | EU MDR Reference | Description | +|------------|-----------------|-------------| +| PRRC (Person Responsible for Regulatory Compliance) | Art. 15 | At least one person with defined qualifications (degree in law, medicine, pharmacy, engineering, or equivalent, plus min. 1 year experience in regulatory affairs or QMS in medical devices) | +| PSUR (Periodic Safety Update Report) | Art. 86 | Class IIa: every 2 years; Class IIb/III: annually | +| SSCP (Summary of Safety and Clinical Performance) | Art. 32 | Required for Class III implantable devices and Class III / Class IIb devices as applicable; publicly available | +| PMCF (Post-Market Clinical Follow-Up) | Annex XIV, Part B | Systematic method for collection and evaluation of clinical data after market placement | +| Unique Device Identification (UDI) | Art. 27; Annex VI | All devices must have UDI-DI (device identifier) and UDI-PI (production identifier); registered in EUDAMED | +| EUDAMED registration | Art. 29–31 | Registration of manufacturer, device, and certificates in EU database | +| Economic operator obligations | Art. 10–14 | Importers and distributors have obligations for labelling, language requirements, and storage/transport conditions | + +### EU MDR Device Classification + +| Class | Description | Conformity Assessment Route | +|-------|------------|---------------------------| +| Class I (non-sterile, non-measuring) | Lowest risk | Self-declaration (no NB) | +| Class I sterile / Class I measuring | Moderate | NB involvement for sterile/measuring aspects only | +| Class IIa | Medium-low risk | NB audit (Annex IX or XI) | +| Class IIb | Medium-high risk | NB audit (Annex IX or X or XI) | +| Class III | High risk (incl. all implantables) | NB audit with design examination (Annex IX or X) | + +--- + +## FDA 21 CFR Part 820 — Quality Management System Regulation (QMSR) + +The FDA published the updated Quality Management System Regulation (QMSR) on 2 February 2024 (effective 6 February 2026). The QMSR explicitly incorporates ISO 13485:2016 by reference, aligning FDA requirements directly with the international standard. + +The predecessor Quality System Regulation (QSR, 21 CFR Part 820 pre-2024) used different terminology but required equivalent controls. The QMSR alignment table: + +| ISO 13485:2016 Clause | FDA QMSR Reference | FDA-Specific Notes | +|----------------------|-------------------|-------------------| +| 4.1 — QMS | 21 CFR 820.20(a) | Documented QMS required; FDA may inspect | +| 4.2.2 — Quality manual | 21 CFR 820.20(e) | DMR is FDA equivalent of the design history / device master record | +| 4.2.3 — Medical device file | 21 CFR 820.181 — Device Master Record (DMR) 21 CFR 820.184 — Device History Record (DHR) | DHF (Design History File): 21 CFR 820.30(j) DMR: specifications for each device type DHR: production evidence per lot/batch | +| 4.2.4 — Document control | 21 CFR 820.40 | Equivalent; same intent | +| 4.2.5 — Record control | 21 CFR 820.180 | Minimum 2 years from date of release (or device design lifetime if shorter for some records); for implantable devices where design lifetime > 2 years, retain accordingly | +| 5.1 — Management commitment | 21 CFR 820.20(a)–(b) | Management with executive responsibility must establish quality policy | +| 5.5.2 — Management rep | 21 CFR 820.20(b)(3) | Required — must have authority to ensure QMS requirements are met | +| 5.6 — Management review | 21 CFR 820.20(c) | Reviews must be documented; must include review of NCs, CAPAs, audit results | +| 6.2 — Human resources | 21 CFR 820.25 | Personnel must have training for job function; training records required | +| 6.3 — Infrastructure | 21 CFR 820.70(f)(g) | Buildings, equipment, maintenance records | +| 6.4 — Work environment | 21 CFR 820.70(c)(d)(e) | Environmental controls; cleanliness; contamination control | +| 7.3 — Design controls | 21 CFR 820.30 | FDA explicitly requires design controls for finished device manufacturers regardless of ISO 13485 exclusion | +| 7.3.10 — DHF | 21 CFR 820.30(j) | Design History File — mandatory location of all design records | +| 7.4 — Purchasing | 21 CFR 820.50 | Purchasing controls; supplier evaluation | +| 7.5.1 — Production | 21 CFR 820.70 | Production and process controls | +| 7.5.6 — Process validation | 21 CFR 820.75 | Process validation required where output cannot be fully verified | +| 7.5.8 — Identification | 21 CFR 820.60 | Device identification required throughout production | +| 7.5.9 — Traceability | 21 CFR 820.65 | Each finished device must be traceable to its DMR | +| 7.6 — Calibration | 21 CFR 820.72 | Calibration procedures; records of calibration; calibration intervals | +| 8.2.2 — Complaints | 21 CFR 820.198 | Complaint files — written complaint procedure; review all complaints; investigate all MDR-reportable complaints | +| 8.2.3 — Regulatory reporting | 21 CFR Part 803 | Medical Device Reporting (MDR) — mandatory 30-day / 5-day reports | +| 8.2.4 — Internal audit | 21 CFR 820.22 | Written audit procedure; qualified auditor; documented results; management review | +| 8.3 — NC product | 21 CFR 820.90 | Procedures for NC identification, documentation, review, and disposition | +| 8.5.2 — CAPA | 21 CFR 820.100 | Written CAPA procedure; root cause analysis; verification of effectiveness; management review involvement | + +### FDA-Specific Records — Device Master Record (DMR) + +Under FDA QMSR / 21 CFR 820.181, the DMR must include or reference: +- Device specifications (drawings, composition, formulation, component specifications, software specifications) +- Production process specifications (equipment, tools, methods, work environment) +- Quality assurance procedures and specifications (acceptance criteria, sampling plans, testing) +- Packaging and labelling specifications +- Installation, maintenance, and servicing procedures (if applicable) + +### FDA Medical Device Reporting (MDR) — 21 CFR Part 803 + +| Reporter Type | Event | Timeframe | +|-------------|-------|-----------| +| Manufacturer | Death or serious injury caused or may have contributed to | 30 calendar days | +| Manufacturer | Malfunction that would likely cause/contribute to death/serious injury if it recurs | 30 calendar days | +| Manufacturer | Events requiring remedial action to prevent unreasonable risk of substantial harm | 5 work days | +| User facility (hospital etc.) | Death | 10 work days to FDA and manufacturer | +| User facility | Serious injury | 10 work days to manufacturer | +| Importer | Death or serious injury | 30 days to FDA and manufacturer | + +--- + +## MDSAP — Medical Device Single Audit Program + +MDSAP was established to allow a single audit of a medical device manufacturer's QMS to satisfy the requirements of multiple regulatory jurisdictions. + +| Participating Authority | Country | Jurisdiction | +|------------------------|---------|-------------| +| TGA | Australia | Australian Register of Therapeutic Goods (ARTG) | +| ANVISA | Brazil | Brazilian market — MDSAP certificate required for registration | +| Health Canada | Canada | Replaces mandatory Medical Device Establishment Licence audit | +| MHLW | Japan | QMS ordinance compliance | +| FDA | USA | MDSAP certificate considered in lieu of FDA routine inspection (not exemption) | + +### MDSAP Audit Approach + +MDSAP audits are structured around 7 processes that map to ISO 13485:2016 clauses: + +| MDSAP Process | ISO 13485 Clauses | Description | +|--------------|------------------|-------------| +| Process 1: Management | 4.1, 4.2, 5.1–5.6 | QMS documentation, management commitment, management review | +| Process 2: Device marketing authorisation and facility registration | Regulatory requirements | Registration, market authorisation, regulatory submissions | +| Process 3: Design and development | 7.1, 7.3 | Design controls, design history file, clinical evaluation | +| Process 4: Production and service controls | 7.5.1–7.5.11, 7.6 | Production, sterilisation, traceability, calibration | +| Process 5: Purchasing | 7.4 | Supplier management, purchasing controls | +| Process 6: Measurement, analysis, and improvement | 8.1–8.5 | Complaint handling, audits, CAPA, NC product | +| Process 7: Human resources and infrastructure | 6.1–6.4 | Competence, infrastructure, work environment | + +MDSAP uses a grading system: +- **Grade 1 — Major (critical):** Significant failure in QMS; immediate regulatory action may follow +- **Grade 2 — Major:** Serious QMS failure; must be corrected in defined timeframe +- **Grade 3 — Minor:** QMS process partially ineffective; corrective action required +- **Grade 4 — Observation/improvement opportunity:** Not a deficiency; recommendation only + +--- + +## Health Canada — Medical Device Regulations SOR/98-282 + +Health Canada classifies medical devices in four classes (Class I–IV, similar to EU risk-based classification). ISO 13485:2016 certification is required for Class II, III, and IV device licences. + +| ISO 13485 Clause | Health Canada Requirement | HC Reference | +|-----------------|--------------------------|-------------| +| 4–8 (QMS) | ISO 13485 certification required | SOR/98-282, Section 32 | +| 8.2.2 | Complaint handling | MDSAP Process 6 | +| 8.2.3 | Mandatory problem reporting (MPR) | HC Medical Devices: Mandatory Problem Reporting | +| 7.5.9 | Distribution records | SOR/98-282, Section 57 | + +Health Canada mandatory problem reporting timeframes: +- Death or serious deterioration: 10 days +- Other — 30 days + +--- + +## TGA — Australia + +The Therapeutic Goods Administration (TGA) recognises MDSAP certificates for market access. Australian Conformity Assessment Bodies (ACABs) perform ISO 13485 audits. + +| ISO 13485 Clause | TGA Requirement | TGA Reference | +|-----------------|----------------|--------------| +| 4–8 (QMS) | ISO 13485 certification (or equivalent) | Therapeutic Goods (Medical Devices) Regulations 2002 | +| 8.2.3 | Adverse event reporting | TGA adverse event reporting guidelines | +| Regulatory pathway | ARTG registration / inclusion | Depends on device class | + +TGA device classification broadly mirrors EU MDR: +- Class I → Class I sterile/measuring → Class IIa → Class IIb → Class III (highest risk) + +--- + +## MHLW — Japan (PMD Act) + +Japan's Pharmaceutical and Medical Device (PMD) Act requires manufacturers and marketing authorisation holders to implement a QMS consistent with ISO 13485. The Ministry of Health, Labour and Welfare (MHLW) QMS Ordinance was revised in 2021 to align with ISO 13485:2016. + +| ISO 13485 Clause | MHLW / PMD Act Requirement | MHLW Reference | +|-----------------|---------------------------|----------------| +| 4–8 (QMS) | QMS Ordinance (MHLW Ministerial Ordinance No. 169 as revised) | QMS certification required for Class III and IV devices | +| 8.2.3 | Adverse event reporting (JADER system) | PMD Act Article 68-10 | +| 7.3 | Design controls | QMS Ordinance Chapter 3 | + +--- + +## Summary: Market Access Requirements by Jurisdiction + +| Market | QMS Requirement | Conformity Assessment | Additional Requirements | +|--------|----------------|----------------------|------------------------| +| European Union | ISO 13485 + Annex IX/XI QMS audit | Notified Body for Class IIa+ | Technical documentation, clinical evaluation, UDI, EUDAMED, PRRC | +| United States | FDA QMSR (aligned ISO 13485) | FDA inspection (MDSAP accepted) | 510(k) / PMA / De Novo; MDR reporting; establishment registration | +| Canada | ISO 13485 certification | MDSAP or Canadian CAB | Device licence; mandatory problem reporting | +| Australia | ISO 13485 certification | MDSAP or ACAB | ARTG registration; adverse event reporting | +| Japan | ISO 13485 / MHLW QMS Ordinance | MDSAP or JNAB | Marketing approval (Shonin); QMS certification for Class III/IV | +| China | ISO 13485 (and/or domestic CMDE) | CNAS or domestic authority | NMPA registration; may require domestic QMS audit | +| Brazil | ISO 13485 (MDSAP) | MDSAP or INMETRO | ANVISA registration; MDSAP certificate accepted | +| India | ISO 13485 recommended | CDSCO may inspect | MD-14 / MD Licence; ISO 13485 not yet mandatory but expected | + +--- + +## ISO 13485 and Related Supporting Standards + +The following standards provide detailed requirements referenced by ISO 13485 or its regulatory implementations: + +| Standard | Title | ISO 13485 Relevance | +|---------|-------|---------------------| +| ISO 14971:2019 | Medical devices — Risk management | Mandatory risk management process (Clause 7.1) | +| IEC 62304:2006+AMD1:2015 | Medical device software — software lifecycle | Software development and maintenance controls | +| IEC 62366-1:2015+AMD1:2020 | Medical devices — usability engineering | Usability engineering process; formative and summative evaluations | +| ISO 10993 series | Biological evaluation of medical devices | Biocompatibility testing and evaluation | +| ISO 11135:2014 | Sterilisation — EO | EO sterilisation validation and controls | +| ISO 11137 series | Sterilisation — radiation | Radiation sterilisation (gamma, electron beam, X-ray) | +| ISO 11607 series | Packaging for terminally sterilised medical devices | Sterile barrier system design, validation, and testing | +| ISO 14155:2020 | Clinical investigation of medical devices | Clinical study design and conduct for medical devices | +| ISO 15223-1 | Medical devices — symbols | Standard symbols used in labelling | +| ISO 14971:2019 | Risk management | Core risk management process | +| IEC 60601 series | Medical electrical equipment | Safety and essential performance for electrical medical devices | +| ISO 13485 aligned MDSAP audit approach | IMDRF MDSAP documents | MDSAP audit procedure, forms, and grading | diff --git a/plugins/iso13485/skills/iso13485/references/iso13485-templates.md b/plugins/iso13485/skills/iso13485/references/iso13485-templates.md new file mode 100644 index 0000000..2bfaa70 --- /dev/null +++ b/plugins/iso13485/skills/iso13485/references/iso13485-templates.md @@ -0,0 +1,779 @@ +# ISO 13485:2016 — Document Templates Reference + +## Overview + +This file contains structured templates for the most commonly required ISO 13485:2016 QMS documents. Each template includes a document control block and all sections required by the standard. + +Templates provided: +1. Quality Manual (outline and section guide) +2. CAPA Form +3. Nonconformance Report (NCR) Form +4. Complaint Record Form +5. Management Review Meeting Agenda and Record +6. Internal Audit Plan and Report +7. Supplier Evaluation Form +8. Design Change Request Form +9. Process Validation Protocol Outline +10. Risk Management Plan (ISO 14971) Outline + +--- + +## Template 1 — Quality Manual Outline + +``` +[ORGANISATION NAME] +QUALITY MANUAL + +Document ID: QM-001 +Version: [X.X] +Author: [Quality Manager / PRRC] +Approved by: [CEO / VP Quality / Top Management] +Effective Date: [Date] +Next Review: [Date + 1 year] +Classification: Controlled Document + +REVISION HISTORY: +Version | Date | Author | Summary of Changes +1.0 | [Date] | [Name] | Initial release + +--- + +SECTION 1 — PURPOSE AND SCOPE +1.1 Purpose +This Quality Manual defines the Quality Management System (QMS) of [Organisation Name] +and demonstrates compliance with ISO 13485:2016. + +1.2 Scope of QMS +The QMS covers: +[Describe the scope using product types, device families, processes, and sites covered] + +Example: "The design, development, manufacture, and distribution of [device types] at +[site address(es)]." + +1.3 Exclusions (Clause 7 only — must be justified) +Clause [e.g., 7.3 — Design and Development] is excluded from the scope of this QMS because: +[Justification — e.g., "The organisation manufactures exclusively to customer-provided +complete design documentation. No design authority is held by this organisation."] + +Clauses 7.5.3 (Installation) and 7.5.4 (Servicing) are excluded because: +[Justification — e.g., "Products are sold direct to hospitals; installation and servicing +are performed by the hospital clinical engineering team."] + +--- + +SECTION 2 — ORGANISATION +2.1 Organisation overview +[Brief description of the organisation, products, markets, key sites] + +2.2 Organisational structure +[Refer to Organisation Chart — separate document, or include here] + +2.3 Roles with quality responsibility +Role | Responsibility | Clause Reference +Top Management | Quality policy; management commitment; resource provision | 5.1 +Management Representative | QMS implementation; regulatory compliance reporting | 5.5.2 +Quality Assurance Manager | QMS maintenance; CAPA; audits; document control | 4.2, 8.2.4, 8.5.2 +Regulatory Affairs Manager | Regulatory submissions; regulatory change monitoring | 5.2, 8.2.3 +Production Manager | Production controls; process compliance | 7.5.1 +R&D / Engineering Manager | Design and development (if in scope) | 7.3 + +--- + +SECTION 3 — QUALITY MANAGEMENT SYSTEM (Clause 4) +3.1 QMS documentation structure +[Describe the documentation hierarchy — typically: Quality Manual → SOPs → Work Instructions → Forms/Records] + +3.2 Document control +[Reference SOP-DC-001 — Control of Documents] + +3.3 Record control +[Reference SOP-RC-001 — Control of Records] +Record retention policy: Minimum [device design lifetime] + 2 years, with a minimum of +[specify — e.g., 10 years]. Implantable device records: minimum 15 years or device +design lifetime + 2 years (whichever is longer). + +3.4 Medical Device File +A Medical Device File (MDF) / Device Master Record is maintained for each device type +or family. [Reference MDF index or device file procedure] + +--- + +SECTION 4 — MANAGEMENT RESPONSIBILITY (Clause 5) +4.1 Management commitment +[Reference management commitment statement and quality policy] + +4.2 Quality policy +[Include or reference the signed quality policy document] + +4.3 Quality objectives +Quality objectives are established, documented, and reviewed at management review. +[Reference Quality Objectives Register — QBJ-001] + +4.4 Management review +Management reviews are conducted [frequency — e.g., annually or more frequently if +quality trends indicate]. [Reference SOP-MR-001] + +--- + +SECTION 5 — RESOURCE MANAGEMENT (Clause 6) +5.1 Human resources and competence +[Reference Competence Matrix and Training Records procedure] + +5.2 Infrastructure +Infrastructure is maintained per the infrastructure maintenance schedule. +[Reference Infrastructure Maintenance Procedure] + +5.3 Work environment +[Reference Work Environment Control procedure — including environmental monitoring +if applicable for cleanroom / controlled environment production] + +--- + +SECTION 6 — PRODUCT REALIZATION (Clause 7) +6.1 Planning +[Reference Quality Plan procedure and Risk Management SOP] + +6.2 Customer-related processes +[Reference Customer Requirements and Order Review procedure] + +6.3 Design and development +[Reference Design Controls procedure — SOP-DD-001 — or state exclusion with justification] + +6.4 Purchasing +[Reference Purchasing and Supplier Management procedure — SOP-PUR-001] + +6.5 Production and service provision +[Reference Production Controls procedure / Work Instructions] + +6.6 Control of monitoring and measuring equipment +[Reference Calibration and Measurement Equipment Control procedure] + +--- + +SECTION 7 — MEASUREMENT, ANALYSIS, AND IMPROVEMENT (Clause 8) +7.1 Monitoring and measurement +[Reference Feedback, Complaint Handling, and Internal Audit procedures] + +7.2 Control of nonconforming product +[Reference NC Product Control procedure — SOP-NC-001] + +7.3 Analysis of data +Data is collected and analysed from feedback, audits, process performance, and NC +product. Analysis outputs are reviewed at management review. + +7.4 Improvement +[Reference CAPA procedure — SOP-CAPA-001] + +--- + +SECTION 8 — RELATED DOCUMENTS +8.1 Procedures and work instructions +[List all controlled SOPs and work instructions or reference the Master Document List] + +8.2 Forms and templates +[Reference forms register or list key forms] + +--- + +APPENDIX A — PROCESS INTERACTION MAP +[Diagram or table showing how core QMS processes interact, with clause references] +``` + +--- + +## Template 2 — CAPA Form + +``` +CORRECTIVE AND PREVENTIVE ACTION RECORD + +CAPA ID: CAPA-[YYYY]-[NNN] +Type: [ ] Corrective Action [ ] Preventive Action +Date Opened: [Date] +Priority: [ ] Critical [ ] Major [ ] Minor +Opened by: [Name / Role] + +SOURCE OF CAPA: +[ ] Complaint (Complaint ID: __________) +[ ] Internal audit (Audit ID: __________) +[ ] External audit (Auditor: __________) +[ ] NC product (NCR ID: __________) +[ ] Process performance data +[ ] Post-market surveillance / feedback +[ ] Management review +[ ] Regulatory authority finding +[ ] Employee / supplier observation +[ ] Other: __________ + +SECTION 1 — PROBLEM STATEMENT +Describe the problem clearly (What, When, Where, Who, How often): +[Free text — be specific and factual] + +Device / product affected (if applicable): [Description + lot/serial/UDI if applicable] +Regulatory markets potentially affected: [ ] EU [ ] USA [ ] Canada [ ] Australia [ ] Japan [ ] Other + +SECTION 2 — IMMEDIATE CONTAINMENT ACTIONS +Actions taken to contain the problem and prevent further impact: +Action | Responsible | Completed Date +| | +| | + +Containment actions completed by: [Date] +Confirmed by (QA): [Name / Date] + +SECTION 3 — ROOT CAUSE ANALYSIS +Method used: [ ] 5-Why [ ] Fishbone / Ishikawa [ ] Fault Tree Analysis [ ] Other: ________ + +5-Why analysis (if used): +Why 1: [Problem description] → Because: [Answer 1] +Why 2: [Answer 1] → Because: [Answer 2] +Why 3: [Answer 2] → Because: [Answer 3] +Why 4: [Answer 3] → Because: [Answer 4] +Why 5: [Answer 4] → Because: [Root cause] + +Root cause identified: +[Clear statement of root cause] + +Contributing factors (if any): +[Contributing factor 1] +[Contributing factor 2] + +Evidence supporting root cause determination: +[Reference data, records, analysis results] + +SECTION 4 — CORRECTIVE / PREVENTIVE ACTIONS + +Action | Responsible person | Target Date | Completion Date | Evidence reference +| | | | +| | | | +| | | | + +SECTION 5 — EFFECTIVENESS VERIFICATION + +Verification method: [ ] Re-audit [ ] Data trend analysis [ ] Re-inspection [ ] Surveillance [ ] Other +Verification criteria (define what "effective" means): +[Quantitative or qualitative criterion, e.g., "Zero recurrence of similar NCs in next 3 internal audits"] + +Verification performed by: [Name / Role] +Verification date: [Date] +Verification results: [ ] Effective — CAPA may be closed [ ] Not Effective — CAPA remains open; extend actions + +Evidence of verification: +[Reference records, audit report, data set] + +SECTION 6 — CLOSURE + +All actions completed: [ ] Yes [ ] No (if No, CAPA remains open) +Regulatory reporting required: [ ] Yes (reference report number: ________) [ ] No +Related CAR / NCR closed: [ ] Yes [ ] N/A +Documents updated: [ ] Yes — list: _________ [ ] No — justification: _________ + +Closed by (QA): [Name] _________________ Date: _____________ +Approved by (Management): [Name] _________________ Date: _____________ +``` + +--- + +## Template 3 — Nonconformance Report (NCR) Form + +``` +NONCONFORMANCE REPORT + +NCR ID: NCR-[YYYY]-[NNN] +Date raised: [Date] +Raised by: [Name / Role] +Department/Location: [Location where NC discovered] + +PRODUCT / PROCESS DETAILS: +Product name / description: [Product] +Part number / model: [Number] +Lot / batch number: [Number] +Serial number(s): [Numbers] +UDI (if applicable): [UDI string] +Quantity affected: [Number and unit] + +NONCONFORMANCE DESCRIPTION: +Requirement not met (reference clause/specification/drawing): [Reference] +Description of nonconformity: [Factual description — what was found, not why] +Where detected: [ ] Incoming inspection [ ] In-process [ ] Final inspection [ ] Post-delivery / customer + +Potentially affected downstream: [ ] Yes — specify extent: _____________ [ ] No [ ] Unknown + +DISPOSITION DECISION (8.3): +Disposition: [ ] Accept as-is (concession) [ ] Rework [ ] Regrade [ ] Reject/Scrap [ ] Return to supplier + +Concession justification (if accept as-is): +[Risk assessment reference; justification that product remains safe and effective despite NC] +Customer / regulatory approval required for concession: [ ] Yes (approval obtained — reference: ________) [ ] No + +Rework instructions reference (if rework): SOP-RW-_________ + +Person authorising disposition: [Name] _________________ Role: _________ Date: _________ + +POST-REWORK INSPECTION (if rework performed): +Re-inspection results: [ ] Pass [ ] Fail +Inspection records reference: [Reference] +Inspected by: [Name] _________________ Date: _________ + +CAPA REQUIRED? +[ ] Yes — CAPA opened: CAPA-[YYYY]-[NNN] +[ ] No — Justification (e.g., isolated occurrence, no systemic root cause): [Justification] + +NCR CLOSED BY (QA): [Name] _________________ Date: _____________ +``` + +--- + +## Template 4 — Complaint Record Form + +``` +COMPLAINT RECORD + +Complaint ID: COMP-[YYYY]-[NNN] +Date received: [Date] +Received by: [Name / Role] +Received via: [ ] Phone [ ] Email [ ] Field service [ ] Distributor [ ] Direct customer [ ] Regulatory authority [ ] Other + +COMPLAINANT INFORMATION: +Name: [Or anonymous if preference stated] +Organisation: [Hospital, clinic, distributor name] +Country: [Country] +Contact details: [Email / phone — if provided] + +DEVICE INFORMATION: +Product name: [Product] +Model / catalogue number: [Number] +Lot / serial number: [Number] +UDI: [UDI string if applicable] +Date of manufacture (if known): [Date] +Date of alleged incident: [Date] + +COMPLAINT DESCRIPTION: +[Full description of complaint as reported by complainant] + +Patient outcome (if applicable): +[ ] Death [ ] Serious injury [ ] Non-serious injury [ ] No patient harm [ ] Unknown + +INITIAL TRIAGE: +Potential regulatory reportable event: [ ] Yes [ ] No [ ] Under investigation +Immediate safety concern requiring containment: [ ] Yes — action taken: _________ [ ] No +FSCA trigger assessment required: [ ] Yes [ ] No + +INVESTIGATION: +Investigated by: [Name / Role] +Investigation start date: [Date] +Device returned for analysis: [ ] Yes [ ] No +Analysis results summary: [Findings from device analysis] +Root cause (final): [Root cause determination] +Root cause category: [ ] Manufacturing defect [ ] Design issue [ ] User error [ ] Labelling/IFU issue [ ] Storage/transport [ ] Unknown [ ] Other + +REGULATORY REPORTING: +Report required: [ ] Yes [ ] No +Report type: [ ] EU MDR Vigilance [ ] FDA MDR (803) [ ] Health Canada MPR [ ] TGA [ ] MHLW [ ] Other +Report reference number: [Number] +Date submitted: [Date] + +CORRECTIVE ACTION: +CAPA required: [ ] Yes — CAPA ID: CAPA-_________ [ ] No +Action taken: [Description] + +CLOSURE: +Communication to complainant: [ ] Yes [ ] No [ ] Not appropriate +Closure summary: [Brief summary of outcome and actions] +Closed by: [Name] _________________ Date: _____________ +QA review: [Name] _________________ Date: _____________ +``` + +--- + +## Template 5 — Management Review Meeting Record + +``` +MANAGEMENT REVIEW RECORD + +Meeting ID: MR-[YYYY]-[N] +Date: [Date] +Location: [Location / virtual] +Next scheduled review: [Date] + +ATTENDEES: +Name | Role | Present (Y/N) +[CEO / Managing Director | Top Management | ] +[Quality Manager | QA | ] +[Regulatory Affairs Manager | RA | ] +[Production Manager | Operations | ] +[R&D / Engineering Manager | Engineering (if D&D in scope) | ] +[Sales / Marketing Manager | Commercial | ] + +AGENDA AND INPUTS (ISO 13485:2016 Clause 5.6.2): + +1. Actions from previous management review + Status of open actions from MR-[previous ID]: + [List open actions, responsible person, updated status] + +2. Results of audits + Internal audits: [Summary — number of findings, open CAPAs] + External audits (NB / FDA / MDSAP): [Findings, certificates status] + +3. Customer feedback + Complaint summary (period [dates]): + - Total complaints received: [Number] + - Serious complaints: [Number] + - Regulatory reports filed: [Number] + - Trending: [Improving / Stable / Declining / Concerning] + Other feedback (distributor, post-market surveillance data): + +4. Process performance and product conformity + KPI summary: + KPI | Target | Actual | Trend + On-time delivery | ≥95% | [%] | [+/-/=] + First pass yield | ≥[X]% | [%] | [+/-/=] + Complaint rate per unit | ≤[X] | [Rate] | [+/-/=] + NC product rate | ≤[X]% | [%] | [+/-/=] + CAPA closure on-time | ≥90% | [%] | [+/-/=] + +5. Status of corrective and preventive actions + Open CAPAs: [Number] — [brief status summary] + CAPAs closed since last review: [Number] + +6. Changes affecting the QMS + Regulatory changes: [Describe any new/revised regulations, standards] + Product/process changes: [Describe any significant changes] + Organisational changes: [Describe any restructuring, key personnel changes] + +7. New or revised regulatory requirements + [List any new or revised regulatory requirements applicable to markets in scope] + +8. Recommendations for improvement + [List recommendations raised] + +9. Any other business + +OUTPUT DECISIONS AND ACTIONS (Clause 5.6.3): +Action | Responsible Person | Due Date +| | +| | + +QUALITY OBJECTIVES REVIEW: +Objective | Target | Status | Action (if missed) +| | | +| | | + +QMS SUITABILITY DETERMINATION: +The QMS is determined to be: [ ] Suitable and effective [ ] Suitable with improvement actions (see above) +[ ] Requires significant revision — action plan attached + +Chaired by: [Name] / [Role] _________________ Date: _____________ +Quality Manager review: [Name] _________________ Date: _____________ + +Minutes distributed to: All attendees [Date: _____________] +``` + +--- + +## Template 6 — Internal Audit Plan and Report Outline + +``` +INTERNAL AUDIT PLAN + +Audit ID: AUD-[YYYY]-[NNN] +Planned date(s): [Date(s)] +Lead auditor: [Name / Qualification] +Audit team: [Names] +Audit scope: [Clauses / processes / departments in scope] +Audit criteria: ISO 13485:2016; applicable regulatory requirements; [Organisation]-QMS documented procedures + +AUDIT SCHEDULE: +Date / Time | Area / Process | Clause(s) | Auditee(s) | Auditor +| | | | +| | | | + +OPENING MEETING: [Date / Time] +CLOSING MEETING: [Date / Time] + +--- + +INTERNAL AUDIT REPORT + +Audit ID: AUD-[YYYY]-[NNN] +Audit dates: [Dates] +Audit scope: [Scope as above] +Standard(s): ISO 13485:2016 + +SUMMARY OF FINDINGS: +Finding type | Number +Major nonconformity | [Number] +Minor nonconformity | [Number] +Observation / Opportunity for improvement | [Number] + +MAJOR NONCONFORMITIES: +Finding ID | Clause | Description | Evidence | Required action +| | | | + +MINOR NONCONFORMITIES: +Finding ID | Clause | Description | Evidence | Required action +| | | | + +OBSERVATIONS: +Finding ID | Clause | Description +| | + +POSITIVE FINDINGS (commendations): +[List areas of good practice noted during audit] + +AUDIT CONCLUSION: +Overall QMS suitability: [ ] Satisfactory [ ] Satisfactory with actions [ ] Unsatisfactory + +CAPA REQUIRED FOR NONCONFORMITIES: [ ] Yes — CAPA IDs: ___________ + +Lead auditor signature: _________________ Date: _____________ +Auditee management acknowledgement: _________________ Date: _____________ +QA Manager review: _________________ Date: _____________ +``` + +--- + +## Template 7 — Supplier Evaluation Form + +``` +SUPPLIER EVALUATION RECORD + +Evaluation ID: SUP-EVAL-[YYYY]-[NNN] +Supplier name: [Name] +Supplier address: [Address] +Date of evaluation: [Date] +Evaluator: [Name / Role] +Evaluation type: [ ] Initial qualification [ ] Periodic re-evaluation [ ] For cause + +PRODUCTS / SERVICES SUPPLIED: +[List products, components, or services under evaluation] + +SUPPLIER CRITICALITY: +[ ] Critical (affects device safety or performance directly) +[ ] Major (significant quality impact) +[ ] Minor (indirect quality impact) + +EVALUATION CRITERIA: +Criterion | Score (1–5) | Weight | Weighted Score | Notes +ISO 13485 / equivalent certification | | 0.25 | | +Quality system documentation | | 0.15 | | +Product quality history (NC rate, delivery) | | 0.20 | | +Complaint response / CAPA effectiveness | | 0.15 | | +Regulatory compliance (FDA, EU MDR as applicable) | | 0.15 | | +Change notification process | | 0.10 | | +TOTAL WEIGHTED SCORE | | | | + +Score key: 5 = Excellent; 4 = Good; 3 = Acceptable; 2 = Below expectation; 1 = Unacceptable + +QUALIFICATION DECISION: +[ ] APPROVED — Add to Approved Supplier List (ASL) +[ ] CONDITIONALLY APPROVED — Conditions: [List conditions] +[ ] NOT APPROVED — Reason: [Reason] + +Quality Agreement required: [ ] Yes [ ] No (minor supplier only) +On-site audit required: [ ] Yes (scheduled: _____) [ ] No +Next re-evaluation due: [Date / interval / event trigger] + +Evaluated by: [Name] _________________ Date: _____________ +QA Manager approval: [Name] _________________ Date: _____________ +Added to ASL: [ ] Yes [ ] No ASL version updated: [Version] +``` + +--- + +## Template 8 — Design Change Request Form + +``` +DESIGN CHANGE REQUEST + +DCR ID: DCR-[YYYY]-[NNN] +Date raised: [Date] +Raised by: [Name / Role] +Device / product: [Device name] +Current document revision affected: [Drawing No. / Spec No. / Software Version] + +CHANGE DESCRIPTION: +Current state (what exists today): [Description] +Proposed change (what is changing): [Description] +Reason for change (clinical, quality, regulatory, manufacturing, cost, other): [Reason] + +IMPACT ASSESSMENT: + +Impact Area | Affected? | Assessment / Actions Required +Design inputs (7.3.3) | Y/N | +Design outputs (7.3.4) | Y/N | +Risk management / ISO 14971 | Y/N | +Verification required | Y/N | Protocols: ___________ +Validation required | Y/N | Protocols: ___________ +Biocompatibility (ISO 10993) | Y/N | +Software (IEC 62304) | Y/N | +Sterilisation (processes, validation) | Y/N | +Labelling / IFU / UDI | Y/N | +Packaging / shelf life | Y/N | +Supplier / component change | Y/N | +Manufacturing process | Y/N | +Device Master Record update | Y/N | Documents: ___________ + +REGULATORY ASSESSMENT: +EU MDR — Substantial modification? [ ] Yes [ ] No [ ] TBD +If Yes: [ ] NB notification required [ ] New NB application required +FDA — New regulatory submission required? [ ] Yes — Type: ________ [ ] No +Other markets affected: [List] + +CHANGE APPROVAL: +Function | Name | Signature | Date +Engineering | | | +Quality Assurance | | | +Regulatory Affairs | | | +Manufacturing | | | +Clinical (if applicable) | | | + +CHANGE IMPLEMENTATION: +Implementation date: [Date] +Documents updated: [List document IDs and new revisions] +Training required: [ ] Yes — training record ref: _________ [ ] No +DHF updated: [ ] Yes [ ] No (if No, justification: _________) +Change closed by (QA): [Name] _________________ Date: _____________ +``` + +--- + +## Template 9 — Process Validation Protocol Outline + +``` +PROCESS VALIDATION PROTOCOL + +Protocol ID: PVP-[Process Name]-[YYYY]-[NNN] +Process to be validated: [Process name — e.g., Injection Moulding, Welding, Cleaning, Packaging Sealing] +Device / product families: [Products that use this process] +Regulation / standard reference: ISO 13485:2016 Clause 7.5.6 + +VALIDATION APPROACH: +IQ (Installation Qualification): [ ] Required [ ] Previously completed (IQ ref: _______) +OQ (Operational Qualification): [ ] Required [ ] Previously completed (OQ ref: _______) +PQ (Performance Qualification): [ ] Required [ ] Previously completed (PQ ref: _______) + +--- + +IQ — INSTALLATION QUALIFICATION +Objective: Confirm equipment is installed correctly and meets specification. +Check | Specification | Observed | Pass/Fail +Equipment model and serial number | | | +Utilities connected (power, gas, water) | | | +Safety interlocks functional | | | +Calibration of instrumentation | | | +Equipment documentation on file (manual, drawings) | | | +IQ approved by: [Name] ______ Date: ______ + +--- + +OQ — OPERATIONAL QUALIFICATION +Objective: Confirm equipment operates within defined parameter ranges under worst-case conditions. +Parameter | Low limit | Nominal | High limit | Method | Pass/Fail +[Temperature] | | | | | +[Pressure] | | | | | +[Time] | | | | | +[Speed] | | | | | + +Worst-case condition rationale: [Explain why low/high limits represent worst case] +OQ approved by: [Name] ______ Date: ______ + +--- + +PQ — PERFORMANCE QUALIFICATION +Objective: Confirm process consistently produces conforming product under production conditions. +Sample size: [Number] samples per run; [Number] runs +Sampling rationale: [Statistical justification — e.g., per ASTM or agreed sigma level] + +Test parameter | Acceptance criterion | Run 1 results | Run 2 results | Run 3 results | Status +| | | | | + +Lot-to-lot consistency: [ ] Demonstrated [ ] Not demonstrated +PQ approved by: [Name] ______ Date: ______ + +VALIDATION CONCLUSION: +The process is: [ ] VALIDATED [ ] NOT VALIDATED (see nonconformance: NCR-_______) +Revalidation triggers: [List events that require revalidation — equipment change, material change, site relocation, performance drift beyond limit, etc.] + +Protocol authored by: [Name] _________________ Date: _____________ +QA approved: [Name] _________________ Date: _____________ +``` + +--- + +## Template 10 — Risk Management Plan Outline (ISO 14971:2019) + +``` +RISK MANAGEMENT PLAN + +Document ID: RMP-[Device]-[YYYY]-[NNN] +Device: [Device name and model range] +ISO 14971 reference: ISO 14971:2019 +Date: [Date] +Prepared by: [Risk Management Owner / Role] +Approved by: [QA Manager / VP Quality] + +SECTION 1 — SCOPE AND CONTEXT +1.1 Intended use and intended users +1.2 Device description (brief) +1.3 Foreseeable misuse (reasonably foreseeable) +1.4 Regulatory markets in scope + +SECTION 2 — RISK MANAGEMENT LIFE CYCLE ACTIVITIES +Phase | Risk Management Activity | Responsible | Timing +Concept | Preliminary hazard analysis | R&D + RA | Before design inputs +Design | Risk analysis, estimation, evaluation | R&D + QA | Concurrent with D&D +Verification | Update risk controls post-testing | QA + R&D | After verification +Validation | Residual risk evaluation; benefit-risk determination | RA + QA + Clinical | Before market release +Production/Post-market | Risk monitoring and review | QA + Regulatory | Ongoing; annual review minimum + +SECTION 3 — RISK ACCEPTABILITY CRITERIA +[Organisation must define its own criteria — the standard does not specify absolute values] + +3.1 Severity categories +Severity Level | Description | Clinical Example +1 — Negligible | No injury or only inconvenience | Mild discomfort; no treatment required +2 — Minor | Temporary injury; no permanent harm | Mild irritation; self-limiting reaction +3 — Serious | Injury requiring medical intervention | Hospital admission; reversible harm +4 — Critical | Permanent impairment | Permanent disability; organ damage +5 — Catastrophic | Death | Patient fatality + +3.2 Probability categories +Probability Level | Description | Qualitative Estimate +5 — Frequent | Expected to occur often | >1 in 100 +4 — Probable | Likely during device lifetime | 1 in 100 to 1 in 1,000 +3 — Occasional | Could occur | 1 in 1,000 to 1 in 10,000 +2 — Remote | Unlikely but possible | 1 in 10,000 to 1 in 100,000 +1 — Improbable | Very unlikely | <1 in 100,000 + +3.3 Risk acceptability decision matrix +[Include 5x5 matrix with Acceptable / Low / Medium / High / Unacceptable zones] + +3.4 Overall residual risk acceptability +The overall residual risk is acceptable if: +- All individual residual risks are in the Acceptable, Low, or Medium zone +- Risks in the Medium zone are justified by clinical benefit (ALARP principle applied) +- The clinical benefit to the intended patient population outweighs the residual risks +- Risk reduction has been pursued as far as reasonably practicable + +SECTION 4 — RISK MANAGEMENT ACTIVITIES DOCUMENTATION +All risk management activities shall be documented in the Risk Management File, which includes: +- This Risk Management Plan +- Risk Analysis records +- Risk Evaluation records +- Risk Control records +- Residual Risk Evaluation +- Risk Management Report (ISO 14971 Clause 9) +- Post-market risk review records (ISO 14971 Clause 10) + +SECTION 5 — REVIEW AND UPDATE TRIGGERS +This Risk Management Plan shall be reviewed and updated when: +- New hazards are identified +- Residual risks change due to design or process changes +- Post-market data reveals new risk information +- A CAPA or NC is linked to a device failure mode +- A design change occurs (per Clause 7.3.9) +- Regulatory requirements applicable to risk management are revised +- At each management review (summarised update minimum) + +Approved by: [Top Management / VP Quality] _________________ Date: _____________ +``` 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/plugins/iso9001/.claude-plugin/plugin.json b/plugins/iso9001/.claude-plugin/plugin.json new file mode 100644 index 0000000..483b407 --- /dev/null +++ b/plugins/iso9001/.claude-plugin/plugin.json @@ -0,0 +1,21 @@ +{ + "name": "iso9001", + "description": "ISO 9001:2015 Quality Management System (QMS) advisor — gap analysis, quality policy and procedure writing, clause-by-clause implementation guidance, process documentation, audit preparation, and certification readiness.", + "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": [ + "iso9001", + "quality-management", + "qms", + "compliance", + "gap-analysis", + "certification", + "grc" + ] +} diff --git a/plugins/iso9001/skills/iso9001/SKILL.md b/plugins/iso9001/skills/iso9001/SKILL.md new file mode 100644 index 0000000..d03141a --- /dev/null +++ b/plugins/iso9001/skills/iso9001/SKILL.md @@ -0,0 +1,298 @@ +--- +name: iso9001 +description: > + Expert ISO 9001 Quality Management System (QMS) compliance assistant. Use this skill + whenever a user asks about ISO 9001 or ISO 9001:2015, including any of the following: + gap analysis, internal auditing, certification readiness, quality policy writing, process + documentation, nonconformity management, corrective action, risk-based thinking, PDCA cycle, + document control, management review, supplier qualification, customer satisfaction, + design and development controls, production and service provision, or any quality management + system (QMS) topic. Trigger even if the user does not say "skill" -- any ISO 9001 or QMS + question should use this skill. +--- + +# ISO 9001 Quality Management System (QMS) Skill + +You are an expert ISO 9001 Lead Auditor and QMS implementation consultant assisting a **quality, operations, or compliance team**. You have deep knowledge of ISO 9001:2015 and its predecessor ISO 9001:2008, and can help with gap analysis, procedure authoring, process documentation, audit preparation, and nonconformity management. + +--- + +## How to Respond + +Always confirm the organisation's industry/sector and product or service type if not stated, as ISO 9001 scope varies significantly between manufacturing, software, services, and professional services. + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Clause \| Requirement \| Status \| Evidence Needed \| Gap Notes | +| Policy/procedure generation | Full structured document with document control block | +| Process documentation | Process map narrative + SIPOC table + key controls | +| Audit checklist | Clause-by-clause checklist with evidence prompts | +| Nonconformity/CAPA | Structured NC report: Description -> Root Cause -> Correction -> CA -> Verification | +| Risk and opportunities | Risk register: Process \| Risk/Opportunity \| Likelihood \| Impact \| Treatment \| Owner | +| Certification readiness | Stage 1 / Stage 2 checklist with RAG status | +| General question | Clear, concise prose with clause citations | + +Always cite the specific clause (e.g., Clause 8.3.2, Clause 9.1.2) in all outputs. + +--- + +## Standard Overview + +**ISO 9001:2015** is the world's most widely adopted management system standard, with over one million certified organisations across every sector. It was published in **September 2015**, replacing ISO 9001:2008. + +### High Level Structure (Annex SL) +ISO 9001:2015 uses the **Annex SL High Level Structure**, making it directly compatible with ISO 27001 (information security), ISO 14001 (environment), ISO 45001 (OH&S), and ISO 42001 (AI) for integrated management systems. + +### Seven Quality Management Principles +The standard is underpinned by seven principles: +1. **Customer focus** -- meeting customer requirements and exceeding expectations +2. **Leadership** -- unified direction and engagement from top management +3. **Engagement of people** -- competent, empowered, and engaged people at all levels +4. **Process approach** -- consistent, predictable results from interrelated processes +5. **Improvement** -- continual improvement of QMS performance +6. **Evidence-based decision making** -- decisions based on analysis of data +7. **Relationship management** -- sustained success through managing supplier/partner relationships + +### Key Change: Risk-Based Thinking +ISO 9001:2015 replaced the **preventive action** requirement of 2008 with **risk-based thinking** embedded throughout Clause 6 and Clause 8. There is no separate "preventive action" procedure -- risk is addressed at the process level. + +--- + +## Clause Structure (Mandatory -- Clauses 4-10) + +| Clause | Title | Key Deliverables | +|--------|-------|-----------------| +| 4 | Context of the Organisation | QMS scope document, interested party register, internal/external issue register | +| 5 | Leadership | Quality Policy (signed by top management), roles & responsibilities (RACI), management commitment evidence | +| 6 | Planning | Risk and opportunities register, quality objectives, plans to achieve objectives, change management process | +| 7 | Support | Competence records, awareness programme, calibrated equipment register, documented information procedure, communication plan | +| 8 | Operation | Operational planning records, customer requirement records, design/development files (if applicable), supplier qualification records, production/service records, inspection/test records, NC records | +| 9 | Performance Evaluation | Customer satisfaction data, KPIs/metrics, internal audit programme and reports, management review minutes | +| 10 | Improvement | Nonconformity log, corrective action records, continual improvement register | + +For detailed clause requirements -> read `references/iso9001-clauses-requirements.md` +For quality process controls reference -> read `references/iso9001-quality-controls.md` +For document templates -> read `references/iso9001-document-templates.md` + +--- + +## Core Workflows + +### 1. Gap Analysis (Most Common Starting Point) + +**Inputs needed from user:** Industry/sector, products or services, current certifications (if any), approximate organisation size, target timeline. + +**Process:** +1. Assess mandatory clause compliance (4-10) -- flag missing required documents +2. Identify gaps in documented procedures and process controls +3. Produce prioritised remediation roadmap (30/60/90 days + strategic) + +**Output format:** +``` +CLAUSE | REQUIREMENT | STATUS | EVIDENCE NEEDED | GAP/ACTION +4.1 | Internal/external context documented | Not started | Context analysis document | Conduct SWOT/PESTLE; document interested parties +6.1 | Risks and opportunities addressed | Partial | Risk register | Expand to cover all QMS processes; assign owners +8.5.1 | Production/service provision controls | Implemented | Work instructions, travellers | Review for completeness +``` + +**Status definitions:** +- Implemented -- requirement is fully in place with objective evidence +- Partial -- some evidence exists but gaps remain +- Not Implemented -- no evidence of implementation +- N/A -- documented exclusion with justification (only valid for Clause 8.3 and 8.5.x sub-clauses under specific conditions) + +**Permitted exclusions:** Only Clause 8 requirements may be excluded, and only when the excluded requirement does not affect the organisation's ability to deliver conforming products/services. The most common valid exclusion is **Clause 8.3 (Design and Development)** for organisations that use customer-provided designs without modification. + +### 2. Policy and Procedure Generation + +When generating quality documents: +- Always include document control block: Doc ID | Version | Owner | Approved By | Date | Next Review +- Map each procedure to the relevant ISO 9001 clause(s) +- Include: Purpose, Scope, Responsibilities, Procedure Steps, Records, Related Documents + +**Core QMS documents (minimum set for certification):** + +| Document | Clause | Mandatory? | +|----------|--------|-----------| +| Quality Manual | -- | Not mandatory in 2015 (but strongly recommended) | +| Quality Policy | 5.2 | Yes -- documented and communicated | +| Quality Objectives | 6.2 | Yes -- measurable and monitored | +| QMS Scope | 4.3 | Yes -- documented | +| Risk and Opportunities Register | 6.1 | Yes -- process-level | +| Documented Information Procedure | 7.5 | Yes | +| Internal Audit Procedure | 9.2 | Yes | +| Nonconformity and Corrective Action Procedure | 10.2 | Yes | +| Management Review Procedure | 9.3 | Yes | +| Competency and Training Records | 7.2 | Yes | +| Calibration/Equipment Register | 7.1.5 | Yes (if monitoring equipment used) | +| Customer Requirements / Contract Review | 8.2 | Yes | +| Design and Development Records | 8.3 | Only if Clause 8.3 applies | +| Supplier/External Provider Records | 8.4 | Yes | +| Production/Service Records | 8.5 | Yes | +| Release Records | 8.6 | Yes | +| Nonconformity Records | 8.7 | Yes | + +### 3. Nonconformity and Corrective Action (CAPA) + +When generating a nonconformity report or CAPA: + +**NC Report structure:** +``` +NC Reference: [NC-YYYY-NNN] +Date Raised: | Raised by: | Process/Area: +Clause Reference: | NC Type: Major / Minor / Observation + +DESCRIPTION OF NONCONFORMITY: +[Precise description -- what was found, where, what the requirement is] + +IMMEDIATE CORRECTION (fix the symptom): +[Action taken to address the specific instance] + +ROOT CAUSE ANALYSIS (method: 5-WHY / Fishbone / Fault Tree): +[Documented root cause -- not symptoms] + +CORRECTIVE ACTION (eliminate the root cause): +[Systemic action to prevent recurrence] + +EVIDENCE OF EFFECTIVENESS: +[How and when effectiveness will be verified] + +CLOSURE DATE: | Verified by: | Closed by: +``` + +**Major vs Minor NC guidance:** +- **Major NC** -- absence of a required element, systemic failure, or multiple minors in same area -> potential certification suspension +- **Minor NC** -- isolated lapse, partial implementation -> corrective action required before next audit +- **Observation/OFI** -- opportunity for improvement, no formal corrective action required + +### 4. Internal Audit Support + +When supporting an internal audit or producing an audit checklist: + +1. Structure by clause (4-10) or by process (whichever the user prefers) +2. For each clause/process: list audit questions, evidence to request, and common findings +3. Produce a clause-by-clause checklist with columns: Requirement | Audit Question | Evidence Requested | Finding | NC Ref (if applicable) + +**Common audit findings by clause:** +- **4.1/4.2**: Context and interested party needs not reviewed at defined intervals +- **6.1**: Risks identified but no treatment actions or owners assigned +- **7.2**: Competency records incomplete; no evaluation of training effectiveness +- **7.5**: Document control inadequate -- obsolete documents in use +- **8.4**: Supplier evaluation criteria undefined or records missing +- **9.1**: Customer satisfaction data collected but not analysed or acted upon +- **9.3**: Management review records lack required inputs (e.g., audit results, KPIs) +- **10.2**: Corrective actions implemented but effectiveness never verified + +### 5. Process Documentation + +When helping document a QMS process: + +**SIPOC Table:** +| Suppliers | Inputs | Process Steps | Outputs | Customers | +|-----------|--------|--------------|---------|-----------| + +**Process Document structure:** +1. Process Name and Owner +2. Purpose and Scope +3. Inputs and Outputs +4. Process Steps (flowchart or numbered) +5. Roles and Responsibilities +6. Risk and Controls (what can go wrong, what controls prevent it) +7. Performance Indicators (KPIs tied to Clause 9.1) +8. Records Generated +9. Related Documents + +### 6. Certification Readiness + +**Stage 1 readiness checklist:** +- [ ] QMS scope documented (Clause 4.3) +- [ ] Quality Policy signed by top management (Clause 5.2) +- [ ] Quality Objectives -- measurable and monitored (Clause 6.2) +- [ ] Risks and opportunities addressed for all QMS processes (Clause 6.1) +- [ ] Documented information procedure (Clause 7.5) +- [ ] Internal audit programme and at least one completed cycle (Clause 9.2) +- [ ] Management review completed with all required inputs (Clause 9.3) +- [ ] Nonconformity and corrective action procedure (Clause 10.2) +- [ ] Supplier evaluation records (Clause 8.4) +- [ ] Customer requirements and satisfaction records (Clause 8.2, 9.1.2) + +**Stage 2 evidence package:** +- Quality Policy and Objectives + performance data showing progress +- Competency and training records for key roles +- Calibration records (if measuring equipment used) +- Internal audit reports and corrective actions +- Management review minutes +- Customer complaint log and satisfaction survey results +- Supplier qualification and evaluation records +- Nonconformity and CAPA records (show closed-loop process) +- Design and development records (if Clause 8.3 applies) + +--- + +## Integration with Other Management Systems + +ISO 9001 uses Annex SL so it integrates cleanly: + +| ISO Standard | Integration Point | +|-------------|-----------------| +| ISO 14001:2015 | Shared HLS, context analysis, objectives, internal audit, management review | +| ISO 45001:2018 | Shared HLS; worker participation (Clause 5.4) extends 9001 leadership | +| ISO 27001:2022 | Shared HLS; Clause 7.5 (documented information) aligns; supplier controls mapped | +| ISO 42001:2023 | Shared HLS; Clause 8 operational controls extended for AI system lifecycle | +| ISO 13485:2016 | Medical devices -- sector-specific derivative with additional regulatory requirements | +| IATF 16949:2016 | Automotive -- builds on 9001:2015 with core tools (APQP, PPAP, FMEA, MSA, SPC) | + +--- + +## Sector Scheme Awareness + +| Sector | Scheme | Key Additional Requirements | +|--------|--------|-----------------------------| +| Automotive | IATF 16949 | Core tools (APQP, PPAP, FMEA, MSA, SPC), customer-specific requirements (CSRs) | +| Aerospace | AS9100D | Product/part traceability, FOD prevention, first article inspection, key characteristics | +| Medical Devices | ISO 13485 | Design controls, sterilisation validation, complaint handling, regulatory submissions | +| Food | FSSC 22000 / BRC | HACCP, allergen management, food defence, food fraud | +| Software / IT Services | ISO/IEC 90003 | Software lifecycle controls mapped to 9001 clauses | +| Construction | ISO 9001 + sector guidance | Site-specific QMS, subcontractor management, inspection and test plans | + +--- + +## Mandatory Documentation Checklist + +- [ ] QMS scope (4.3) +- [ ] Quality Policy (5.2) +- [ ] Quality Objectives (6.2) +- [ ] Documented information as determined necessary by the organisation (4.4) +- [ ] Monitoring and measurement resources -- calibration records (7.1.5) +- [ ] Customer requirements (8.2) +- [ ] Design and development (8.3) -- if applicable +- [ ] Externally provided products/services -- supplier evaluation records (8.4) +- [ ] Production/service provision records (8.5) +- [ ] Traceability records (8.5.2) -- if required +- [ ] Release records (8.6) +- [ ] Nonconforming outputs records (8.7) +- [ ] Monitoring, measurement, analysis and evaluation results (9.1) +- [ ] Internal audit programme and results (9.2) +- [ ] Management review results (9.3) +- [ ] Nonconformity and corrective action records (10.2) + +--- + +## Key Terminology + +| Term | Definition | +|------|-----------| +| QMS | Quality Management System | +| PDCA | Plan-Do-Check-Act -- the continual improvement cycle underpinning ISO 9001 | +| Risk-based thinking | Proactive identification and treatment of risks at the process level (replaces 2008 preventive action) | +| Nonconformity (NC) | Failure to meet a requirement -- internal, external, or from an audit | +| Corrective Action | Action to eliminate the root cause of a nonconformity to prevent recurrence | +| Documented information | ISO 9001:2015 term covering both documents (procedures) and records (evidence) | +| Competence | Demonstrated ability to apply knowledge and skills to achieve intended results | +| Interested party | Any person or organisation that can affect or be affected by the QMS | +| Process approach | Managing activities and related resources as processes with defined inputs, outputs, and controls | +| External provider | Supplier, subcontractor, or any third party providing processes, products, or services | +| Management review | Periodic top-management evaluation of the QMS suitability, adequacy, and effectiveness | +| Internal audit | Systematic, independent examination of the QMS against ISO 9001 requirements | diff --git a/plugins/iso9001/skills/iso9001/references/iso9001-clauses-requirements.md b/plugins/iso9001/skills/iso9001/references/iso9001-clauses-requirements.md new file mode 100644 index 0000000..befe6e2 --- /dev/null +++ b/plugins/iso9001/skills/iso9001/references/iso9001-clauses-requirements.md @@ -0,0 +1,498 @@ +# ISO 9001:2015 — Clause-by-Clause Requirements Reference + +This reference file provides a detailed breakdown of every mandatory and recommended requirement across ISO 9001:2015 Clauses 4–10. Load this file when performing clause-specific gap analysis, generating audit checklists, or advising on specific clause implementation. + +--- + +## Clause 4 — Context of the Organisation + +### 4.1 Understanding the Organisation and Its Context +**Requirement:** Determine internal and external issues relevant to the QMS purpose and strategic direction. + +**What is required:** +- Conduct a structured context analysis — SWOT, PESTLE, or equivalent +- Identify internal issues: culture, values, performance, resources, knowledge, systems +- Identify external issues: legal/regulatory environment, competitive landscape, economic factors, technology, supply chain +- Review at defined intervals (typically annually and at management review) + +**Common audit evidence:** Context analysis document, SWOT matrix, management review agenda referencing 4.1 review + +**Common gaps:** Analysis performed once and never updated; only external context considered; no link to QMS scope or objectives + +--- + +### 4.2 Understanding the Needs and Expectations of Interested Parties +**Requirement:** Identify interested parties and their relevant requirements. + +**What is required:** +- List of interested parties (customers, employees, regulators, suppliers, shareholders, community) +- For each: document relevant requirements that may affect QMS conformance +- Determine which requirements become compliance obligations +- Review at defined intervals + +**Common audit evidence:** Interested party register, legal/regulatory requirements log, customer contract review records + +**Common gaps:** Only customers and regulators listed; requirements not linked to QMS processes; no review cycle + +--- + +### 4.3 Determining the Scope of the QMS +**Requirement:** Define the boundaries and applicability of the QMS in a documented statement. + +**What is required:** +- Documented scope statement: products/services covered, sites, functions +- Justify any exclusions from Clause 8 — must not affect ability to deliver conforming products/services +- Most common valid exclusion: Clause 8.3 (Design and Development) for organisations using customer-provided designs + +**Common audit evidence:** Scope document (often in Quality Manual or standalone), certificate scope statement + +**Common gaps:** Scope too broad (includes unrealistic activities); exclusions not justified; scope inconsistent with certification certificate + +--- + +### 4.4 Quality Management System and Its Processes +**Requirement:** Establish, implement, maintain, and continually improve QMS processes. + +**What is required:** +- Process inventory: list all QMS processes with inputs, outputs, sequence, and interactions +- For each process: determine criteria, methods, resources, responsibilities, risks/opportunities +- Process performance monitoring and analysis +- Evaluate processes and implement changes needed to achieve intended results + +**Common audit evidence:** Process map (turtle diagram, process interaction matrix), process procedure documents, process KPIs + +**Common gaps:** Process inventory not documented; process interactions not shown; KPIs not linked to quality objectives + +--- + +## Clause 5 — Leadership + +### 5.1 Leadership and Commitment +**Requirement:** Top management must demonstrate leadership and commitment to the QMS. + +**5.1.1 General (QMS):** +- Accountability for QMS effectiveness +- Quality policy and objectives compatible with strategic direction +- QMS integrated into business processes +- Promotion of process approach and risk-based thinking +- Resources available for QMS +- Promoting continual improvement + +**5.1.2 Customer Focus:** +- Customer requirements determined and met +- Risks and opportunities affecting product/service conformance addressed +- Customer satisfaction focus maintained + +**Common audit evidence:** Signed quality policy, management review minutes showing leadership participation, QMS integrated into org strategy documents + +**Common gaps:** Quality policy signed by administrator rather than top management; QMS treated as separate from business operations + +--- + +### 5.2 Quality Policy +**Requirement:** Top management must establish, implement, and maintain a Quality Policy. + +**Quality Policy must:** +- Be appropriate to the purpose and context of the organisation +- Provide a framework for quality objectives +- Include commitment to satisfying applicable requirements +- Include commitment to continual improvement of QMS +- Be documented, communicated, and understood within the organisation +- Be available to interested parties as appropriate + +**Common audit evidence:** Signed quality policy document, evidence of communication (intranet, noticeboards, orientation records) + +**Common gaps:** Policy not signed or dated; lacks commitment to continual improvement; staff unable to explain policy in their own words during audit + +--- + +### 5.3 Organisational Roles, Responsibilities and Authorities +**Requirement:** Top management must assign and communicate QMS roles and responsibilities. + +**What is required:** +- Roles for: QMS conformance, process performance, customer requirements reporting, QMS integrity during change +- RACI matrix or equivalent +- Management Representative role (not mandatory in 2015, but remains best practice) + +**Common audit evidence:** Org chart, job descriptions, RACI matrix, documented role assignments + +**Common gaps:** QMS responsibilities not in job descriptions; no single point of accountability for QMS conformance + +--- + +## Clause 6 — Planning + +### 6.1 Actions to Address Risks and Opportunities +**Requirement:** Identify and address risks and opportunities at the process level. + +**What is required:** +- Systematic risk identification for each QMS process +- Assessment of risk likelihood and impact +- Risk treatment decisions: accept, mitigate, avoid, transfer +- Proportionate actions integrated into QMS processes +- Evaluation of effectiveness of risk actions +- Opportunity identification (process improvement, new capabilities) + +**Risk-based thinking replaces preventive action** from ISO 9001:2008. There is no standalone "preventive action procedure" requirement. + +**Common audit evidence:** Risk register (process-level), risk treatment records, process KPI trends showing managed risks + +**Common gaps:** Risk register only covers strategic/enterprise risks — not process-level; risks identified but no treatment actions or owners; never reviewed after initial creation + +--- + +### 6.2 Quality Objectives and Planning to Achieve Them +**Requirement:** Establish, maintain, and monitor quality objectives. + +**Quality objectives must:** +- Be consistent with the quality policy +- Be measurable +- Take into account applicable requirements +- Be relevant to product/service conformance and customer satisfaction +- Be monitored, communicated, and updated as appropriate +- Be documented + +**For each objective:** Document what will be done, what resources are needed, who is responsible, when it will be completed, how results will be evaluated. + +**Common audit evidence:** Quality objectives register/dashboard, performance reviews, management review minutes referencing objectives + +**Common gaps:** Objectives vague ("improve quality") without measurable targets; objectives never reviewed or updated; no action plan linking objectives to specific activities + +--- + +### 6.3 Planning of Changes +**Requirement:** Changes to the QMS must be carried out in a planned manner. + +**What is required:** +- Change purpose and potential consequences considered +- QMS integrity maintained during change +- Resources available for change +- Responsibilities and authorities assigned for the change + +**Common audit evidence:** Change request records, change impact assessments, procedure change logs + +**Common gaps:** Procedure updates made informally without change control; impact on related processes not assessed + +--- + +## Clause 7 — Support + +### 7.1 Resources + +**7.1.1 General:** +Determine and provide resources needed for QMS establishment, implementation, maintenance, and improvement — considering capabilities and constraints of existing internal resources, and what needs to be obtained from external providers. + +**7.1.2 People:** +Sufficient people to operate and control QMS processes. Document headcount/competency requirements. + +**7.1.3 Infrastructure:** +Buildings, utilities, equipment, transport, IT systems. Maintenance records required. + +**7.1.4 Environment for Operation of Processes:** +Physical, social, psychological, and environmental conditions necessary for conforming products/services. Documented where critical to conformance. + +**7.1.5 Monitoring and Measuring Resources:** +- Maintain calibrated equipment used to verify product/service conformance +- Calibration records: equipment ID, calibration date, next due date, traceability to national standard, result (pass/fit for use) +- Equipment found out-of-calibration: investigate impact on previous measurements + +**7.1.6 Organisational Knowledge:** +Identify, maintain, and make available knowledge necessary for QMS operation. Protect against loss (succession planning, documentation). Acquire additional knowledge as needed. + +**Common audit evidence:** Equipment calibration register, infrastructure maintenance records, competency matrix, knowledge management procedure + +--- + +### 7.2 Competence +**Requirement:** Determine, ensure, and document the competence of QMS process workers. + +**What is required:** +- Identify competence requirements for each role affecting QMS performance +- Evaluate current competence of individuals against requirements +- Take actions to acquire needed competence (training, mentoring, redeployment) +- Document evidence of competence: qualifications, training records, work experience, skills assessments +- Evaluate effectiveness of training actions + +**Common audit evidence:** Competency matrix, training records, training effectiveness evaluation forms, job descriptions with competency requirements + +**Common gaps:** Training delivered but effectiveness never evaluated; competency requirements not defined for QMS-critical roles; records incomplete + +--- + +### 7.3 Awareness +**Requirement:** All persons doing work under the organisation's control must be aware of the quality policy, objectives, their contribution to QMS effectiveness, and implications of non-conformance. + +**Common audit evidence:** Onboarding records, awareness training records, staff knowledge-check results + +--- + +### 7.4 Communication +**Requirement:** Determine internal and external communications relevant to the QMS. + +**What is required (for each communication):** What, when, with whom, how, who communicates. + +**Common audit evidence:** Communication plan, meeting minutes, customer communication records + +--- + +### 7.5 Documented Information +**Requirement:** Create, maintain, and control documented information required by the standard and determined as necessary by the organisation. + +**7.5.2 Creating and Updating:** +- Identification and description (title, date, author, reference number) +- Format and media +- Review and approval + +**7.5.3 Control of Documented Information:** +- Available and suitable for use, where and when needed +- Protected from loss of confidentiality, improper use, or loss of integrity +- Distribution, access, retrieval, and use +- Storage and preservation +- Change control (version control) +- Retention and disposition +- **Prevention of use of obsolete documents** — remove from use or clearly identify + +**Common audit evidence:** Document control procedure, master document list, version-controlled procedure library, obsolete document handling records + +**Common gaps:** No version control on procedures; obsolete procedures still in use on shop floor; no defined retention periods + +--- + +## Clause 8 — Operation + +### 8.1 Operational Planning and Control +**Requirement:** Plan, implement, control, maintain, and review processes needed to meet requirements for provision of products and services. + +**What is required:** +- Criteria for processes and product/service acceptance +- Resources to meet criteria +- Control of processes per criteria +- Documented information to: confirm processes carried out as planned; demonstrate conformance +- Control of planned changes; mitigation of adverse effects of unintended changes +- Control of outsourced processes (reference 8.4) + +--- + +### 8.2 Requirements for Products and Services + +**8.2.1 Customer Communication:** Channels for product/service information, enquiries, contracts, customer feedback and complaints, customer property handling, contingency plan communication. + +**8.2.2 Determining Requirements for Products and Services:** Statutory and regulatory requirements; those considered necessary; customer requirements including delivery and post-delivery. + +**8.2.3 Review of Requirements:** Review before committing to supply — ability to meet defined requirements confirmed; differing contract/tender requirements resolved; documented evidence of review; customer order confirmation process. + +**8.2.4 Changes to Requirements for Products and Services:** Relevant documented information amended; relevant personnel informed; change records. + +**Common audit evidence:** Customer contract review records, order acknowledgements, customer communication logs, change request records + +--- + +### 8.3 Design and Development of Products and Services +*(May be excluded if organisation does not perform design — requires documented justification)* + +**8.3.1 General:** Establish, implement, and maintain a design and development process. + +**8.3.2 Planning:** +- Nature, duration, and complexity of D&D activities +- Required process stages including applicable reviews +- Verification and validation activities +- Responsibilities and authorities +- Internal and external resource needs +- Control of interfaces between persons involved +- Customer and user involvement +- Requirements for subsequent provision of products/services +- Level of control expected by customers and other interested parties +- Documented information to demonstrate requirements met + +**8.3.3 Inputs:** Functional and performance requirements; applicable statutory and regulatory requirements; standards or codes of practice; potential consequences of failure due to nature of product/service. + +**8.3.4 Controls:** Reviews, verification, validation at defined stages. Problems during D&D addressed and documented. + +**8.3.5 Outputs:** Meet input requirements; adequate for subsequent production/service; include or reference monitoring and measurement requirements; specify characteristics essential for intended use and safe and proper provision. + +**8.3.6 Changes:** Identify, review, and control D&D changes. Include: change significance, design reviews, verification/validation, authorisation. Retain documented information. + +--- + +### 8.4 Control of Externally Provided Processes, Products, and Services + +**8.4.1 General:** Ensure externally provided processes/products/services conform to requirements. Determine controls based on: +- Incorporation into own products/services +- Provision directly to customer by external provider +- Process/function outsourced + +**Supplier evaluation criteria:** Must be defined and applied to select, evaluate, and re-evaluate. + +**8.4.2 Type and Extent of Control:** Proportionate to impact on output conformance. Communicate requirements to external providers. Retain evidence of evaluation. + +**8.4.3 Information for External Providers:** Communicate before delivery: +- Processes, products, services to be provided +- Acceptance criteria +- Competence (including qualifications) +- Interactions with organisation +- Control and monitoring of performance +- Verification activities at external provider's premises + +**Common audit evidence:** Approved supplier list, supplier evaluation forms, supplier scorecards, purchase orders with quality requirements, supplier audit records + +**Common gaps:** Approved supplier list exists but no re-evaluation records; evaluation criteria not documented; critical subcontractors not assessed + +--- + +### 8.5 Production and Service Provision + +**8.5.1 Control of Production and Service Provision:** Controlled conditions including: +- Documented information defining characteristics of products/services +- Documented information defining activities to be performed and results to be achieved +- Monitoring and measurement activities +- Suitable infrastructure and process environment +- Competent persons +- Validation and periodic revalidation of special processes +- Actions to prevent human error +- Implementation of release, delivery, and post-delivery activities + +**8.5.2 Identification and Traceability:** +- Identify outputs where traceability is required +- Control unique identification; retain documented information + +**8.5.3 Property Belonging to Customers or External Providers:** +- Identify, verify, protect, and safeguard +- Report loss/damage/unsuitability to owner and retain records + +**8.5.4 Preservation:** Preserve conformity of outputs during production and delivery — identification, handling, contamination control, packaging, storage, transmission/transportation, protection. + +**8.5.5 Post-delivery Activities:** Warranty provisions, contractual obligations, supplementary services, recycling/disposal requirements. Consider: statutory/regulatory requirements, potential undesired consequences, nature/use/intended lifetime, customer requirements, customer feedback. + +**8.5.6 Control of Changes:** Review and control unplanned changes needed during production/service provision. Retain documented information. + +--- + +### 8.6 Release of Products and Services +**Requirement:** Implement planned arrangements to verify requirements met before release to customer. + +**What is required:** +- Documented evidence of conformance with acceptance criteria +- Retain evidence of person(s) authorising release +- Release not until planned arrangements completed (or approved by relevant authority) + +**Common audit evidence:** Final inspection records, test reports, certificate of conformance, ship/delivery authorisation records + +--- + +### 8.7 Control of Nonconforming Outputs +**Requirement:** Identify and control outputs not conforming to requirements to prevent unintended delivery or use. + +**Actions depending on nature of NC:** +- Correction (fix the output) +- Segregation, containment, return, or suspension of provision +- Informing the customer +- Obtaining authorisation for acceptance under concession/waiver + +**Retain documented information:** Description of nonconformity, actions taken, concessions obtained, authority deciding action. + +**If NC corrected:** Re-verify conformance to requirements after correction. + +--- + +## Clause 9 — Performance Evaluation + +### 9.1 Monitoring, Measurement, Analysis and Evaluation + +**9.1.1 General:** +- Determine what to monitor and measure +- Methods for valid results +- When monitoring/measurement performed +- When results analysed and evaluated +- Retain documented evidence of results + +**9.1.2 Customer Satisfaction:** +Monitor customer perception of the degree to which requirements have been met. +Methods: surveys, complaints, NPS, customer scorecards, warranty claims, distributor reports. +Documented customer satisfaction data required — not just complaint logs. + +**9.1.3 Analysis and Evaluation:** +Analyse and evaluate data from monitoring and measurement. Use results to evaluate: +- Conformance of products/services +- Degree of customer satisfaction +- QMS performance and effectiveness +- Planning was implemented effectively +- Effectiveness of risk and opportunity actions +- External provider performance +- Need for QMS improvements + +**Common audit evidence:** Customer satisfaction survey results, customer complaint log, KPI dashboard, process performance data, supplier scorecards + +--- + +### 9.2 Internal Audit + +**Requirement:** Conduct internal audits at planned intervals to determine whether the QMS conforms to organisation's own requirements and ISO 9001:2015 requirements; is effectively implemented and maintained. + +**What is required:** +- Documented audit programme (considering importance of processes, changes, and previous results) +- Audit criteria and scope for each audit +- Select auditors ensuring objectivity and impartiality (auditors cannot audit their own work) +- Report audit results to relevant management +- Correct and take corrective actions for nonconformities without undue delay +- Retain documented information (audit programme + audit reports) + +**Common audit evidence:** Annual audit programme, individual audit plans, completed audit checklists, audit reports, corrective action tracker + +**Common gaps:** Internal audits conducted but no audit programme; same person auditing own area; corrective actions from previous audits not closed before next audit; only one audit per year covering entire QMS without process-based approach + +--- + +### 9.3 Management Review + +**Requirement:** Top management must review the QMS at planned intervals to ensure its continuing suitability, adequacy, effectiveness, and alignment with strategic direction. + +**Mandatory inputs to management review:** +1. Status of actions from previous management reviews +2. Changes in external/internal issues relevant to QMS (4.1, 4.2) +3. Information on QMS performance: customer satisfaction and feedback; quality objectives achievement; process performance and product/service conformance; nonconformities and CAs; audit results; external provider performance +4. Adequacy of resources +5. Effectiveness of actions taken to address risks/opportunities +6. Opportunities for improvement + +**Mandatory outputs from management review:** +- Decisions and actions related to: improvement opportunities; any need for QMS changes; resource needs + +**Retain documented information as evidence.** + +**Common gaps:** Management review held but inputs incomplete (e.g., no audit results, no objective performance data); outputs lack specific action items with owners and dates; review done informally without documented minutes + +--- + +## Clause 10 — Improvement + +### 10.1 General +Determine and select improvement opportunities. Include: improving products/services, correcting/preventing/reducing undesired effects, improving QMS performance and effectiveness. + +--- + +### 10.2 Nonconformity and Corrective Action + +**Requirement:** When a nonconformity occurs (including customer complaint): +1. React: control, correct, deal with consequences +2. Evaluate the need for corrective action: root cause analysis; could the NC occur elsewhere? +3. Implement necessary corrective action +4. Review effectiveness of corrective action +5. Update risks/opportunities if needed +6. Change the QMS if needed + +**Corrective actions must be appropriate to the effects of the nonconformities encountered.** + +**Retain documented information as evidence:** +- Nature of nonconformities and subsequent actions taken +- Results of corrective actions + +**Common gaps:** Corrections made but root cause not analysed; corrective actions not reviewed for effectiveness; recurring NCs not escalated to systemic root cause investigation; CAPA closed without verification + +--- + +### 10.3 Continual Improvement +**Requirement:** Continually improve the suitability, adequacy, and effectiveness of the QMS. + +**Consider results of:** Analysis and evaluation (9.1.3), management review outputs (9.3), risk actions, customer feedback, nonconformity patterns. + +**Evidence expected:** Improvement register or log showing ideas, actions, and results; trends in KPIs improving over time; management review minutes referencing improvement themes. diff --git a/plugins/iso9001/skills/iso9001/references/iso9001-document-templates.md b/plugins/iso9001/skills/iso9001/references/iso9001-document-templates.md new file mode 100644 index 0000000..1c5fc76 --- /dev/null +++ b/plugins/iso9001/skills/iso9001/references/iso9001-document-templates.md @@ -0,0 +1,589 @@ +# ISO 9001:2015 — Document Templates Reference + +This reference file provides ready-to-use and customisable document templates for ISO 9001:2015 QMS implementation. Load this file when a user asks for a specific document template or policy. Adapt each template to the organisation's sector, size, and operational context. + +--- + +## Template 1 — Quality Policy + +``` +[ORGANISATION NAME] +QUALITY POLICY + +Document ID: QP-001 | Version: 1.0 | Owner: Managing Director / CEO +Effective Date: [DATE] | Next Review: [DATE + 1 YEAR] +Approved by: [NAME, TITLE] + +--- + +[ORGANISATION NAME] is committed to providing [products/services] that consistently meet +customer requirements and applicable statutory and regulatory requirements. We achieve this +through the establishment, implementation, and continual improvement of our Quality +Management System in accordance with ISO 9001:2015. + +We are committed to: + +1. CUSTOMER FOCUS + Understanding and meeting the needs and expectations of our customers, and seeking to + exceed their expectations wherever possible. + +2. LEADERSHIP AND ENGAGEMENT + Top management leading by example, ensuring all employees understand their role in + delivering quality outcomes, and fostering a culture of quality throughout the organisation. + +3. CONTINUAL IMPROVEMENT + Continuously improving the effectiveness of our QMS, our processes, and the quality + of our products/services through regular performance monitoring, management review, + and corrective action. + +4. RISK-BASED THINKING + Proactively identifying risks and opportunities that could affect our ability to deliver + conforming products/services, and taking appropriate action to address them. + +5. COMPLIANCE + Meeting all applicable statutory, regulatory, and customer-specified quality requirements. + +6. QUALITY OBJECTIVES + Setting and monitoring measurable quality objectives that support this policy and align + with our strategic direction. + +This policy is communicated to all employees and made available to interested parties. +It is reviewed at least annually to ensure its continuing suitability. + +Signed: _________________________ Date: _____________ + [Name], [Title] +``` + +--- + +## Template 2 — QMS Scope Statement + +``` +[ORGANISATION NAME] +QMS SCOPE STATEMENT + +Document ID: QMS-SCOPE-001 | Version: 1.0 +Effective Date: [DATE] | Approved by: [NAME, TITLE] + +--- + +SCOPE OF THE QUALITY MANAGEMENT SYSTEM + +[ORGANISATION NAME]'s Quality Management System applies to: + +PRODUCTS/SERVICES: [Describe the products or services covered — be specific, e.g. +"Design, manufacture, and supply of precision-machined components for the automotive +sector" or "Provision of IT managed services including helpdesk, infrastructure +management, and cybersecurity monitoring"] + +SITES/LOCATIONS: [List all sites, facilities, or locations included in the QMS scope. +State any remote working arrangements if relevant.] + +FUNCTIONS: [List functional departments within scope — e.g. Sales, Engineering, +Procurement, Production, Quality, Logistics, Customer Service] + +STANDARD: ISO 9001:2015 + +--- + +EXCLUSIONS FROM CLAUSE 8 (if applicable): + +The following Clause 8 requirements are excluded from the scope of the QMS with +justification as stated: + +| Clause | Title | Justification for Exclusion | +|--------|-------|-----------------------------| +| 8.3 | Design and Development | [Organisation] does not perform product or service design. All product specifications and designs are provided by customers. [Organisation]'s activities are limited to production to customer specifications. | +| [Other] | [Other title] | [Justification] | + +Note: Exclusions are only permitted for Clause 8 requirements and only where the +excluded requirement does not affect the organisation's ability or responsibility +to ensure conformity of products/services and enhancement of customer satisfaction. + +--- + +Approved: _________________________ Date: _____________ + [Name], [Title] +``` + +--- + +## Template 3 — Quality Objectives Register + +``` +[ORGANISATION NAME] +QUALITY OBJECTIVES REGISTER + +Document ID: QO-001 | Version: 1.0 | Owner: Quality Manager +Effective Date: [DATE] | Review Frequency: Quarterly and at Management Review + +--- + +Linkage to Quality Policy: All objectives below flow from the Quality Policy commitment to +[reference specific policy commitments, e.g. "customer satisfaction, continual improvement, +and compliance"]. + +| Obj. ID | Objective | Measure / KPI | Baseline | Target | Frequency | Owner | Actions Required | Status | +|---------|-----------|--------------|----------|--------|-----------|-------|-----------------|--------| +| QO-01 | Achieve customer satisfaction score ≥ X% | % customers rating overall satisfaction as "satisfied" or "very satisfied" | [Current %] | ≥ [X%] | Quarterly | Sales/QA Manager | Deploy post-delivery survey; analyse results; action on low scores | On track / Behind / Met | +| QO-02 | Reduce internal nonconformity rate | Number of internal NCs per [unit/month] | [Current rate] | ≤ [Target rate] | Monthly | Quality Manager | Root cause analysis on recurring NCs; process improvements | On track / Behind / Met | +| QO-03 | On-time delivery to customer ≥ X% | % orders delivered on or before agreed delivery date | [Current %] | ≥ [X%] | Monthly | Operations Manager | Improve production planning; identify and resolve delivery bottlenecks | On track / Behind / Met | +| QO-04 | Supplier on-time delivery ≥ X% | % supplier deliveries received on or before agreed date | [Current %] | ≥ [X%] | Monthly | Procurement Manager | Supplier scorecard review; SCAR for persistently late suppliers | On track / Behind / Met | +| QO-05 | Complete all internal audits per programme | % planned audits completed on schedule | [Current %] | 100% | Annually | Quality Manager | Maintain and execute annual audit programme | On track / Behind / Met | +| QO-06 | First time pass rate ≥ X% | % products passing final inspection without rework | [Current %] | ≥ [X%] | Monthly | Production Manager | Process control improvements; SPC where applicable | On track / Behind / Met | + +--- + +Review History: +| Date | Reviewed by | Changes | +|------|------------|---------| +``` + +--- + +## Template 4 — Risk and Opportunities Register + +``` +[ORGANISATION NAME] +RISK AND OPPORTUNITIES REGISTER + +Document ID: ROR-001 | Version: 1.0 | Owner: Quality Manager +Effective Date: [DATE] | Review Frequency: Annually and when significant changes occur + +Likelihood scale: 1 (Very Unlikely) | 2 (Unlikely) | 3 (Possible) | 4 (Likely) | 5 (Very Likely) +Impact scale: 1 (Negligible) | 2 (Minor) | 3 (Moderate) | 4 (Significant) | 5 (Severe) +Risk Score = Likelihood × Impact | Threshold: ≥ 12 = High (action required); 6–11 = Medium; 1–5 = Low + +--- + +RISKS + +| Ref | Process / Area | Risk Description | Likelihood | Impact | Score | Treatment | Actions | Owner | Due | Residual Score | +|-----|----------------|-----------------|-----------|--------|-------|-----------|---------|-------|-----|----------------| +| R-01 | Supplier Management | Key supplier fails to deliver on time, impacting production schedule | 3 | 4 | 12 | Mitigate | Identify alternative approved suppliers; maintain safety stock for critical components | Procurement Mgr | [Date] | 6 | +| R-02 | Human Resources | Loss of key QMS personnel (Quality Manager) creating knowledge gap | 2 | 4 | 8 | Mitigate | Document QMS processes; cross-train backup; succession planning | HR Manager | [Date] | 4 | +| R-03 | Production | Equipment failure causing production downtime and delayed deliveries | 3 | 3 | 9 | Mitigate | Implement preventive maintenance programme; maintain critical spare parts | Maintenance Mgr | [Date] | 4 | +| R-04 | Customer Requirements | Misinterpretation of customer requirements leading to nonconforming product | 2 | 5 | 10 | Mitigate | Customer requirement review procedure; written order confirmations; design review for complex orders | Quality Manager | [Date] | 4 | +| R-05 | Regulatory | Changes to regulatory requirements not identified in time | 2 | 4 | 8 | Mitigate | Subscribe to regulatory updates; annual regulatory review; legal compliance register | Compliance Officer | [Date] | 4 | + +--- + +OPPORTUNITIES + +| Ref | Area | Opportunity Description | Potential Benefit | Actions | Owner | Due | Status | +|-----|------|------------------------|------------------|---------|-------|-----|--------| +| O-01 | Technology | Implement production tracking software to improve traceability and reduce paperwork | Reduced admin time; improved traceability; real-time production data | Evaluate ERP/MES options; prepare business case | Operations Mgr | [Date] | Planned | +| O-02 | Market | Achieve ISO 9001 certification to access new customer segments requiring certified suppliers | Revenue growth; competitive differentiation | Complete QMS implementation; engage certification body | Managing Director | [Date] | In Progress | +| O-03 | Suppliers | Develop preferred supplier partnership with top-performing suppliers | Improved pricing; priority capacity; reduced qualification burden | Identify top 3 suppliers for partnership programme | Procurement Mgr | [Date] | Planned | +``` + +--- + +## Template 5 — Internal Audit Report + +``` +[ORGANISATION NAME] +INTERNAL AUDIT REPORT + +Audit Reference: IAR-[YYYY]-[NNN] +Audit Type: Clause-based / Process-based / Combined +Audit Scope: [Clauses / Processes audited, e.g. "Clauses 8.4 and 8.5 — Supplier Management and Production"] +Audit Criteria: ISO 9001:2015; [Organisation]'s QMS documented procedures +Audit Date(s): [Date(s)] +Auditee Department/Area: [Department / Site] +Auditee Representative: [Name, Title] +Lead Auditor: [Name] | Team Members: [Names, if applicable] +Declaration of Independence: I confirm I have no direct responsibility for the activities audited. + +--- + +EXECUTIVE SUMMARY + +Overall conformance status: Conforming / Conforming with minor NCs / Major NC found + +Summary: [2-4 sentences describing the overall audit findings, e.g. "The supplier management +process demonstrated good overall conformance with ISO 9001:2015 Clause 8.4. An approved +supplier list is maintained and supplier evaluations are conducted. Two minor nonconformities +were raised relating to inconsistent documentation of re-evaluation records and the absence +of supplier performance data for one critical supplier."] + +--- + +FINDINGS SUMMARY + +| Finding Ref | Clause | Type | Finding Description | +|------------|--------|------|-------------------| +| IAR-[NNN]-01 | 8.4.1 | Minor NC | Re-evaluation records for 3 of 12 suppliers on the ASL were found to be >18 months old against a stated re-evaluation interval of 12 months. | +| IAR-[NNN]-02 | 9.1.3 | Observation | Customer satisfaction survey results are collected but not formally analysed or presented at management review. Recommend formal analysis and trend reporting. | +| IAR-[NNN]-C1 | 8.4.2 | Conformance | Purchase orders reviewed confirmed quality requirements (specification, revision level, CoC requirement) are consistently included. | + +--- + +NONCONFORMITY DETAILS + +NC Reference: IAR-[NNN]-01 +Clause: [Clause reference] +Type: Major / Minor +Statement of Nonconformity: [Precise, objective description of what was found, the +requirement it fails to meet, and the objective evidence observed] +Objective Evidence: [What was seen/reviewed — document IDs, sample sizes, records reviewed] +Corrective Action Required By: [Date — typically 30 days for minor, 14 days for major] +Linked CAPA Reference: [To be completed when CAPA raised] + +--- + +POSITIVE FINDINGS / GOOD PRACTICES + +[Note any areas of strong conformance or good practice observed during the audit — useful +for morale and sharing best practices across the organisation] + +--- + +AUDIT CONCLUSION + +Auditor Signature: _____________________________ Date: ___________ +Auditee Acknowledgement: ______________________ Date: ___________ + +Next Audit Scheduled: [Date / As per audit programme] +``` + +--- + +## Template 6 — Nonconformity and Corrective Action Report (CAPA) + +``` +[ORGANISATION NAME] +NONCONFORMITY AND CORRECTIVE ACTION REPORT + +CAPA Reference: CAPA-[YYYY]-[NNN] +Date Raised: [Date] | Raised by: [Name, Role] | Department/Process: [Name] +Source: Internal audit / Customer complaint / Internal finding / Supplier failure / Other +Clause Reference: [ISO 9001:2015 clause, if audit-related] + +--- + +SECTION 1 — NONCONFORMITY DESCRIPTION +Describe precisely what the nonconformity is, where it was found, when, and what requirement +is not being met. Include objective evidence (document IDs, batch numbers, dates, quantities). + +[Description] + +--- + +SECTION 2 — IMMEDIATE CORRECTION (Containment) +What immediate action was taken to fix the specific instance and prevent further impact? +(e.g., product quarantined, customer notified, process stopped, rework initiated) + +Action taken: [Description] +Completed by: [Name] | Date: [Date] + +--- + +SECTION 3 — ROOT CAUSE ANALYSIS +Method used: [ ] 5-Why [ ] Fishbone/Ishikawa [ ] Fault Tree [ ] Other: ____________ + +5-Why Analysis (if used): +Why 1: [Why did the problem occur?] +Why 2: [Why did that happen?] +Why 3: [Why did that happen?] +Why 4: [Why did that happen?] +Why 5: [Root cause identified] + +Root Cause Statement: [Clear, concise statement of the underlying root cause] + +Completed by: [Name] | Date: [Date] + +--- + +SECTION 4 — CORRECTIVE ACTION PLAN +Actions to eliminate the root cause and prevent recurrence (systemic, not just symptom fix): + +| Action | Owner | Due Date | Status | +|--------|-------|----------|--------| +| [Action 1] | [Name] | [Date] | Open | +| [Action 2] | [Name] | [Date] | Open | + +--- + +SECTION 5 — IMPLEMENTATION EVIDENCE +Evidence that corrective actions were completed as planned: + +| Action | Evidence | Completed by | Date Completed | +|--------|---------|-------------|---------------| +| [Action 1] | [Evidence reference] | [Name] | [Date] | + +--- + +SECTION 6 — EFFECTIVENESS VERIFICATION +How and when will effectiveness be confirmed? (e.g., re-audit, process monitoring data, +no recurrence within X months) + +Verification method: [Description] +Verification due date: [Date] +Verification result: [ ] Effective — NC has not recurred; root cause eliminated + [ ] Not effective — NC has recurred; CAPA to be re-opened + +Verified by: [Name, Title] | Date: [Date] + +--- + +SECTION 7 — CLOSURE + +Closed by: [Name, Title] | Date: [Date] +QMS update required: [ ] Yes — document/procedure updated: [Reference] [ ] No + +Linked audit NC reference (if applicable): [IAR reference] +Linked customer complaint reference (if applicable): [CC reference] +``` + +--- + +## Template 7 — Management Review Agenda and Minutes + +``` +[ORGANISATION NAME] +MANAGEMENT REVIEW MINUTES + +Document ID: MR-[YYYY]-[N] +Date: [Date] | Location: [Location / Virtual] +Attendees: [Names and titles of all attendees including top management representative] +Chair: [Name, Title — must be top management] +Minute-taker: [Name] + +--- + +AGENDA AND DISCUSSION + +1. WELCOME AND PURPOSE + Confirm quorum. Confirm minutes of previous management review ([MR reference]). + +2. STATUS OF PREVIOUS MANAGEMENT REVIEW ACTIONS + Review all actions from [Previous MR reference]: + | Action | Owner | Due Date | Status | Comments | + |--------|-------|----------|--------|----------| + +3. CHANGES IN EXTERNAL AND INTERNAL CONTEXT (Clause 4.1/4.2) + Discussion: What has changed since the last review in external environment (regulatory, + market, competitive) or internal context (people, systems, strategy)? + Decision/Action: + +4. CUSTOMER SATISFACTION AND FEEDBACK (Clause 9.1.2) + Data presented: Customer satisfaction scores, complaint trends, customer feedback summary + Discussion: + Decision/Action: + +5. QUALITY OBJECTIVES PERFORMANCE (Clause 6.2) + Data presented: Current status of all quality objectives against targets + Discussion: [List each objective and RAG status] + Decision/Action: + +6. PROCESS PERFORMANCE AND PRODUCT/SERVICE CONFORMANCE (Clause 9.1) + Data presented: Process KPIs, nonconformity trends, first pass yield, delivery performance + Discussion: + Decision/Action: + +7. INTERNAL AUDIT RESULTS (Clause 9.2) + Data presented: Summary of internal audits conducted since last review, outstanding NCs + Discussion: + Decision/Action: + +8. EXTERNAL PROVIDER PERFORMANCE (Clause 8.4) + Data presented: Supplier scorecard summary, outstanding SCARs + Discussion: + Decision/Action: + +9. ADEQUACY OF RESOURCES (Clause 7.1) + Discussion: Are current people, infrastructure, environment, and knowledge resources + adequate for QMS operation? + Decision/Action: + +10. EFFECTIVENESS OF RISK AND OPPORTUNITY ACTIONS (Clause 6.1) + Data presented: Risk register review; have treatment actions been effective? + Discussion: + Decision/Action: + +11. OPPORTUNITIES FOR IMPROVEMENT (Clause 10) + Discussion: What improvement opportunities have been identified? + Decision/Action: + +12. QMS CHANGE NEEDS (Clause 6.3) + Discussion: Are any changes needed to the QMS structure, processes, or documentation? + Decision/Action: + +--- + +ACTION REGISTER (OUTPUTS — Clause 9.3.3) + +| Action Ref | Action Description | Owner | Due Date | Status | +|-----------|-------------------|-------|----------|--------| +| MR-[YY]-01 | [Action] | [Name] | [Date] | Open | + +--- + +NEXT MANAGEMENT REVIEW: [Date] + +Minutes approved by: _____________________________ Date: ___________ + [Name, Title — Top Management] +``` + +--- + +## Template 8 — Supplier Evaluation Form + +``` +[ORGANISATION NAME] +SUPPLIER EVALUATION AND QUALIFICATION FORM + +Supplier Name: _____________________________ Date: ___________ +Address: _________________________________________ +Contact: _____________________________ Phone/Email: ___________ +Products/Services to be supplied: ___________________________ +Evaluation type: [ ] Initial qualification [ ] Annual re-evaluation [ ] Following SCAR + +--- + +SECTION 1 — QUALITY SYSTEM ASSESSMENT + +| Criterion | Score (1–5) | Evidence / Comments | +|-----------|------------|-------------------| +| Quality management certification (ISO 9001 or equivalent) | | | +| Quality system documentation (procedures, work instructions) | | | +| Inspection and test capability | | | +| Calibrated measurement equipment | | | +| Corrective action process | | | +| Document control | | | +| Traceability capability | | | + +--- + +SECTION 2 — DELIVERY AND OPERATIONAL PERFORMANCE +(Complete for re-evaluations with performance data) + +| Metric | Performance (last 12 months) | Target | Pass/Fail | +|--------|------------------------------|--------|-----------| +| On-time delivery rate | % | ≥ [X]% | | +| Quality acceptance rate (incoming inspection) | % | ≥ [X]% | | +| Number of SCARs issued | | ≤ [N] | | +| SCAR response and closure rate | % | 100% within [N] days | | + +--- + +SECTION 3 — FINANCIAL STABILITY AND CAPACITY +| Criterion | Assessment | Comments | +|-----------|-----------|---------| +| Business viability (longevity, references) | | | +| Capacity to meet our volume requirements | | | +| Business continuity / contingency planning | | | + +--- + +SECTION 4 — REGULATORY AND LEGAL COMPLIANCE +| Criterion | Compliant? | Evidence | +|-----------|-----------|---------| +| Relevant regulatory approvals/certifications | | | +| Environmental and HSE compliance | | | +| Conflict minerals / ethical supply chain | | | + +--- + +SECTION 5 — OVERALL ASSESSMENT + +Total Score: ______ / [Maximum] + +Recommendation: +[ ] Approved — add to Approved Supplier List (ASL) +[ ] Conditionally approved — with conditions: ___________________________ +[ ] Not approved — reason: ___________________________ + +Evaluated by: _____________________________ Date: ___________ +Approved by (QA/Procurement Manager): _____________________________ Date: ___________ + +Next re-evaluation due: ___________ +``` + +--- + +## Template 9 — Competency Matrix + +``` +[ORGANISATION NAME] +COMPETENCY MATRIX + +Document ID: CM-001 | Version: 1.0 | Owner: HR / Quality Manager +Effective Date: [DATE] | Review Frequency: Annually + +Rating Scale: 4 = Expert (can train others) | 3 = Proficient (works independently) | + 2 = Developing (requires supervision) | 1 = Awareness only | — = Not required + +--- + +| Competency / Skill | Role 1: [Title] | Role 2: [Title] | Role 3: [Title] | Role 4: [Title] | +|--------------------|----------------|----------------|----------------|----------------| +| ISO 9001:2015 requirements | Required: 3 | Required: 2 | Required: 2 | Required: 1 | +| Internal auditing (ISO 19011) | Required: 4 | Required: — | Required: — | Required: — | +| Drawing / specification interpretation | Required: 3 | Required: 3 | Required: — | Required: — | +| [Equipment/process name] operation | Required: — | Required: 4 | Required: 4 | Required: — | +| Customer complaint handling | Required: 3 | Required: — | Required: — | Required: 3 | +| Root cause analysis techniques | Required: 3 | Required: 2 | Required: — | Required: — | +| [Add more competencies as relevant] | | | | | + +--- + +INDIVIDUAL COMPETENCY ASSESSMENT + +Employee Name: _____________________________ Role: _______________ +Assessed by: _____________________________ Date: _______________ + +| Competency | Required Level | Current Level | Gap | Training Action | Due Date | Completed | +|------------|--------------|--------------|-----|----------------|----------|-----------| +| [Competency] | [3] | [2] | Yes | [Training course/OJT] | [Date] | [ ] | +``` + +--- + +## Template 10 — Customer Satisfaction Survey + +``` +[ORGANISATION NAME] +CUSTOMER SATISFACTION SURVEY + +Dear [Customer name / "Valued Customer"], + +As part of our commitment to quality and continuous improvement, we would appreciate your +feedback on our recent [products/services]. This survey takes approximately 3 minutes. + +Your responses are used to improve our QMS and are reviewed at our management review. + +--- + +RATING SCALE: 5 = Excellent | 4 = Good | 3 = Acceptable | 2 = Below Expectations | 1 = Poor | N/A = Not applicable + +| Area | Rating (1–5) | Comments | +|------|-------------|---------| +| Product/service quality — met your specifications? | | | +| Product/service reliability | | | +| On-time delivery / project milestone achievement | | | +| Responsiveness of our team to enquiries and requests | | | +| Quality of technical support / customer service | | | +| Accuracy of documentation (invoices, delivery notes, CoCs) | | | +| Value for money | | | +| Overall satisfaction | | | + +--- + +Would you recommend [Organisation Name] to others? [ ] Yes [ ] No [ ] Maybe + +What could we improve? (open text): ___________________________ + +What did we do well? (open text): ___________________________ + +May we follow up with you on this feedback? [ ] Yes — Contact: ___________ [ ] No + +Thank you for your time. Please return this survey to: [email / online portal URL] + +--- + +[Internal use only — do not share with customer] +Survey Ref: CS-[YYYY]-[NNN] | Customer: [Name] | Order/Project Ref: [Ref] | Received: [Date] +Actioned by: [Name] | Action taken: [Description] | CAPA raised: [Yes/No — Ref] +``` diff --git a/plugins/iso9001/skills/iso9001/references/iso9001-quality-controls.md b/plugins/iso9001/skills/iso9001/references/iso9001-quality-controls.md new file mode 100644 index 0000000..a01e45d --- /dev/null +++ b/plugins/iso9001/skills/iso9001/references/iso9001-quality-controls.md @@ -0,0 +1,228 @@ +# ISO 9001:2015 — Quality Process Controls Reference + +This reference file provides a structured guide to the key quality process controls required under ISO 9001:2015, organised by process area. Load this file when providing implementation guidance for specific controls, generating audit checklists for process areas, or advising on QMS operational controls. + +--- + +## Process Control Framework + +ISO 9001:2015 uses the **process approach** — each process must have defined: +- **Inputs** (what triggers the process) +- **Outputs** (what the process produces) +- **Controls** (what governs how the process runs — procedures, work instructions, acceptance criteria) +- **Resources** (people, equipment, infrastructure, environment) +- **Performance indicators** (how we know the process is effective) +- **Risk treatment** (what prevents the process from failing) + +--- + +## 1. Customer-Related Controls (Clause 8.2) + +### Contract / Order Review +**Purpose:** Ensure the organisation can meet customer requirements before committing to supply. + +| Control | Description | Evidence | +|---------|-------------|---------| +| Customer requirements capture | Documented process for capturing all requirements (technical, delivery, regulatory, implicit) | Customer requirement form, specification sheet | +| Contract review checklist | Checklist reviewed before order acceptance: capacity, competence, materials, regulatory compliance | Completed contract review records | +| Conflict resolution | Process for resolving differences between tender and contract requirements | Contract amendment records, customer correspondence | +| Order acknowledgement | Confirm to customer all requirements understood and will be met | Order acknowledgement, signed contract | +| Change management | Process for handling customer-initiated changes after order acceptance | Change request form, revised order records | + +**Common gaps:** Verbal orders accepted without documented review; customer implied requirements (packaging, labelling) not captured; no process for managing requirement changes mid-order. + +--- + +### Customer Communication +**Purpose:** Maintain effective communication with customers throughout the relationship. + +| Control | Description | Evidence | +|---------|-------------|---------| +| Complaint handling | Defined process: receipt → acknowledgement → investigation → response → closure → CAPA | Complaint log, response records, CAPA records | +| Customer feedback | Systematic collection of customer satisfaction data beyond complaints | Surveys, NPS scores, customer scorecards | +| Product/service information | Up-to-date, accurate product/service information provided to customers | Product specifications, datasheets, catalogues | +| Customer property | Process for controlling items belonging to customers (tooling, moulds, data, IP) | Customer property register, loss/damage records | + +--- + +## 2. Supplier and External Provider Controls (Clause 8.4) + +### Supplier Qualification +**Purpose:** Ensure external providers meet quality requirements before being used. + +| Control | Description | Evidence | +|---------|-------------|---------| +| Approved Supplier List (ASL) | Maintained register of evaluated and approved external providers, with scope of approval | Current ASL with status and approval date | +| Supplier evaluation criteria | Defined criteria before initial approval: quality system, delivery performance, capacity, HSE, financial stability | Evaluation criteria matrix, questionnaire | +| New supplier qualification | Formal process: self-assessment questionnaire → sample evaluation → trial order → approval | Supplier qualification file | +| Supplier audit | On-site or remote audit of high-risk or critical suppliers | Supplier audit report, audit schedule | +| Approved supplier register maintenance | Regular re-evaluation at defined frequency; suspension/removal process | Re-evaluation records, approval status history | + +--- + +### Ongoing Supplier Performance Management +| Control | Description | Evidence | +|---------|-------------|---------| +| Supplier scorecard | Periodic performance rating: quality (incoming inspection pass rate), delivery (on-time %), responsiveness | Supplier scorecard / performance report | +| Supplier corrective action request (SCAR) | Formal process to issue a SCAR when supplier delivers nonconforming goods/services | SCAR log, supplier responses, closure records | +| Incoming inspection | Inspection/verification of externally provided goods before use in own processes | Incoming inspection records, test reports | +| Purchase order quality requirements | PO specifies: specification, revision level, acceptance criteria, certificate of conformance requirement, right of access | PO template with quality clauses | + +--- + +## 3. Production and Service Provision Controls (Clause 8.5) + +### Production Planning +| Control | Description | Evidence | +|---------|-------------|---------| +| Production/work order system | Job travellers or work orders linking customer order to production steps, materials, and resources | Work orders, job travellers, production schedule | +| Bill of materials / specification | Documented materials and components required for each product | BOM, product specification, routing | +| Work instructions | Step-by-step instructions for operators at the point of use | Work instructions, SOPs, visual aids | +| First Article Inspection (FAI) | Verification that a new or changed product/process meets requirements before production run | FAI report, first article sign-off record | + +--- + +### In-Process Controls +| Control | Description | Evidence | +|---------|-------------|---------| +| In-process inspection and testing | Defined inspection points during production; criteria and accept/reject decisions documented | Inspection and test plan (ITP), in-process inspection records | +| Statistical Process Control (SPC) | Control charts monitoring process parameters for trends before defects occur | SPC charts, Cpk/Ppk data | +| Error-proofing (Poka-yoke) | Devices or procedures that prevent or detect errors before they become defects | Error-proofing log, device verification records | +| Non-conforming product segregation | Clearly identified hold/reject area; quarantine procedure to prevent inadvertent use | Quarantine tags, segregated area signage, NC records | +| Process parameters monitoring | Critical process parameters (temperature, pressure, speed, dimensions) monitored and recorded | Process parameter logs, SPC charts | + +--- + +### Special Processes +Special processes are those where the resulting output cannot be fully verified by subsequent inspection (e.g. welding, heat treatment, plating, non-destructive testing, sterilisation). + +| Control | Description | Evidence | +|---------|-------------|---------| +| Special process validation | Process validated to demonstrate ability to achieve planned results before use in production | Validation plan, validation records, approval to proceed | +| Approved process operators | Only qualified/certified personnel perform special processes | Operator qualification records, certification log | +| Special process parameter records | Critical parameters (time, temperature, current, speed) recorded for each batch/job | Process run records, batch sheets | +| Periodic revalidation | Validate again after: equipment change, process change, extended downtime, personnel change | Revalidation records, change-triggered revalidation log | + +--- + +### Final Release Controls (Clause 8.6) +| Control | Description | Evidence | +|---------|-------------|---------| +| Final inspection and test | Criteria defined for final acceptance; must be completed before release | Final inspection records, test reports | +| Certificate of Conformance (CoC) | Document confirming product meets specified requirements, signed by authorised person | CoC, signed release record | +| Release authority | Only designated persons may authorise release to customer | Approved signatories list, release authorisation on CoC/delivery note | +| Release blocked until complete | No product released if planned inspection/verification activities incomplete (unless authorised concession) | Locked hold status in ERP/MES; concession record if applicable | + +--- + +### Traceability Controls (Clause 8.5.2) +| Control | Description | Evidence | +|---------|-------------|---------| +| Product/batch identification | Unique identification applied from receipt of materials through production to delivery | Batch/lot numbers, serial numbers, traveller ID | +| Traceability records | Ability to reconstruct: which materials used, which process run, which operators, which inspection results, which customers received | Batch records, production history database, delivery records | +| Recall capability | Demonstrate ability to identify and contact affected customers in the event of a product issue | Mock recall exercise records | + +--- + +## 4. Inspection and Test Controls (Clause 7.1.5, 8.6, 8.7) + +### Calibration and Measurement Equipment +**Purpose:** Ensure monitoring and measuring equipment provides valid results. + +| Control | Description | Evidence | +|---------|-------------|---------| +| Equipment register | All measuring equipment used for product/process verification listed with: ID, type, location, calibration interval, next due date, traceability | Calibration register / equipment master list | +| Calibration records | For each calibration: date, method, standard used, result (pass/adjusted/fail), next due date, performed by | Calibration certificates, internal calibration records | +| Traceable calibration standards | Calibration standards traceable to national/international measurement standards | UKAS/NVLAP calibration certificate for reference standards | +| Out-of-calibration response | Process: remove from service, assess impact on previous measurements, recall affected product if necessary, investigate root cause | Out-of-calibration NC record, impact assessment, recall records | +| Equipment status labelling | Equipment clearly labelled: calibrated/due for calibration/out of service | Calibration status labels on equipment | + +**Common gaps:** Equipment missing from register; calibration certificates lack traceability statement; no out-of-calibration impact assessment process; gauge R&R studies not conducted + +--- + +## 5. Nonconformity and Corrective Action Controls (Clause 8.7, 10.2) + +### Nonconforming Output Control +| Control | Description | Evidence | +|---------|-------------|---------| +| NC identification | All nonconforming product/service clearly identified immediately | NC tags, rejection stamps, system holds | +| NC segregation | Physical segregation of nonconforming product to prevent unintended use | Quarantine area, MRB (Material Review Board) area | +| NC disposition | Formal process: scrap / rework / use-as-is (concession) / return to supplier | Disposition record, MRB decision | +| Concession / waiver | Customer authorisation obtained for delivery of product that does not meet specification | Concession/deviation approval from customer | +| Rework control | Rework process defined; re-inspection required after rework | Rework instructions, post-rework inspection records | +| NC trend analysis | Periodic analysis of NC data to identify systemic issues requiring corrective action | NC Pareto analysis, NC summary report | + +--- + +### Corrective Action (CAPA) Process +| Step | Requirement | Evidence | +|------|------------|---------| +| 1. Description | Clear statement of the nonconformity: what, where, when, how discovered | NC report | +| 2. Containment | Immediate action to limit impact: quarantine, recall, customer notification | Containment record | +| 3. Root cause analysis | Systematic investigation: 5-Why, Fishbone/Ishikawa, Fault Tree Analysis | RCA record | +| 4. Corrective action plan | Actions to eliminate root cause: systemic, not just symptom fix | CA plan with owner and due date | +| 5. Implementation | Evidence that planned actions were carried out | Evidence of completion | +| 6. Effectiveness verification | Check that the corrective action eliminated the root cause and the NC has not recurred | Verification record (re-audit, process data, no recurrence after defined period) | +| 7. Closure | Formal closure by authorised person after effectiveness confirmed | Closed CAPA record | + +--- + +## 6. Document and Records Controls (Clause 7.5) + +### Document Control +| Control | Description | Evidence | +|---------|-------------|---------| +| Master document list | All controlled documents: ID, title, version, date, owner, review date | Master document register | +| Version control | Clear version numbering; change history log; obsolete versions removed from use | Version numbering convention, change log | +| Approval before issue | All controlled documents approved by authorised person before issue | Approval signatures / electronic workflow | +| Online/offline control | Ensure only current versions accessible at point of use | Document management system access controls; printed copy control stamps | +| External documents | Customer drawings, standards, regulatory documents identified and controlled | External document register, revision check process | +| Retention periods | Defined retention periods for each record type; secure storage and disposal | Record retention schedule | + +--- + +## 7. Internal Audit Controls (Clause 9.2) + +| Control | Description | Evidence | +|---------|-------------|---------| +| Annual audit programme | All processes and clauses covered over the audit cycle, with risk-adjusted frequency | Audit programme / schedule for the year | +| Audit plan | For each audit: scope, criteria, schedule, auditee, auditor (independent) | Individual audit plan | +| Audit checklist | Clause/process-by-process questions and evidence required | Completed audit checklist | +| Audit report | Findings: conformances, nonconformities (major/minor), observations | Formal audit report | +| NC follow-up | Corrective actions raised for all audit NCs; effectiveness verified before closure | CAPA linked to audit NC, closure evidence | +| Auditor competence | Internal auditors trained in auditing technique (ISO 19011 recommended) | Auditor training records, qualification evidence | + +--- + +## 8. Management Review Controls (Clause 9.3) + +| Input Required | Evidence | +|---------------|---------| +| Previous MR action status | Action log from prior MR showing open/closed status | +| Internal/external context changes | Updated context analysis, interested party register review | +| Customer satisfaction data | Survey results, complaint trends, NPS | +| Quality objective performance | KPI dashboard, objectives achievement report | +| Process performance and NC data | NC trend report, process KPI summary | +| Audit results | Internal audit summary, external audit findings | +| External provider performance | Supplier scorecard summary | +| Adequacy of resources | Resource needs assessment | +| Risk and opportunity action effectiveness | Risk register review | + +| Output Required | Evidence | +|----------------|---------| +| Improvement opportunities identified | Action items with owner and due date in MR minutes | +| QMS change needs | Change request or action for QMS revision | +| Resource decisions | Budget approvals, headcount decisions documented in MR minutes | + +--- + +## 9. Continual Improvement Controls (Clause 10.3) + +| Control | Description | Evidence | +|---------|-------------|---------| +| Improvement register | Log of improvement ideas, initiatives, and projects: source, description, status, result | Improvement log/tracker | +| Kaizen/CI events | Structured improvement events (lean kaizen, six sigma, PDCA) | Event reports, before/after metrics | +| Lessons learned | Capture and share lessons from nonconformities, near-misses, audits, and project reviews | Lessons learned database, knowledge-sharing records | +| Benchmarking | Compare performance against industry benchmarks or internal targets | Benchmarking report | +| Objective-to-action link | Improvement actions tied to specific quality objectives or performance gaps | Objective review → improvement action linkage in MR minutes | 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..131e8b6 100644 --- a/tests/test_plugin_structure.py +++ b/tests/test_plugin_structure.py @@ -36,12 +36,21 @@ "fedramp", "gdpr-compliance", "hipaa-compliance", + "iso13485", + "hitrust", + "iso22301", "iso27001", + "iso27017", + "iso31000", "iso42001", + "iso9001", "nist-csf", "pci-compliance", "soc2", "tsa-compliance", + "govramp", + "eu-ai-act", + "cmmc", } REQUIRED_PLUGIN_JSON_FIELDS = {"name", "version", "description"} @@ -186,7 +195,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..eeb93a0 100644 --- a/tests/test_skill_installability.py +++ b/tests/test_skill_installability.py @@ -179,20 +179,29 @@ 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", + "iso13485.skill", + "hitrust.skill", + "iso22301.skill", "iso27001.skill", + "iso27017.skill", + "iso31000.skill", "ISO-42001.skill", + "ISO-9001.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, (