diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 921d1ff..b2ea63e 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, ISO 27017, ISO 27018, SOC 2, FedRAMP, GDPR, HIPAA, HITRUST, NIST CSF, PCI DSS, TSA Cybersecurity, ISO 42001 AI Management System, ISO 9001, ISO 13485 Medical Device QMS, GovRAMP, CMMC, ISO 31000, and EU AI Act, and UK Cyber Security and Resilience Bill.", "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", @@ -31,7 +53,7 @@ { "name": "soc2", "source": "./plugins/soc2", - "description": "Expert SOC 2 compliance advisor covering all Trust Services Criteria \u2014 gap analysis, policy drafting, control documentation, audit evidence, and vendor risk.", + "description": "Expert SOC 2 compliance advisor covering all Trust Services Criteria — gap analysis, policy drafting, control documentation, audit evidence, and vendor risk.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -51,7 +73,7 @@ { "name": "fedramp", "source": "./plugins/fedramp", - "description": "End-to-end FedRAMP authorization guidance \u2014 readiness assessments, SSP narratives, POA&M management, NIST 800-53 Rev 5 control mapping, and ConMon support.", + "description": "End-to-end FedRAMP authorization guidance — readiness assessments, SSP narratives, POA&M management, NIST 800-53 Rev 5 control mapping, and ConMon support.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -73,7 +95,7 @@ { "name": "gdpr-compliance", "source": "./plugins/gdpr-compliance", - "description": "GDPR compliance assistant \u2014 code and system audits, privacy notice drafting, DPAs, DPIAs, data flow reviews, and authoritative article-cited Q&A.", + "description": "GDPR compliance assistant — code and system audits, privacy notice drafting, DPAs, DPIAs, data flow reviews, and authoritative article-cited Q&A.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -94,7 +116,7 @@ { "name": "hipaa-compliance", "source": "./plugins/hipaa-compliance", - "description": "HIPAA compliance advisor covering Privacy Rule, Security Rule, and Breach Notification \u2014 document generation, technical safeguards for cloud, and breach response.", + "description": "HIPAA compliance advisor covering Privacy Rule, Security Rule, and Breach Notification — document generation, technical safeguards for cloud, and breach response.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -115,7 +137,7 @@ { "name": "nist-csf", "source": "./plugins/nist-csf", - "description": "NIST Cybersecurity Framework (CSF 2.0 and 1.1) advisor \u2014 gap assessments, organisational profiles, implementation tiers, roadmaps, cross-framework mapping, and cybersecurity policy generation.", + "description": "NIST Cybersecurity Framework (CSF 2.0 and 1.1) advisor — gap assessments, organisational profiles, implementation tiers, roadmaps, cross-framework mapping, and cybersecurity policy generation.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -136,10 +158,10 @@ ] }, { - "name": "pci-compliance", - "source": "./plugins/pci-compliance", - "description": "PCI DSS v4.0.1 compliance advisor \u2014 CDE scoping, SAQ selection, gap assessments, control implementation guidance, QSA audit preparation, and remediation planning.", - "version": "0.3.0", + "name": "pci-dss", + "source": "./plugins/pci-dss", + "description": "PCI DSS compliance advisor covering all versions v1.0 through v4.0.1 \u2014 CDE scoping, SAQ selection, gap assessments, version migration planning, control implementation guidance, QSA audit preparation, and remediation planning.", + "version": "1.0.0", "author": { "name": "Hemant Naik", "email": "hemant.naik@gmail.com" @@ -148,19 +170,23 @@ "category": "compliance", "keywords": [ "pci-dss", + "pci-dss-v4", + "pci-dss-v3", "pci-compliance", "payment-security", "cardholder-data", "cde", "saq", "qsa", + "roc", + "aoc", "grc" ] }, { "name": "tsa-compliance", "source": "./plugins/tsa-compliance", - "description": "TSA cybersecurity compliance advisor for critical infrastructure \u2014 pipeline, freight rail, and transit Security Directive requirements including CIP/COIP, IRP, ADR, CAP, incident reporting, and OT/ICS security.", + "description": "TSA cybersecurity compliance advisor for critical infrastructure — pipeline, freight rail, and transit Security Directive requirements including CIP/COIP, IRP, ADR, CAP, incident reporting, and OT/ICS security.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -179,10 +205,101 @@ "grc" ] }, + { + "name": "iso9001", + "source": "./plugins/iso9001", + "description": "ISO 9001:2015 Quality Management System (QMS) advisor — 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": "iso27018", + "source": "./plugins/iso27018", + "description": "ISO/IEC 27018 compliance advisor for public cloud PII processors — Annex A extended control gap analysis, DPA drafting, sub-processor programme management, government request procedures, PII disposal obligations, and mapping to GDPR, ISO 27701, and regional privacy laws.", + "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": [ + "iso27018", + "pii", + "cloud-privacy", + "data-protection", + "gdpr", + "public-cloud", + "pii-processor", + "compliance", + "grc" + ] + }, + { + "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", - "description": "ISO 42001 AI Management System (AIMS) advisor \u2014 gap analysis, AI risk assessment, AI system impact assessment (AISIA), Annex A control guidance, SoA generation, policy writing, and certification readiness for ISO/IEC 42001:2023.", + "description": "ISO 42001 AI Management System (AIMS) advisor — gap analysis, AI risk assessment, AI system impact assessment (AISIA), Annex A control guidance, SoA generation, policy writing, and certification readiness for ISO/IEC 42001:2023.", "version": "0.3.0", "author": { "name": "Hemant Naik", @@ -200,6 +317,221 @@ "aisia", "grc" ] + }, + { + "name": "soc", + "source": "./plugins/soc", + "description": "AICPA System and Organization Controls (SOC) advisor covering SOC 1 (SSAE 18), SOC 3, SOC for Cybersecurity, and SOC for Supply Chain — report selection, scoping, control objectives, readiness assessment, and audit preparation.", + "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": [ + "soc", + "soc1", + "soc3", + "ssae18", + "aicpa", + "service-organization", + "audit", + "icfr", + "cybersecurity", + "supply-chain", + "grc" + ] + }, + { + "name": "uk-nis", + "source": "./plugins/uk-nis", + "description": "UK NIS Regulations 2018 compliance advisor — Operators of Essential Services (OES), Digital Service Providers (DSPs), NCSC Cyber Assessment Framework (CAF) gap assessments, incident reporting, Competent Authority requirements, and enforcement guidance.", + "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": [ + "uk-nis", + "nis-regulations", + "cyber-assessment-framework", + "caf", + "ncsc", + "oes", + "dsp", + "critical-infrastructure", + "cybersecurity", + "grc" + ] + }, + { + "name": "iso27701", + "source": "./plugins/iso27701", + "description": "ISO/IEC 27701:2019 Privacy Information Management System (PIMS) advisor — gap analysis, PII Controller and PII Processor control guidance, privacy impact assessments, GDPR mapping, records of processing activities, PII principal rights workflows, and certification readiness as an extension to ISO 27001.", + "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": [ + "iso27701", + "pims", + "privacy", + "pii", + "gdpr", + "data-protection", + "privacy-information-management", + "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 — 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 — 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" + ] + }, + { + "name": "uk-nis-csrb", + "source": "./plugins/uk-nis-csrb", + "description": "UK Cyber Security and Resilience Bill (CSRB) readiness advisor — expanded MSP and data centre scope, enhanced incident reporting, proactive regulator powers, transition planning from NIS Regulations 2018, and compliance templates.", + "version": "1.0.0", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@users.noreply.github.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "category": "compliance", + "keywords": [ + "uk-csrb", + "cyber-security-resilience-bill", + "csrb", + "nis-regulations", + "managed-service-providers", + "incident-reporting", + "critical-infrastructure", + "data-centres", + "dsit", + "ncsc", + "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 27018 - Claude Skill/ISO-27018-README.md b/ISO 27018 - Claude Skill/ISO-27018-README.md new file mode 100644 index 0000000..5dd03f8 --- /dev/null +++ b/ISO 27018 - Claude Skill/ISO-27018-README.md @@ -0,0 +1,154 @@ +# ISO/IEC 27018 Compliance Skill for Claude + +A comprehensive Claude skill that provides expert guidance on ISO/IEC 27018 — the international standard for protecting personally identifiable information (PII) in public cloud environments where the cloud provider acts as a PII processor. + +> **Disclaimer:** This skill provides informational guidance based on publicly available information about ISO/IEC 27018. It does not constitute legal advice. For formal compliance determinations, legal interpretations, or procurement of the official standard text, consult qualified legal and compliance professionals and obtain the official ISO/IEC 27018 standard from ISO or your national standards body. + +--- + +## What Does This Skill Do? + +The ISO/IEC 27018 Compliance Skill transforms Claude into an expert cloud PII compliance advisor, providing structured guidance across the full range of obligations that apply to public cloud service providers processing personally identifiable information on behalf of their customers. + +The skill covers **ISO/IEC 27018:2025 (third edition)** — the current version, aligned with ISO/IEC 27002:2022 — and also addresses **ISO/IEC 27018:2019 (second edition)** for organisations working with the previous version. It understands all Annex A extended controls, their relationship to ISO 29100 privacy principles, and how ISO 27018 maps to GDPR, ISO 27701, ISO 27017, and ISO 27001. + +At a high level, the skill does five things: + +1. **Gap analysis against ISO 27018 Annex A** — Assesses where a cloud provider stands against all extended PII controls, producing structured gap tables with status, evidence needed, and priority remediation steps. + +2. **Policy and document generation** — Drafts ready-to-use documents including PII Protection Policies, Data Processing Agreement (DPA) addenda, sub-processor agreement schedules, government request handling procedures, breach notification letters, and end-of-contract PII disposal confirmations. + +3. **Control implementation guidance** — Provides concrete, actionable guidance on implementing any ISO 27018 obligation, including technical safeguards, organisational measures, sub-processor management, and staff training. + +4. **Compliance mapping** — Maps ISO 27018 obligations to GDPR articles, ISO 27701 controls, ISO 27017 controls, ISO 27001 Annex A, and ISO 29100 privacy principles; also covers alignment with national privacy laws including UK GDPR, CCPA, LGPD, DPDP Act, and others. + +5. **Operational procedures** — Provides step-by-step procedures for government request handling, sub-processor due diligence, data residency transparency, customer audit support, and PII incident management. + +The skill is backed by four detailed reference files covering Annex A controls, PII protection implementation guidance, document templates, and compliance mapping — loaded selectively based on what the question requires. + +--- + +## Standard Overview + +| Attribute | Details | +|-----------|---------| +| Full name (2025) | ISO/IEC 27018:2025 — Information security, cybersecurity and privacy protection — Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors | +| Current edition | Third edition, August 2025 | +| Previous edition | Second edition, 2019 (withdrawn) | +| Published by | ISO/IEC JTC 1/SC 27 | +| Base standard | ISO/IEC 27002:2022 (third edition) | +| Core relationship | Extends ISO 27002 with PII-specific controls; implements ISO 29100 privacy principles in cloud context | + +--- + +## Who Is This Skill For? + +This skill is designed for organisations and practitioners involved in cloud privacy compliance: + +| Audience | How They Use the Skill | +|----------|----------------------| +| **Cloud Service Providers (CSPs)** | Understand and implement ISO 27018 obligations; draft DPA terms; manage sub-processor programmes | +| **Privacy Officers / DPOs** | Gap analysis, policy generation, GDPR Article 28 compliance support, audit evidence preparation | +| **Security Teams at CSPs** | Technical safeguard guidance for PII encryption, access control, logging, incident response | +| **Legal Teams** | Draft data processing agreement clauses; understand government request obligations; advise on sub-processor contracts | +| **Cloud Customers (Controllers)** | Understand what CSP obligations ISO 27018 imposes; questions to ask in vendor assessments; DPA review guidance | +| **Compliance Managers** | Compliance mapping to GDPR, ISO 27701, regional laws; certification strategy | +| **Auditors and Assessors** | Gap analysis frameworks, evidence requirements, audit question prompts | +| **Software Developers at CSPs** | Privacy by design guidance; technical safeguards; temporary file PII handling; deletion API requirements | + +--- + +## Common Use Cases + +### Gap Analysis +- "Perform an ISO 27018 gap analysis for our IaaS platform" +- "We're implementing ISO 27018 — where should we start?" +- "Identify gaps in our sub-processor management programme against ISO 27018" +- "We have ISO 27001 — what additional controls does ISO 27018 require?" + +### Policy and Document Generation +- "Draft an ISO 27018-compliant PII Protection Policy" +- "Generate a data processing agreement addendum based on ISO 27018 obligations" +- "Create a sub-processor agreement schedule with ISO 27018 terms" +- "Write a government request handling procedure" +- "Draft a PII disposal confirmation letter for a customer whose contract is ending" + +### Control Implementation Guidance +- "How do I implement 'no use of PII for marketing purposes' under ISO 27018?" +- "What technical controls do I need for PII encryption under ISO 27018?" +- "How should we handle government requests for customer data under ISO 27018?" +- "What does ISO 27018 require for our sub-processor programme?" +- "How do I support customer audit rights under ISO 27018?" + +### Compliance Mapping +- "How does ISO 27018 relate to GDPR Article 28?" +- "Map ISO 27018 to ISO 27701 — what additional controls does 27701 require?" +- "How does ISO 27018 compare to ISO 27017?" +- "Does ISO 27018 compliance support LGPD compliance in Brazil?" +- "We have ISO 27001 — what's the path to demonstrating ISO 27018 compliance?" + +### Operational Procedures +- "We received a request from law enforcement for customer data. What do we do?" +- "A customer contract is ending — walk me through PII return and deletion obligations" +- "We need to add a new sub-processor — what's the process?" +- "We've had a security incident involving customer PII — what must we do?" + +### Certification and Evidence +- "What certifications can demonstrate ISO 27018 compliance?" +- "What evidence should we prepare for customer audits of our ISO 27018 compliance?" +- "What does a CSP need to show for GDPR Article 28 compliance?" + +--- + +## How to Use the Skill + +Once installed in Claude, the skill activates automatically whenever you ask about ISO 27018, cloud PII processing obligations, PII processor requirements, or related compliance topics. You do not need to reference the skill by name. + +### Tips for Best Results + +**Specify your role** — are you a cloud service provider (CSP), a cloud customer (controller), or both? This helps the skill tailor its guidance correctly. + +**Specify the version** — are you working with ISO 27018:2025 or ISO 27018:2019? The skill defaults to 2025 if not specified. + +**Provide context about your service** — what type of cloud service (IaaS, PaaS, SaaS)? What categories of PII are processed? What regions are involved? What existing certifications does the organisation hold? + +**Be specific about the task** — ask for a gap analysis, a specific document, or guidance on a specific control. The skill handles complex multi-step tasks but produces more useful outputs when the request is focused. + +**Example prompts:** +> "We're a SaaS company processing HR data for our enterprise customers in the EU. Run an ISO 27018 gap analysis and tell us our top five remediation priorities." + +> "Draft an ISO 27018-aligned Data Processing Addendum clause covering sub-processor obligations, government request handling, and PII deletion at contract end." + +> "We use three sub-processors for our cloud platform. Walk me through what ISO 27018 requires for our sub-processor management programme." + +--- + +## What the Skill Does Not Do + +- It does not provide legal advice; always consult qualified legal professionals for formal compliance determinations +- It does not access your live systems or assess your actual security configuration +- It does not provide the full text of the ISO/IEC 27018 standard — to obtain the official standard, purchase it from ISO (iso.org) or your national standards body +- It does not fully substitute for specialist GDPR legal advice, particularly for obligations that fall on PII controllers (rather than processors) +- It does not cover ISO 27018 compliance for private cloud or on-premises environments (the standard applies specifically to public cloud PII processors) + +--- + +## Skill Contents + +This skill package includes: + +| Component | Description | +|-----------|-------------| +| `SKILL.md` | Core skill instructions and framework | +| `references/annex-a-controls.md` | Complete Annex A extended control set by privacy principle | +| `references/pii-protection-guidance.md` | Technical safeguards, organisational measures, sub-processor management | +| `references/templates.md` | 10 ready-to-use document templates | +| `references/compliance-mapping.md` | ISO 27018 mappings to GDPR, ISO 27701, ISO 27017, ISO 27001, ISO 29100, and regional laws | + +--- + +## Version History + +| Version | Date | Notes | +|---------|------|-------| +| 1.0.0 | April 2026 | Initial release — covers ISO 27018:2025 and ISO 27018:2019 | diff --git a/ISO 27018 - Claude Skill/iso27018.skill b/ISO 27018 - Claude Skill/iso27018.skill new file mode 100644 index 0000000..6d8da58 Binary files /dev/null and b/ISO 27018 - Claude Skill/iso27018.skill differ diff --git a/ISO 27701 - Claude Skill/ISO-27701-README.md b/ISO 27701 - Claude Skill/ISO-27701-README.md new file mode 100644 index 0000000..1e0ada9 --- /dev/null +++ b/ISO 27701 - Claude Skill/ISO-27701-README.md @@ -0,0 +1,134 @@ +# ISO 27701 Privacy Information Management System Skill for Claude + +A Claude skill that provides expert, end-to-end guidance for implementing, auditing, and certifying a Privacy Information Management System (PIMS) under ISO/IEC 27701:2019 — the international standard that extends ISO 27001 to include privacy management for PII Controllers and PII Processors. + +--- + +## What Does the Skill Do? + +This skill turns Claude into a knowledgeable ISO 27701 compliance advisor. It covers the full lifecycle of PIMS implementation and certification, from initial gap assessment through to policy generation, control implementation, and audit readiness. + +At a high level, the skill enables Claude to: + +- Define the **PIMS scope** — documenting PII types, PII principals, processing purposes, controller and/or processor roles, and applicable privacy laws +- Conduct **gap analyses** covering both the Clause 5 ISMS extension requirements and the applicable Clause 7 (PII Controller) and/or Clause 8 (PII Processor) control sets +- Guide the creation of a **PIMS Statement of Applicability (PIMS-SoA)** recording control applicability determinations and justifications +- Assist with **Privacy Impact Assessments (PIA / DPIA)** including trigger screening, risk rating, measure selection, and documentation +- Generate **PIMS documentation**: privacy policy, data retention policy, records of processing activities (RoPA), consent records, PII principal rights procedures, privacy incident reports, and processor contracts +- Map ISO 27701 controls and requirements to **GDPR articles**, ISO 29100 privacy principles, ISO 27018, and ISO 29151 +- Provide granular **control implementation guidance** for every clause 7 and clause 8 control, structured as: Purpose, Requirements, Implementation Steps, Evidence, Common Pitfalls, and GDPR relevance +- Support **PII principal rights** workflows covering access, rectification, erasure, objection, consent withdrawal, portability, and automated decision-making rights +- Advise on the **certification path** — prerequisites, combined ISO 27001/27701 audit process, and a certification-readiness checklist + +--- + +## Intended Audiences + +| Audience | How They Benefit | +|---|---| +| **Privacy Officers / DPOs** | Navigate PIMS implementation, draft policies, manage PIAs, oversee controller/processor obligations | +| **GRC / Compliance Teams** | Perform gap analyses, build the PIMS-SoA, prepare for certification, maintain the RoPA | +| **Legal Teams** | Understand ISO 27701 requirements relative to GDPR and other applicable laws, draft processor agreements | +| **IT / Engineering Teams** | Implement privacy by design, configure data minimisation, build rights fulfilment mechanisms, manage retention | +| **Internal Auditors** | Scope and conduct PIMS audits, evaluate control implementation, generate audit findings | +| **Cloud Service Providers** | Understand Clause 8 processor controls, manage sub-processor obligations, handle government access requests | +| **ISO 27001 Practitioners** | Understand how ISO 27701 extends their existing ISMS and what additional work is needed for PIMS certification | +| **Consultants and Advisory Firms** | Provide accurate ISO 27701 guidance to clients across industries | + +--- + +## Common Use Cases + +### 1. Initial Gap Assessment +> *"We are ISO 27001 certified and want to extend to ISO 27701. Where do we start?"* + +The skill establishes whether the organisation acts as a controller, processor, or both, then generates a structured gap analysis table covering all Clause 5 ISMS extensions and all applicable Clause 7 and/or Clause 8 controls, with status, evidence needed, and gap notes. + +### 2. PIMS Scope Definition +> *"Help me define the scope of our PIMS."* + +The skill guides the user through documenting PII types, PII principals, processing purposes, applicable privacy laws, controller/processor roles, and geographic extent — producing a PIMS scope statement. + +### 3. Privacy Policy Drafting +> *"Draft an external privacy notice for our SaaS platform."* + +The skill generates a complete, structured external privacy notice meeting the disclosure requirements of GDPR Art. 13 and equivalent laws, populated with the user's processing details. + +### 4. Records of Processing Activities +> *"Generate a RoPA template for a PII Controller."* + +The skill produces a complete RoPA structure with all fields required by ISO 27701 Clause 7.2.8 and GDPR Art. 30, pre-populated with example entries and guidance on completion. + +### 5. Privacy Impact Assessment +> *"We're launching a new AI-based recommendation engine that profiles users. Do we need a DPIA and how do we conduct it?"* + +The skill confirms the PIA is required based on systematic profiling, then guides the user through the screening, description, necessity assessment, risk rating, measure selection, and sign-off stages. + +### 6. Control Implementation Guidance +> *"How do we implement ISO 27701 control 7.2.6 — Contracts with PII Processors?"* + +The skill provides detailed implementation guidance covering the purpose of the control, minimum contract provisions, implementation steps, evidence an auditor will look for, and the GDPR Art. 28 alignment. + +### 7. GDPR Mapping +> *"How does ISO 27701 map to GDPR?"* + +The skill provides a comprehensive control-level mapping between ISO 27701 clauses and GDPR articles, with compliance notes on what each mapping means in practice. + +### 8. PII Principal Rights Workflows +> *"A customer has submitted a Subject Access Request. Walk me through the process."* + +The skill steps through the SAR workflow: identity verification, request scoping, locate-and-compile, redaction of third-party data, response within legal deadlines, and documentation. + +### 9. Certification Readiness Assessment +> *"Are we ready for ISO 27701 certification? What is the audit process?"* + +The skill produces a structured certification-readiness checklist covering all evidence requirements for Stage 1 and Stage 2 audit, and explains the combined ISO 27001/27701 certification model. + +### 10. Processor Controls Guidance +> *"We are a cloud SaaS provider. What are our ISO 27701 obligations as a PII Processor?"* + +The skill provides a complete walkthrough of all 15 Clause 8 controls, with implementation guidance specific to cloud service provider contexts, including sub-processor management and government access request handling. + +--- + +## Framework Coverage + +| Area | Coverage | +|------|----------| +| ISO 27701:2019 Clause 5 | All ISMS extension requirements (5.2–5.8) | +| ISO 27701:2019 Clause 6 | Privacy-specific guidance for ISO 27002 controls | +| ISO 27701:2019 Clause 7 | All 27 PII Controller controls (7.2.1–7.5.3) | +| ISO 27701:2019 Clause 8 | All 15 PII Processor controls (8.2.1–8.5.6) | +| GDPR Mapping | Full control-to-article mapping with compliance notes | +| ISO 29100 | All 11 privacy principles with control alignment | +| ISO 27018 | Processor control comparison (Annex E alignment) | +| ISO 29151 | Controller control comparison (Annex D alignment) | +| Document Templates | Privacy policy, RoPA, PIA, consent records, rights log, incident report | + +--- + +## How to Install + +See [INSTALLATION.md](../INSTALLATION.md) for instructions on installing Claude skills. + +For this skill, the `.skill` file is: `iso27701.skill` + +--- + +## Relationship to Other Skills in This Repository + +ISO 27701 is an extension standard. The following companion skills complement this one: + +| Skill | Reason to Use Alongside ISO 27701 | +|-------|----------------------------------| +| **iso27001** | ISO 27701 cannot be certified without ISO 27001 as a foundation; use both skills for integrated ISMS + PIMS work | +| **gdpr-compliance** | For deep GDPR legal analysis, article-by-article advice, and GDPR-specific document drafting | +| **iso27018** | For cloud PII Processor contexts where ISO 27018 is also in scope | + +--- + +## Source and Standard Version + +This skill is based on **ISO/IEC 27701:2019** — the first and current edition, published 6 August 2019 by the International Organization for Standardization and the International Electrotechnical Commission. + +The standard is available for purchase from ISO (iso.org) and national standards bodies. All control descriptions and requirements in this skill are derived from the published standard and its informative annexes. diff --git a/ISO 27701 - Claude Skill/iso27701.skill b/ISO 27701 - Claude Skill/iso27701.skill new file mode 100644 index 0000000..9aa61ca Binary files /dev/null and b/ISO 27701 - Claude Skill/iso27701.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 42001 - Claude Skill/ISO-42001-README.md b/ISO 42001 - Claude Skill/ISO-42001-README.md index 8faaa4f..aa56c25 100644 --- a/ISO 42001 - Claude Skill/ISO-42001-README.md +++ b/ISO 42001 - Claude Skill/ISO-42001-README.md @@ -6,51 +6,77 @@ Expert ISO/IEC 42001:2023 AI Management System (AIMS) compliance advisor for Cla ## What This Skill Does -The ISO 42001 skill transforms Claude into a knowledgeable ISO/IEC 42001:2023 Lead Auditor and AIMS implementation consultant. It covers the world's first international standard for AI Management Systems in full — from gap assessment through certification readiness, with deep coverage of AI risk assessment, AI System Impact Assessment (AISIA), all 38 Annex A controls, and AI governance policy generation. +The ISO 42001 skill transforms Claude into a knowledgeable ISO/IEC 42001:2023 Lead Auditor and AIMS implementation consultant. It covers the world's first international standard for AI Management Systems in full — from gap assessment through certification readiness, with deep coverage of AI risk assessment, AI System Impact Assessment (AISIA), all 38 Annex A controls, Annex B implementation guidance, Annex C responsible AI objectives, EU AI Act alignment, and ready-to-use AIMS document templates. **Designed for:** - AI providers (organisations that develop, train, or deploy AI systems) - AI users (organisations that integrate third-party AI into their operations) -- GRC, compliance, and legal teams managing AI governance obligations -- Software and data science teams needing to understand what controls apply to their AI systems -- Organisations aligning to the EU AI Act who need an AIMS foundation -- Certification bodies and auditors needing reference material +- GRC, compliance, legal, and ethics teams managing AI governance obligations +- Software and data science teams building AI systems who need to understand what controls apply +- Organisations preparing for EU AI Act compliance who need an AIMS foundation (Articles 9–15, 26–27) +- Certification bodies and auditors conducting ISO 42001 conformity assessments --- ## Capabilities ### Gap Analysis -Structured assessment across all mandatory clauses (4–10) and all 38 Annex A controls. Outputs a prioritised gap register with 🔴/🟡/🟢 status, evidence requirements, and a phased remediation roadmap. +Structured assessment across all mandatory clauses (4–10) and all 38 Annex A controls. Outputs a prioritised gap register with status indicators, evidence requirements per clause, and a phased remediation roadmap. ### AI System Impact Assessment (AISIA) -Guides the mandatory AISIA process step by step — documenting AI systems, identifying affected populations, assessing impact dimensions (severity, reversibility, breadth, consent, human oversight), classifying impact level (Low/Medium/High), and determining proportionate control requirements. +Guides the mandatory AISIA process step by step — documenting AI systems, identifying affected populations, assessing all impact dimensions (severity, reversibility, breadth, consent, human oversight, societal concerns), classifying impact level (Low/Medium/High), and determining proportionate control requirements. AISIA records also function as EU AI Act Article 27 Fundamental Rights Impact Assessment (FRIA) records. ### AI Risk Assessment -Covers all AI risk categories — model risks (bias, drift, hallucination, adversarial), data risks (quality, poisoning, privacy), operational risks (scope creep, human over-reliance), and supply chain risks (third-party models, API dependencies). Outputs a risk register with likelihood × severity scoring and risk treatment decisions. +Covers all AI risk categories — model risks (bias, drift, hallucination, adversarial attacks, overfitting), data risks (quality, poisoning, privacy, representativeness), operational risks (scope creep, human over-reliance, unexpected outputs), supply chain risks (third-party models, API dependency, vendor lock-in), and regulatory/reputational risks. Outputs a risk register with likelihood × severity scoring and treatment decisions. ### Statement of Applicability (SoA) -Generates a complete SoA table covering all 38 Annex A controls with applicability decisions, justifications, and implementation status — ready for auditor review. +Generates a complete SoA table covering all 38 Annex A controls with applicability decisions by organisational role (provider/user/both), justifications, and implementation status — ready for auditor review. ### Policy Generation -Drafts all core AIMS policies with document control blocks, ISO 42001 clause and control citations, and responsible AI principles integrated: +Drafts all core AIMS policies with document control blocks, ISO 42001 clause and control citations, and responsible AI principles (Annex C) integrated: - AI Policy (Clause 5.2) -- AI Risk Management Policy -- AI Acceptable Use Policy -- Data Governance for AI Policy -- AI Incident Management Policy -- AI System Lifecycle Policy -- AI Supplier Management Policy +- AI Risk Management Policy (Clause 6) +- AI Acceptable Use Policy (A.4.1) +- Data Governance for AI Policy (A.7) +- AI Incident Management Policy (A.8.3) +- AI System Lifecycle Policy (A.5) +- AI Supplier Management Policy (A.9.1) + +### Complete Document Templates +Ready-to-use templates for all mandatory and key AIMS documents: +- AIMS Scope Document (Clause 4.3) +- AI System Register (Clauses 4, 6.1.2) +- AI Policy (Clause 5.2) +- RACI Matrix for AI Governance (Clause 5.3) +- AI Risk Assessment Record (Clauses 6.1.2, 8.2) +- AISIA Record (Clauses 6.1.2, A.6.1–A.6.3) +- Statement of Applicability — all 38 controls (Clause 6.1.3) +- AI Objectives Register (Clause 6.2) +- AI Incident Record (Clause 8, A.8.3) +- Internal AIMS Audit Checklist (Clause 9.2) +- Management Review Agenda and Minutes (Clause 9.3) +- Corrective Action Record (Clause 10.2) + +### EU AI Act Alignment +Detailed mapping of all ISO 42001 clauses and Annex A controls to the EU AI Act (Regulation (EU) 2024/1689): +- Prohibited AI practices (Article 5) — identification via AISIA +- High-risk AI system categories (Annex III) +- Provider obligations (Articles 8–15) mapped to ISO 42001 controls +- Deployer obligations (Article 26) and FRIA requirement (Article 27) mapped to AISIA +- GPAI model obligations (Articles 51–56) +- Phased application timeline (February 2025 through August 2027) +- GDPR and EU AI Act interaction ### Certification Readiness -Produces Stage 1 (documentation review) and Stage 2 (implementation verification) audit checklists with RAG status, evidence requirements per clause, and common auditor focus areas. +Produces Stage 1 (documentation review) and Stage 2 (implementation verification) audit checklists with evidence requirements per clause and common auditor focus areas. ### Framework Integration -Maps ISO 42001 to: -- **ISO 27001:2022** — integrated ISMS + AIMS -- **NIST AI RMF** — Map/Measure/Manage/Govern to 42001 clauses -- **EU AI Act** — AISIA to Fundamental Rights Impact Assessment (FRIA); high-risk AI system controls -- **ISO 31000** — AI risk assessment methodology alignment +- **ISO 27001:2022** — integrated ISMS + AIMS mapping +- **NIST AI RMF (2023)** — Map/Measure/Manage/Govern to 42001 clauses +- **EU AI Act** — comprehensive article-by-article mapping +- **ISO 31000:2018** — AI risk assessment methodology alignment +- **ISO/IEC 23894** — AI risk management alignment +- **IEEE Ethically Aligned Design** — Annex C responsible AI attributes alignment --- @@ -58,12 +84,14 @@ Maps ISO 42001 to: ``` ISO-42001.skill -└── skills/iso42001/ - ├── SKILL.md # Core skill — loaded on every trigger +└── iso42001/ + ├── SKILL.md # Core skill — loaded on every trigger └── references/ - ├── iso42001-controls-annex-a.md # All 38 controls with descriptions and applicability by role - ├── iso42001-clauses-requirements.md # Mandatory clauses 4–10 in full detail - └── iso42001-ai-risk-assessment.md # AI risk assessment + AISIA methodology and templates + ├── iso42001-controls-annex-a.md # All 38 Annex A controls with descriptions and applicability + ├── iso42001-clauses-requirements.md # Mandatory clauses 4–10 in full detail + ├── iso42001-ai-risk-assessment.md # AI risk assessment and AISIA methodology + ├── iso42001-templates.md # Complete AIMS document templates + └── iso42001-eu-ai-act-mapping.md # EU AI Act mapping and FRIA-to-AISIA crosswalk ``` --- @@ -96,36 +124,43 @@ After installing the skill, try these: **AISIA:** > "Help me complete an AI System Impact Assessment for our automated employee performance review system. It uses ML to recommend ratings. It affects 2,000 employees." +**Templates:** +> "Give me the complete Statement of Applicability template for ISO 42001. We're an AI provider with 3 AI systems in scope." + **AI risk assessment:** -> "What are the key AI risks we should assess for a large language model we're deploying for internal legal document drafting?" +> "What are the key AI risks for a large language model we're deploying for internal legal document drafting? Run the risk assessment." **Policy generation:** -> "Draft an AI Acceptable Use Policy for a mid-size financial services firm. We use third-party AI tools including Microsoft Copilot and a custom credit risk model." +> "Draft an AI Acceptable Use Policy for a mid-size financial services firm. We use Microsoft Copilot and a custom credit risk model." -**SoA:** -> "Generate a Statement of Applicability for all 38 ISO 42001 Annex A controls. We're an AI provider. Mark A.10 decommission controls as not yet applicable — our AI systems are all in early deployment." +**EU AI Act alignment:** +> "We're building a hiring tool that uses AI to screen CVs. How does our ISO 42001 AISIA help us meet EU AI Act high-risk requirements? What's the FRIA crosswalk?" **Certification readiness:** > "We're targeting ISO 42001 Stage 2 audit in 3 months. What evidence do we need and what are auditors most likely to test?" -**EU AI Act alignment:** -> "We're building a hiring tool that uses AI to screen CVs. How does our ISO 42001 AISIA help us meet EU AI Act high-risk requirements?" +**Annex C objectives:** +> "Set up our ISO 42001 objectives register. We want to address all seven responsible AI attributes from Annex C with measurable targets." --- ## Standard Coverage | Area | Coverage | -|------|---------| +|------|----------| | Standard | ISO/IEC 42001:2023 (December 18, 2023) | -| Mandatory clauses | 4 through 10 (full coverage) | +| Mandatory clauses | 4 through 10 (full — detailed per clause) | | Annex A controls | All 38 controls across 9 domains (A.2–A.10) | +| Annex B | Implementation guidance highlights per domain | +| Annex C | All 7 responsible AI attributes — objectives and definitions | | Roles | AI provider, AI user, or both | | AI risk categories | Model, data, operational, supply chain, regulatory/reputational | | AISIA | Full process — documentation, population identification, impact dimensions, classification, controls | | Impact levels | Low, Medium, High (with control requirements per level) | -| Integration | ISO 27001, NIST AI RMF, EU AI Act, ISO 31000 | +| Integration | ISO 27001, NIST AI RMF, EU AI Act, ISO 31000, ISO/IEC 23894 | | Certification pathway | Stage 1 + Stage 2 checklists; surveillance audit guidance | +| Document templates | 12 complete templates covering all mandatory documents | +| EU AI Act | Full mapping: Articles 5, 8–15, 26–27, 51–56; prohibited AI; FRIA crosswalk; GPAI | --- @@ -133,15 +168,16 @@ After installing the skill, try these: The skill activates automatically when your conversation includes: -`ISO 42001`, `ISO/IEC 42001`, `AI Management System`, `AIMS`, `AI governance standard`, `AISIA`, `AI System Impact Assessment`, `Annex A controls for AI`, `AI risk assessment ISO`, `responsible AI framework`, `AI certification`, `AI policy ISO`, `Statement of Applicability AI`, `AI lifecycle controls`, `AI supplier management ISO`, `EU AI Act management system`, `NIST AI RMF ISO mapping`, `AI incident management ISO`, `AI transparency standard`, `AI bias controls` +`ISO 42001`, `ISO/IEC 42001`, `AI Management System`, `AIMS`, `AI governance standard`, `AISIA`, `AI System Impact Assessment`, `Annex A controls for AI`, `AI risk assessment ISO`, `responsible AI framework`, `AI certification`, `AI policy ISO`, `Statement of Applicability AI`, `AI lifecycle controls`, `AI supplier management ISO`, `EU AI Act management system`, `NIST AI RMF ISO mapping`, `AI incident management ISO`, `AI transparency standard`, `AI bias controls`, `FRIA ISO 42001`, `Fundamental Rights Impact Assessment`, `EU AI Act Article 27`, `Annex C responsible AI`, `GPAI model compliance`, `high-risk AI system ISO` --- ## About -**Author:** Hemant Naik -**Repository:** [Sushegaad/Claude-Skills-Governance-Risk-and-Compliance](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance) -**License:** MIT -**Standard version covered:** ISO/IEC 42001:2023 +**Author:** Hemant Naik +**Repository:** [Sushegaad/Claude-Skills-Governance-Risk-and-Compliance](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance) +**License:** MIT +**Standard version covered:** ISO/IEC 42001:2023 +**Skill version:** 1.0.0 -> This skill provides compliance guidance based on publicly available ISO 42001 documentation and expert interpretation. It does not substitute for professional legal, audit, or consulting advice. Organisations pursuing ISO 42001 certification should engage an accredited certification body. +> This skill provides compliance guidance based on publicly available ISO 42001 and EU AI Act documentation and expert interpretation. It does not substitute for professional legal, audit, or consulting advice. Organisations pursuing ISO 42001 certification should engage an accredited certification body. diff --git a/ISO 42001 - Claude Skill/ISO-42001.skill b/ISO 42001 - Claude Skill/ISO-42001.skill index cdc527b..6bfdd09 100644 Binary files a/ISO 42001 - Claude Skill/ISO-42001.skill and b/ISO 42001 - Claude Skill/ISO-42001.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/PCI Compliance - Claude Skill/PCI-Compliance-README.md b/PCI Compliance - Claude Skill/PCI-Compliance-README.md deleted file mode 100644 index ef34db2..0000000 --- a/PCI Compliance - Claude Skill/PCI-Compliance-README.md +++ /dev/null @@ -1,132 +0,0 @@ -# PCI DSS Compliance Skill - -> A Claude skill for security, compliance, and engineering teams to navigate PCI DSS v4.0.1 — from CDE scoping and SAQ selection through gap assessments, QSA audit preparation, and remediation planning. - ---- - -## 1. What Does the Skill Do? - -The PCI DSS skill turns Claude into an expert PCI DSS compliance advisor and QSA-trained consultant. It provides structured, actionable guidance across the full PCI DSS compliance lifecycle — from defining cardholder data environment (CDE) scope and selecting the right SAQ type, through gap assessments against all 12 requirements, remediation planning, and QSA audit preparation. - -The skill covers **PCI DSS v4.0.1** (June 2024 — current version), including all new requirements that became mandatory on March 31, 2025 — expanded MFA, payment page script integrity controls, phishing protection, automated log review, and targeted risk analysis. It also supports teams transitioning from the retired **PCI DSS v3.2.1**. - -Outputs are tailored to the task: CDE scoping narratives, structured gap assessment tables with evidence requirements, SAQ selection decisions with rationale, control-level implementation guidance with QSA evidence tips, and full policy documents with PCI DSS control citations. - ---- - -## 2. Intended Audiences - -- **CISOs and Security Managers** overseeing PCI DSS compliance programmes for merchants or service providers -- **Compliance Analysts and GRC Teams** performing gap assessments, maintaining SAQ documentation, or preparing for annual QSA audits -- **Software Developers and Engineers** building payment systems, e-commerce applications, or integrations that touch cardholder data -- **Architects** designing or reviewing systems that interact with the CDE — network segmentation, tokenisation, P2PE, cloud environments -- **Small and Mid-Size Merchants** (Level 2–4) completing their annual SAQ and wanting expert guidance on what controls are needed and why -- **Service Providers** managing their PCI DSS Level 1 or Level 2 obligations and TPSP due diligence - ---- - -## 3. Common Use Cases - -| Use Case | Example Prompt | -|----------|---------------| -| **CDE scoping** | "Help me scope our CDE. We have a cloud-based e-commerce platform that uses Stripe for payments. What's in scope?" | -| **SAQ selection** | "We're a Level 3 merchant accepting e-commerce payments only. We redirect customers to PayPal's hosted checkout. Which SAQ do we need?" | -| **Gap assessment** | "Run a PCI DSS v4.0.1 gap assessment. We're an SAQ D merchant. Here's our current environment..." | -| **v4.0 new requirements** | "What are the new requirements in PCI DSS v4.0 that became mandatory in March 2025?" | -| **MFA guidance** | "What does Req 8.4.2 mean for our internal staff accessing CDE systems?" | -| **Payment page scripts** | "How do we comply with Req 6.4.3 and 11.6.1 for our e-commerce payment page?" | -| **Policy generation** | "Write an Incident Response Plan aligned to PCI DSS Req 12.10." | -| **Remediation roadmap** | "We have 12 non-compliant controls from our last assessment. Help me build a remediation roadmap." | -| **TPSP management** | "What does PCI DSS require for managing third-party service providers?" | -| **Key management** | "How do we implement PCI DSS Req 3.7 for encryption key management?" | - ---- - -## 4. How to Use the Skill - -Once the skill is installed in Claude, it activates automatically whenever you ask about PCI DSS, payment card security, CDE, SAQs, ROC, QSA assessments, cardholder data, or related topics. You do not need to reference the skill by name. - -### Tips for best results - -**Specify your merchant or service provider level** — this determines your validation requirements (SAQ vs ROC) and tailors the guidance. For example: - -> "We're a Level 2 merchant with 2 million transactions per year. We use a hosted payment page (redirect). What SAQ applies and what do we need to demonstrate?" - -**Describe your payment environment** — channels (card-present, e-commerce, MOTO), third-party processors used, whether you store any cardholder data, and which systems are in scope. - -**Reference specific requirements** — for targeted guidance, reference the requirement number (e.g., `Req 8.4.2`, `Req 6.4.3`) to get more focused and actionable responses. - -### Example interaction - -``` -You: We're a Level 3 e-commerce merchant. We use a JavaScript payment widget from - Stripe embedded in our checkout page. Do we qualify for SAQ A? - -Claude: No — because you control the checkout page that hosts the Stripe widget and - your JavaScript can affect how the widget behaves, you do not meet SAQ A - criteria. You are likely SAQ A-EP. Key requirements include: - - Req 6.4.3: Inventory all scripts on your payment page; implement - Content Security Policy (CSP) or Sub-Resource Integrity (SRI) - - Req 11.6.1: Deploy tamper detection for HTTP headers and payment page content - - Req 11.3: Quarterly ASV scans - Here is the full SAQ A-EP control scope and what you need to implement... -``` - ---- - -## 5. Skill Implementation Details - -### Architecture - -``` -pci-compliance/ -├── SKILL.md # Core skill logic and workflows -└── references/ - ├── pci-dss-requirements.md # All 12 requirements with sub-controls and evidence - ├── pci-dss-saq-guide.md # SAQ selection guide, all SAQ types, ROC/AOC/ASV - └── pci-dss-v4-changes.md # v3.2.1 → v4.0/v4.0.1 migration guide and change log -``` - -### What's in SKILL.md - -- **Persona**: Claude adopts the role of a PCI DSS compliance advisor and QSA-trained consultant -- **Output format matrix**: Maps each task type to a specific output format -- **CDE core concepts**: PAN, SAD, account data types, scope reduction strategies (tokenisation, P2PE, segmentation) -- **Merchant and service provider levels**: Validation requirements per level -- **Defined vs Customised Approach**: When each applies and what's required -- **SAQ quick reference**: All 8 SAQ types with ~control counts -- **5 core workflows**: CDE Scoping, Gap Assessment, SAQ Selection, Control Implementation, Policy Generation -- **v4.0 changes table**: Key differences from v3.2.1 -- **Compensating controls**: How they work and when they apply - -### What's in the reference files - -| File | Contents | -|------|----------| -| `pci-dss-requirements.md` | All 12 requirements with sub-controls, QSA evidence requirements, and common gaps | -| `pci-dss-saq-guide.md` | SAQ selection decision tree, all 8 SAQ types with eligibility criteria, ROC/AOC/ASV/QSA/ISA reference | -| `pci-dss-v4-changes.md` | Version timeline, all new v4.0 requirements (future-dated → mandatory), key conceptual changes, migration checklist | - -### Inputs used to build the skill - -- **PCI DSS v4.0.1** (PCI SSC, June 2024) — all 12 requirements and sub-requirements -- **PCI DSS v4.0** (PCI SSC, March 2022) — including future-dated requirements and Customised Approach -- **PCI DSS Summary of Changes v3.2.1 to v4.0** (PCI SSC) — change log and migration reference -- **PCI DSS SAQ documents v4.0** — all 8 SAQ types with eligibility criteria -- **PCI SSC ROC Template v4.0.1** — assessment structure reference -- **PCI SSC Targeted Risk Analysis guidance** — TRA methodology and requirements - -### Skill trigger phrases - -`PCI DSS` · `PCI compliance` · `payment card` · `cardholder data` · `CDE` · `SAQ` · `ROC` · `AOC` · `QSA` · `ASV scan` · `PAN storage` · `SAD` · `tokenisation` · `P2PE` · `Requirement 1` through `Requirement 12` · `v4.0` · `merchant level` · `service provider` · `network segmentation` · `payment page` · `web skimming` · `Magecart` · `TPSP` · `key management` · `PCI scope` - ---- - -## 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:** March 2026 -**Skill version:** 0.3.0 -**Standard coverage:** PCI DSS v4.0.1 (June 2024) and PCI DSS v4.0 (March 2022) diff --git a/PCI Compliance - Claude Skill/PCI-Compliance.skill b/PCI Compliance - Claude Skill/PCI-Compliance.skill deleted file mode 100644 index 245c4ee..0000000 Binary files a/PCI Compliance - Claude Skill/PCI-Compliance.skill and /dev/null differ diff --git a/PCI DSS - Claude Skill/PCI-DSS-README.md b/PCI DSS - Claude Skill/PCI-DSS-README.md new file mode 100644 index 0000000..99e7acb --- /dev/null +++ b/PCI DSS - Claude Skill/PCI-DSS-README.md @@ -0,0 +1,194 @@ +# PCI DSS Compliance Skill — All Versions + +> A Claude skill for security, compliance, and engineering teams to navigate all versions of PCI DSS — from v1.0 (2004) through v4.0.1 (current, June 2024). Covers CDE scoping, SAQ selection, gap assessments, version migration planning, QSA audit preparation, and remediation — for any version of the standard. + +--- + +## 1. What Does the Skill Do? + +The PCI DSS skill turns Claude into an expert PCI DSS compliance advisor and QSA-trained consultant with knowledge spanning every published version of the standard, from the original v1.0 (December 2004) through the current **PCI DSS v4.0.1** (June 2024). + +The skill provides structured, actionable guidance across the full PCI DSS compliance lifecycle: + +- **CDE scoping** — defining what is in scope, scope reduction strategies (tokenisation, P2PE, segmentation) +- **SAQ selection** — decision logic for all 9 SAQ types, eligibility criteria, control counts +- **Gap assessments** — against v4.0.1 or any specified legacy version +- **Version migration** — v3.2.1 → v4.0.1 gap analysis, migration checklists, mandatory-from dates for all future-dated requirements +- **Control implementation** — per-requirement implementation guidance with QSA evidence tips +- **Policy generation** — full policy documents with PCI DSS citations and version applicability +- **Remediation roadmaps** — prioritised action tables with owner and timeline fields +- **Compensating controls and Customised Approach guidance** + +**Defaults to v4.0.1** (current) unless the user specifies a version. Acknowledged historical versions (v1.x through v3.2.1) for legacy documentation, migration planning, and gap comparison. + +--- + +## 2. Version Coverage + +| Version | Year | Status | Notes | +|---------|------|--------|-------| +| v1.0 | 2004 | Retired | Historical reference; first unified standard | +| v1.1 | 2006 | Retired | PCI SSC formation; SAQ programme introduced | +| v1.2 | 2008 | Retired | WEP prohibited; wireless strengthened | +| v1.2.1 | 2009 | Retired | Minor corrections only | +| v2.0 | 2010 | Retired | Virtualisation guidance | +| v3.0 | 2013 | Retired | BAU security focus; SAQ B-IP and P2PE added | +| v3.1 | 2015 | Retired | SSL/TLS 1.0 deprecated | +| v3.2 | 2016 | Retired | MFA expansion; service provider requirements | +| v3.2.1 | 2018 | **Retired March 31, 2024** | Last v3 release; migration baseline | +| v4.0 | 2022 | Superseded | Customised Approach; future-dated requirements | +| **v4.0.1** | **2024** | **CURRENT** | All live assessments must use this version | + +--- + +## 3. Intended Audiences + +- **CISOs and Security Managers** overseeing PCI DSS compliance programmes +- **Compliance Analysts and GRC Teams** performing gap assessments, SAQ documentation, or QSA audit preparation +- **Software Developers and Engineers** building payment systems or integrations touching cardholder data +- **Architects** designing or reviewing CDE environments, network segmentation, tokenisation, P2PE, or cloud deployments +- **Merchants (all levels)** and **Service Providers** — including those migrating from v3.2.1 to v4.0.1 +- **Small and Mid-Size Merchants** (Level 2–4) completing their annual SAQ + +--- + +## 4. Common Use Cases + +| Use Case | Example Prompt | +|----------|---------------| +| **Version guidance** | "What PCI DSS version should we be using for our next assessment?" | +| **Migration planning** | "We completed our last assessment against v3.2.1. What do we need to do to move to v4.0.1?" | +| **v4.0 new requirements** | "What are the new requirements in PCI DSS v4.0 that became mandatory in March 2025?" | +| **CDE scoping** | "Help me scope our CDE. We have a cloud-based e-commerce platform using Stripe. What's in scope?" | +| **SAQ selection** | "We redirect customers to PayPal's hosted checkout. Which SAQ do we need?" | +| **Gap assessment (v4.0.1)** | "Run a PCI DSS v4.0.1 gap assessment against our SAQ D merchant environment." | +| **Legacy gap (v3.2.1)** | "What would our v3.2.1 assessment cover? We're comparing against v4.0.1 gaps." | +| **MFA guidance** | "What does Req 8.4.2 mean for our internal staff accessing CDE systems?" | +| **Payment page scripts** | "How do we comply with Req 6.4.3 and 11.6.1 for our e-commerce payment page?" | +| **Policy generation** | "Write an Incident Response Plan aligned to PCI DSS v4.0.1 Req 12.10." | +| **Remediation roadmap** | "We have 12 non-compliant controls. Help me build a remediation roadmap." | +| **Version comparison** | "Show me what changed between PCI DSS v3.0 and v3.2.1." | + +--- + +## 5. How to Use the Skill + +Once installed, the skill activates automatically whenever you ask about PCI DSS, any PCI DSS version, payment card security, CDE scoping, SAQ types, cardholder data, or related topics. You do not need to reference the skill by name. + +### Tips for best results + +**Specify your PCI DSS version** — the skill defaults to v4.0.1 (current) but can provide guidance for any version if specified. + +**Specify your merchant or service provider level** — this determines your validation requirements (SAQ vs ROC). + +**Describe your payment environment** — channels (card-present, e-commerce, MOTO), processors used, whether cardholder data is stored, which systems are in CDE scope. + +### Example — Migration planning + +``` +You: We completed our last PCI DSS assessment in January 2024 under v3.2.1. + What changes do we face for our next assessment under v4.0.1? + +Claude: Your next assessment must use PCI DSS v4.0.1. Here are the main gaps + from your v3.2.1 baseline: + + CRITICAL — Mandatory from March 31, 2025: + - Req 8.4.2: MFA is now required for ALL access into the CDE, not just + admin/remote. Any internal user accessing a CDE system must now use MFA. + - Req 6.4.3: You must inventory all scripts on your payment pages, + document authorisation for each, and implement integrity controls (CSP/SRI). + - Req 5.4.1: An automated anti-phishing technical solution is required. + - Req 10.4.1.1: Manual daily log review is no longer sufficient — you need + an automated log review mechanism (SIEM or equivalent). + - Req 8.3.6: Minimum password length increases from 7 to 12 characters. + + [Full migration checklist continues...] +``` + +### Example — Version history question + +``` +You: What changed between PCI DSS v3.1 and v3.2? + +Claude: PCI DSS v3.2 (April 2016) made these changes from v3.1: + 1. MFA expanded: v3.2 added MFA for non-console admin access into the CDE + for all personnel (was previously limited to remote access only). + Deadline for existing implementations: February 1, 2018. + 2. Service provider-specific requirements added: + - Req 10.8 (SP): Detect and report failures of critical security controls + - Req 10.8.1 (SP): Respond to critical security control failures within 1 business day + - Req 12.11 (SP): Quarterly reviews of personnel compliance with security procedures + - Req 12.4.1 (SP): Executive oversight responsibility for CHD protection + 3. Appendix A3 (DESV) incorporated for designated entities + 4. Req 6.4.6: After significant changes, all relevant PCI DSS requirements + must be re-implemented on changed systems + Note: v3.1 and v3.2 are both retired. All current assessments use v4.0.1. +``` + +--- + +## 6. Skill Architecture + +``` +pci-dss/ +├── SKILL.md # Core skill logic, all versions, all workflows +└── references/ + ├── pci-dss-requirements.md # All 12 v4.0.1 requirements with sub-controls and evidence + ├── pci-dss-saq-guide.md # SAQ selection guide, all SAQ types, ROC/AOC/ASV + ├── pci-dss-v4-changes.md # v3.2.1 → v4.0/v4.0.1 complete change log + migration checklist + ├── pci-dss-version-history.md # All versions v1.0–v4.0.1 — changes, dates, thresholds + └── pci-dss-v3-controls.md # v3.2.1 complete control structure with v4.0.1 mapping +``` + +### What's covered in each file + +| File | Contents | +|------|---------| +| `SKILL.md` | Claude persona, version guidance table, 7 core workflows (including migration and legacy), output format matrix, quick SAQ reference | +| `references/pci-dss-requirements.md` | All 12 v4.0.1 requirements with all sub-controls, evidence requirements, and common gaps | +| `references/pci-dss-saq-guide.md` | Full SAQ decision tree, per-SAQ eligibility criteria and control counts, ROC/AOC/ASV guidance | +| `references/pci-dss-v4-changes.md` | Complete change log v3.2.1 → v4.0/v4.0.1; all new mandatory requirements with effective dates; migration checklist | +| `references/pci-dss-version-history.md` | v1.0 through v4.0.1 — per-version changes, key milestone dates, authentication/cryptography thresholds by version, glossary | +| `references/pci-dss-v3-controls.md` | Complete v3.2.1 requirement structure with v4.0.1 cross-reference mapping for migration and legacy gap analysis | + +--- + +## 7. Official Sources + +- PCI Security Standards Council Document Library: https://www.pcisecuritystandards.org/document_library/ +- PCI DSS v4.0.1 (June 2024): Available from PCI SSC Document Library +- PCI DSS v3.2.1 (May 2018): Available from PCI SSC Document Library (archived) +- PCI SSC SAQ Documents: https://www.pcisecuritystandards.org/document_library/?category=saqs + + +### What's in the reference files + +| File | Contents | +|------|----------| +| `pci-dss-requirements.md` | All 12 requirements with sub-controls, QSA evidence requirements, and common gaps | +| `pci-dss-saq-guide.md` | SAQ selection decision tree, all 8 SAQ types with eligibility criteria, ROC/AOC/ASV/QSA/ISA reference | +| `pci-dss-v4-changes.md` | Version timeline, all new v4.0 requirements (future-dated → mandatory), key conceptual changes, migration checklist | + +### Inputs used to build the skill + +- **PCI DSS v4.0.1** (PCI SSC, June 2024) — all 12 requirements and sub-requirements +- **PCI DSS v4.0** (PCI SSC, March 2022) — including future-dated requirements and Customised Approach +- **PCI DSS Summary of Changes v3.2.1 to v4.0** (PCI SSC) — change log and migration reference +- **PCI DSS SAQ documents v4.0** — all 8 SAQ types with eligibility criteria +- **PCI SSC ROC Template v4.0.1** — assessment structure reference +- **PCI SSC Targeted Risk Analysis guidance** — TRA methodology and requirements + +### Skill trigger phrases + +`PCI DSS` · `PCI compliance` · `payment card` · `cardholder data` · `CDE` · `SAQ` · `ROC` · `AOC` · `QSA` · `ASV scan` · `PAN storage` · `SAD` · `tokenisation` · `P2PE` · `Requirement 1` through `Requirement 12` · `v4.0` · `merchant level` · `service provider` · `network segmentation` · `payment page` · `web skimming` · `Magecart` · `TPSP` · `key management` · `PCI scope` + +--- + +## 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:** March 2026 +**Skill version:** 0.3.0 +**Standard coverage:** PCI DSS v4.0.1 (June 2024) and PCI DSS v4.0 (March 2022) diff --git a/PCI DSS - Claude Skill/PCI-DSS.skill b/PCI DSS - Claude Skill/PCI-DSS.skill new file mode 100644 index 0000000..99cbeba Binary files /dev/null and b/PCI DSS - Claude Skill/PCI-DSS.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/SOC - Claude Skill/SOC-README.md b/SOC - Claude Skill/SOC-README.md new file mode 100644 index 0000000..0f2376e --- /dev/null +++ b/SOC - Claude Skill/SOC-README.md @@ -0,0 +1,121 @@ +# SOC — Claude Skill + +## Overview + +This Claude skill provides expert guidance on the full AICPA **System and Organization Controls (SOC)** +reporting suite, covering: + +- **SOC 1** (SSAE 18 AT-C Section 320) — Controls relevant to User Entities' Internal Control over Financial Reporting (ICFR) +- **SOC 3** — General use Trust Services Criteria attestation reports +- **SOC for Cybersecurity** — Entity-level cybersecurity risk management program examinations +- **SOC for Supply Chain** — Controls over production and distribution systems + +> **Note:** SOC 2 (Trust Services Criteria — Security, Availability, Confidentiality, Processing Integrity, Privacy) is covered by a separate skill (`soc2.skill`). + +--- + +## What This Skill Covers + +### SOC 1 (SSAE 18) +- Report scoping: identifying services relevant to user entity ICFR +- System description requirements per AT-C Section 320 +- Drafting control objectives +- Type 1 vs Type 2 selection +- Carve-out vs inclusive method for subservice organizations +- Complementary User Entity Controls (CUECs) +- Common audit findings and deficiencies +- User auditor guidance for reading and relying on SOC 1 reports + +### SOC 3 +- Structure of the general use report +- Relationship to SOC 2 (issued from the same examination) +- AICPA seal requirements and usage +- When SOC 3 is and is not sufficient +- Vendor procurement guidance for evaluating received SOC 3 reports + +### SOC for Cybersecurity +- DC-4 description criteria (nine groups) — full detail +- Mapping DC-4 to CC1–CC9 Trust Services Criteria +- Readiness gap assessment template +- Management description writing guidance +- Comparison with SOC 2 and other cybersecurity frameworks + +### SOC for Supply Chain +- DC-3 description criteria (eight areas) — full detail +- Applicable Trust Services Criteria (Security, Availability, Processing Integrity) +- Scoping for manufacturing, logistics, and agriculture organizations +- Complementary User Layer Entity Controls (CULECs) +- Sub-supplier identification and treatment +- OT/ICS cybersecurity considerations + +--- + +## Authoritative Sources + +All content in this skill is based on official AICPA publications: + +| Document | Publisher | Relevance | +|---|---|---| +| SSAE 18 AT-C Section 105 | AICPA | Concepts common to all attestation engagements | +| SSAE 18 AT-C Section 205 | AICPA | Examination engagements | +| SSAE 18 AT-C Section 320 | AICPA | SOC 1 — service organization controls relevant to ICFR | +| AICPA Trust Services Criteria (2017, revised 2022) | AICPA | SOC 2, SOC 3, SOC for Cybersecurity measurement criteria | +| AICPA DC-3 (2020) | AICPA | SOC for Supply Chain description criteria | +| AICPA DC-4 (2017) | AICPA | SOC for Cybersecurity description criteria | +| AICPA SOC 1 Guide | AICPA | Performing and reporting on SOC 1 examinations | +| AICPA SOC 2 Guide | AICPA | Performing and reporting on SOC 2 examinations | +| AICPA SOC for Cybersecurity Guide | AICPA | Reporting on cybersecurity risk management programs | +| AICPA SOC for Supply Chain Guide | AICPA | Reporting on production and distribution system controls | + +--- + +## Installation + +### Via Claude Code Plugin Marketplace + +1. Open Claude Code. +2. Navigate to **Settings > Skills**. +3. Search for `soc`. +4. Click **Install**. + +### Manual Installation + +1. Download `soc.skill`. +2. In Claude Code, navigate to **Settings > Skills > Install from file**. +3. Select the downloaded `soc.skill` file. + +--- + +## Trigger Phrases + +This skill is activated by questions or statements involving: + +- "SOC 1", "SSAE 18", "SAS 70", "SSAE 16" +- "Internal control over financial reporting" / "ICFR" +- "Service organization report", "service auditor report" +- "Complementary user entity controls", "CUECs" +- "Carve-out method", "inclusive method" +- "Subservice organization" +- "SOC 3", "general use report", "AICPA seal" +- "SOC for Cybersecurity", "cybersecurity risk management program", "DC-4" +- "SOC for Supply Chain", "production and distribution system", "DC-3" +- "Which SOC report do we need?" +- "How are SOC reports different?" + +--- + +## Version History + +| Version | Date | Notes | +|---|---|---| +| 1.0.0 | 2026-04-16 | Initial release — SOC 1, SOC 3, SOC for Cybersecurity, SOC for Supply Chain | + +--- + +## License + +MIT License — see `LICENSE` in the repository root. + +## Repository + +[https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance](https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance) diff --git a/SOC - Claude Skill/soc.skill b/SOC - Claude Skill/soc.skill new file mode 100644 index 0000000..f21d2c6 Binary files /dev/null and b/SOC - Claude Skill/soc.skill differ diff --git a/UK NIS - Claude Skill/UK-NIS-README.md b/UK NIS - Claude Skill/UK-NIS-README.md new file mode 100644 index 0000000..a74dd59 --- /dev/null +++ b/UK NIS - Claude Skill/UK-NIS-README.md @@ -0,0 +1,104 @@ +# UK NIS (Network and Information Systems Regulations 2018) — Claude Skill + +## Overview + +This Claude skill provides expert compliance guidance for the **UK Network and Information Systems (NIS) Regulations 2018** (Statutory Instrument 2018/506). The skill covers the full scope of the Regulations including Operators of Essential Services (OES), Digital Service Providers (DSPs), the NCSC Cyber Assessment Framework (CAF), incident reporting obligations, Competent Authority requirements, and enforcement provisions. + +The NIS Regulations 2018 came into force on **10 May 2018** as the UK implementation of EU Directive 2016/1148 (EU NIS Directive) and have been retained in UK domestic law following Brexit. + +--- + +## What This Skill Covers + +- **Scope determination** — Is your organisation an OES, DSP, or both? +- **CAF assessments** — All 14 CAF outcomes (Objectives A–D) with IGP and IPP +- **Gap analysis** — Structured gap assessment against the CAF +- **Incident reporting** — Regulation 11 (OES) and Regulation 13 (DSP) notification requirements +- **Competent Authorities** — Sector-specific CA mapping (Ofgem, CAA, ORR, DfT, DHSC, DWI, Ofcom, ICO) +- **Policy generation** — NIS compliance policies, risk registers, asset registers, incident response plans, supplier assessments, BCP +- **Enforcement** — Enforcement notices, penalty notices (up to £17 million), appeals +- **DSP requirements** — Security measures and ICO notification for cloud, marketplace, and search engine operators + +--- + +## Skill Contents + +``` +uk-nis/ + SKILL.md — Main skill instruction file + references/ + caf-objectives.md — Complete CAF v3.2: all 14 outcomes with IGP and IPP + incident-reporting.md — OES and DSP notification templates and thresholds + oes-sectors.md — OES sector breakdown, CA mapping, designation criteria + templates.md — Policy, register, IRP, BCP, and assessment templates +``` + +--- + +## Installation + +### Via Claude Code (plugin install) + +```bash +claude plugin install ./plugins/uk-nis +``` + +### Manual (.skill file) + +1. Download `uk-nis.skill` from this repository +2. Open Claude desktop +3. Go to Settings > Skills > Install from file +4. Select `uk-nis.skill` + +--- + +## Usage Examples + +**Scope determination:** +> "We are a water company operating treatment works and distribution networks. Are we in scope for UK NIS?" + +**Gap assessment:** +> "Run a CAF gap assessment for our SCADA control systems." + +**Incident reporting:** +> "We've detected ransomware on our electricity distribution control systems. What are our NIS reporting obligations?" + +**Policy generation:** +> "Generate a NIS Compliance Policy for our NHS Trust." + +**Competent Authority queries:** +> "Who is the Competent Authority for DNS service providers under UK NIS?" + +**CAF guidance:** +> "Explain CAF outcome B2 — Identity and Access Control, including all Indicators of Good Practice." + +--- + +## Legal Basis + +- **Statutory Instrument 2018/506** — The Network and Information Systems (NIS) Regulations 2018 +- **EU Directive 2016/1148** (original basis, now superseded by UK domestic law post-Brexit) +- **NCSC CAF v3.2** — Cyber Assessment Framework (primary technical standard for NIS compliance in the UK) + +--- + +## Key Authorities + +| Authority | Role | +|-----------|------| +| DSIT | Lead government department for NIS policy | +| NCSC | National technical authority; incident response support | +| Ofgem | CA for electricity and gas | +| CAA | CA for air transport | +| ORR | CA for rail transport | +| DfT/MCA | CA for road and maritime transport | +| DHSC/NHS England | CA for health | +| DWI | CA for drinking water | +| Ofcom | CA for digital infrastructure (IXP, DNS, TLD) | +| ICO | CA for all DSPs | + +--- + +## Disclaimer + +This skill provides informational guidance only and does not constitute legal advice. For formal NIS compliance conclusions, consult a qualified regulatory or legal specialist. The NIS Regulations should be read in their current form as maintained on legislation.gov.uk. diff --git a/UK NIS - Claude Skill/uk-nis.skill b/UK NIS - Claude Skill/uk-nis.skill new file mode 100644 index 0000000..46ef8c9 Binary files /dev/null and b/UK NIS - Claude Skill/uk-nis.skill differ diff --git a/UK NIS CSRB - Claude Skill/UK-NIS-CSRB-README.md b/UK NIS CSRB - Claude Skill/UK-NIS-CSRB-README.md new file mode 100644 index 0000000..65c4f8e --- /dev/null +++ b/UK NIS CSRB - Claude Skill/UK-NIS-CSRB-README.md @@ -0,0 +1,145 @@ +# UK Cyber Security and Resilience Bill (CSRB) — Claude Skill + +A Claude skill providing expert advisory capability for organisations preparing for +the UK Cyber Security and Resilience Bill (CSRB). Covers scope determination, enhanced +incident reporting, regulator powers, readiness assessment, and transition from the +NIS Regulations 2018. + +--- + +## Important Notice — Bill Status + +The Cyber Security and Resilience Bill was announced in the King's Speech on 17 July 2024. +This skill is based on published DSIT policy intent, the Bill as introduced, and publicly +available parliamentary materials. The Bill has not yet received Royal Assent. + +**Always verify content against enacted legislation and any statutory instruments or guidance +issued following Royal Assent.** Content in this skill reflects the state of the Bill as +of mid-2025 and will require review after enactment. + +Current Bill status: bills.parliament.uk (search: Cyber Security and Resilience Bill) + +--- + +## What This Skill Covers + +### 1. CSRB Overview and Context +- Policy rationale for the Bill +- What the CSRB changes compared with NIS Regulations 2018 +- Relationship with EU NIS2 Directive +- Key authorities: DSIT, NCSC, sector Competent Authorities + +### 2. Scope and Applicability +- Retained scope: Operators of Essential Services (OES) and Digital Service Providers (DSP) +- New scope: Managed Service Providers (MSPs) — policy rationale and definition +- New scope: Large data centres above the qualifying threshold +- Scope determination flowchart + +### 3. Enhanced Incident Reporting +- New reportable event categories (ransomware, near-misses, supply chain incidents) +- Compressed 24/72-hour notification timeline +- Reporting templates for OES, DSP, MSP, and data centres +- Cross-regulatory interaction (UK GDPR/ICO, FCA, NHS DSPT) + +### 4. Regulator Powers +- Proactive audit powers (directed assessments, scheduled audits) +- Enhanced information-gathering powers +- Enforcement process and financial penalties +- Cross-CA information sharing + +### 5. Readiness Assessment +- 5-step readiness framework +- Gap analysis against NIS Regs 2018 baseline +- Scoring methodology + +### 6. Transition from NIS Regulations 2018 +- Transition checklist for existing OES/DSP organisations +- New obligations for MSPs +- Governance and documentation gap analysis + +### 7. Policy and Documentation Generation +- CSRB Readiness Gap Assessment +- Compliance Roadmap +- Incident Response Plan (CSRB edition) +- MSP Security Policy +- Board Briefing Note +- MSP Customer Security Addendum + +### 8. Comparative Analysis +- CSRB vs NIS Regulations 2018 (key changes table) +- CSRB vs EU NIS2 Directive (alignment and divergence) + +--- + +## Installation + +### Option A — Install from the .skill file + +1. Open Claude (claude.ai or the Claude desktop app with skills/plugins enabled) +2. Go to Settings > Skills or Plugins +3. Select "Install from file" +4. Select `uk-nis-csrb.skill` from this folder + +### Option B — Install the plugin from source + +If you are using Claude with a local plugin directory: + +```bash +# Copy the plugin folder to your Claude plugins directory +cp -r plugins/uk-nis-csrb ~/.claude/plugins/ +``` + +Or add the path to your Claude plugin configuration. + +--- + +## Example Prompts + +Once installed, ask Claude: + +- "Does the CSRB apply to my organisation? We provide IT managed services to NHS trusts." +- "What is a managed service provider under the CSRB and how is one defined?" +- "Walk me through the CSRB incident reporting process — what do I need to report, by when?" +- "We currently comply with NIS Regs 2018 as an OES. What additional steps does the CSRB require of us?" +- "Generate a CSRB readiness gap assessment for our organisation." +- "What new regulatory powers does our Competent Authority have under the CSRB?" +- "We are an MSP — draft a CSRB security policy for our organisation." +- "Generate a board briefing note explaining our CSRB obligations." +- "How does the UK CSRB compare with the EU NIS2 Directive?" +- "What are the incident reporting timelines under the CSRB and how do they differ from current NIS Regs?" + +--- + +## Key Authorities and References + +| Body | Role | URL | +|------|------|-----| +| DSIT | Policy lead for CSRB | gov.uk/dsit | +| NCSC | Technical authority and CAF | ncsc.gov.uk | +| Parliament | Bill tracker | bills.parliament.uk | +| ICO | UK GDPR / DSP oversight | ico.org.uk | +| Ofcom | Telecoms sector CA | ofcom.org.uk | +| Ofgem | Energy sector CA | ofgem.gov.uk | +| DfT | Transport sector CA | gov.uk/dft | +| CQC | Health sector CA | cqc.org.uk | + +--- + +## Relationship to Other Skills + +This skill is designed to complement: + +- **UK NIS skill** — NIS Regulations 2018 compliance (the predecessor regime) +- **NCSC CAF** — The Cyber Assessment Framework underpins CSRB security requirements +- **ISO 27001 skill** — ISO 27001 certification provides strong evidence toward CSRB compliance +- **GDPR/UK GDPR skill** — Cross-regulatory interaction on personal data breach reporting + +--- + +## Version + +Version: 1.0.0 +Last Updated: 2025 +Maintainer: sjackson0109 + +This skill will be updated following Royal Assent to reflect enacted provisions. diff --git a/UK NIS CSRB - Claude Skill/uk-nis-csrb.skill b/UK NIS CSRB - Claude Skill/uk-nis-csrb.skill new file mode 100644 index 0000000..85fe592 Binary files /dev/null and b/UK NIS CSRB - Claude Skill/uk-nis-csrb.skill differ diff --git a/plugins/cmmc/.claude-plugin/plugin.json b/plugins/cmmc/.claude-plugin/plugin.json new file mode 100644 index 0000000..9fcebf1 --- /dev/null +++ b/plugins/cmmc/.claude-plugin/plugin.json @@ -0,0 +1,28 @@ +{ + "name": "cmmc", + "description": "CMMC 2.0 compliance advisor for defense contractors — Level 1/2/3 gap analysis, scoping, SPRS scoring, SSP documentation, POA&M development, C3PAO assessment preparation, and NIST 800-171/800-172 practice guidance for organizations protecting FCI and CUI under DoD contracts.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "cmmc", + "cmmc-2.0", + "dod", + "defense-contractor", + "dib", + "cui", + "fci", + "nist-800-171", + "nist-800-172", + "c3pao", + "sprs", + "dfars", + "cybersecurity", + "certification" + ] +} diff --git a/plugins/cmmc/skills/cmmc/SKILL.md b/plugins/cmmc/skills/cmmc/SKILL.md new file mode 100644 index 0000000..e45a41f --- /dev/null +++ b/plugins/cmmc/skills/cmmc/SKILL.md @@ -0,0 +1,357 @@ +--- +name: cmmc +description: > + Expert CMMC 2.0 compliance advisor for defense contractors and subcontractors. Use this skill + whenever a user asks about CMMC (Cybersecurity Maturity Model Certification) 2.0, DoD contractor + cybersecurity, CUI (Controlled Unclassified Information) protection, FCI (Federal Contract + Information), DFARS 252.204-7012, DFARS 252.204-7019, DFARS 252.204-7020, DFARS 252.204-7021, + NIST SP 800-171, NIST SP 800-172, CMMC Level 1, CMMC Level 2, CMMC Level 3, C3PAO assessments, + CMMC scoping, System Security Plan (SSP) for CMMC, POA&M for CMMC, Annual Affirmations, + SPRS (Supplier Performance Risk System) scores, DIBNet portal, or any question about achieving + or maintaining CMMC certification for defense industrial base (DIB) companies. Also trigger for + questions about flow-down requirements, subcontractor CMMC obligations, OSC (Organization Seeking + Certification) readiness, or responding to DoD RFPs that include CMMC requirements. +--- + +# CMMC 2.0 Compliance Skill + +You are an expert CMMC 2.0 implementation consultant and certified assessment advisor with +comprehensive knowledge of the Cybersecurity Maturity Model Certification 2.0 framework, +NIST SP 800-171 Rev 2 security requirements, DoD assessment methodology, scoping guidance, +and the full CMMC ecosystem including C3PAOs, CAICO, and the Accreditation Body (Cyber-AB). + +> **Disclaimer:** This guidance is for informational and educational purposes only and does not +> constitute legal or official DoD compliance advice. CMMC certification requires formal +> assessment by a Cyber-AB authorized C3PAO (for Level 2 and 3) or a DoD authorized Lead +> Assessor (for Level 3). Always refer to the official CMMC Program documentation at +> https://dodcio.defense.gov/CMMC/ and the Cyber-AB at https://cyberab.org/ for authoritative +> requirements. + +--- + +## How to Respond + +Clarify the user's CMMC level requirement (1, 2, or 3) and whether they handle CUI, FCI, or both +before diving into detailed guidance. + +Match output to the task: + +| Task | Output Format | +|------|--------------| +| Level determination | Decision tree: contract type, data type, flow-down requirements | +| Gap analysis | Table: Domain \| Practice ID \| Practice \| Current State \| Gap \| Priority | +| Scoping guidance | Asset category table with in-scope determination for each category | +| SSP documentation | Structured narrative per practice with implementation description | +| POA&M development | Table: Practice ID \| Gap Description \| Remediation Plan \| Milestone Date \| Status | +| SPRS score calculation | Scored table of 110 practices showing -1/-3/-5 deductions | +| Policy generation | Full policy document mapped to CMMC practices | +| Assessment preparation | Domain-by-domain readiness checklist with evidence requirements | +| General question | Clear prose with CMMC practice citations and NIST 800-171 references | + +--- + +## CMMC 2.0 — Framework Overview + +### What Is CMMC 2.0? + +The Cybersecurity Maturity Model Certification (CMMC) 2.0 is a DoD program that establishes +cybersecurity requirements for entities operating within the Defense Industrial Base (DIB). +The CMMC 2.0 Final Rule (32 CFR Part 170) was published on October 15, 2024, and became +effective on **December 16, 2024**. + +CMMC 2.0 requires DoD contractors and subcontractors to implement and, depending on the level, +have assessed against cybersecurity requirements derived from well-established NIST standards. +It replaces the self-attestation-only model with mandatory third-party certification for contracts +involving sensitive federal information. + +### Regulatory Basis + +| Regulation | Purpose | +|-----------|---------| +| 32 CFR Part 170 | CMMC Program rule — establishes the framework, levels, and assessment requirements | +| DFARS 252.204-7012 | Safeguarding covered defense information; incident reporting to DoD | +| DFARS 252.204-7019 | Notice of NIST SP 800-171 DoD Assessment requirements; SPRS submission | +| DFARS 252.204-7020 | NIST SP 800-171 DoD Assessment Requirements — allows DoD to conduct assessments | +| DFARS 252.204-7021 | CMMC Requirements — prime contractor CMMC clause (included when required) | +| NIST SP 800-171 Rev 2 | 110 security requirements protecting CUI — basis for CMMC Level 2 | +| NIST SP 800-172 | Enhanced security requirements — basis for the 24 additional Level 3 practices | +| NIST SP 800-171A | Assessment methods for NIST 800-171 — used by assessors | + +### Three Levels of CMMC 2.0 + +| Level | Name | Practices | Who Assesses | Data Type | Annual Affirmation | +|-------|------|-----------|-------------|-----------|-------------------| +| 1 | Foundational | 17 | Self-assessment (annual) | FCI only | Required by senior official | +| 2 | Advanced | 110 | C3PAO (triennial) or self-assessment (if not prioritized) | CUI | Required by senior official | +| 3 | Expert | 134 | Defense Contract Management Agency (DCMA) DIBCAC | CUI (highest priority programs) | Required by senior official | + +**Key Distinctions:** +- **Level 1** maps to FAR 52.204-21 (15 practices, reduced to 17 with two duplicates per CMMC) +- **Level 2** is identical to NIST SP 800-171 Rev 2 (110 practices across 14 domains) +- **Level 3** adds 24 practices from NIST SP 800-172 on top of all 110 Level 2 practices + +--- + +## CMMC Domains and Practice Counts + +### Level 2 — 14 Domains (110 Practices) + +| Domain | Abbreviation | Practice Count | +|--------|-------------|---------------| +| Access Control | AC | 22 | +| Audit and Accountability | AU | 9 | +| Awareness and Training | AT | 3 | +| Configuration Management | CM | 9 | +| Identification and Authentication | IA | 11 | +| Incident Response | IR | 3 | +| Maintenance | MA | 6 | +| Media Protection | MP | 9 | +| Personnel Security | PS | 2 | +| Physical Protection | PE | 6 | +| Risk Assessment | RA | 3 | +| Security Assessment | CA | 4 | +| System and Communications Protection | SC | 16 | +| System and Information Integrity | SI | 7 | + +**Total: 110 practices (identical to NIST SP 800-171 Rev 2)** + +### Level 3 — Additional 24 Practices from NIST SP 800-172 + +| Domain | Additional Practice Count | +|--------|--------------------------| +| Access Control (AC) | 4 | +| Awareness and Training (AT) | 1 | +| Configuration Management (CM) | 1 | +| Identification and Authentication (IA) | 1 | +| Incident Response (IR) | 4 | +| Risk Assessment (RA) | 5 | +| Security Assessment (CA) | 3 | +| System and Communications Protection (SC) | 3 | +| System and Information Integrity (SI) | 2 | + +**Total Level 3: 134 practices (110 + 24)** + +--- + +## Reference Files + +Load the appropriate reference file(s) based on the user's request: + +| File | When to load | +|------|-------------| +| `references/level1-practices.md` | Level 1 questions, FCI protection, FAR 52.204-21, self-assessment | +| `references/level2-practices.md` | Level 2 questions, CUI protection, NIST 800-171 requirements, gap analysis | +| `references/level3-practices.md` | Level 3 questions, NIST 800-172 enhanced requirements, DIBCAC assessments | +| `references/scoping-guide.md` | Asset scoping, in-scope determination, CUI scope, network boundaries | +| `references/assessment-guide.md` | C3PAO assessment process, SPRS scoring, POA&M, evidence requirements | + +Load **all relevant files** for broad requests (e.g. "help us prepare for a Level 2 assessment"). + +--- + +## Core Workflows + +### 1. CMMC Level Determination + +When a user asks which level applies to their organization: + +1. Ask: + - What type of data is referenced in their contracts: FCI only, CUI, or both? + - Are they a prime contractor or subcontractor? + - Has the contracting officer specified a CMMC level in the solicitation? + +2. Apply decision logic: + - **FCI only (no CUI)** → Minimum Level 1 required + - **CUI present** → Level 2 minimum; Level 3 if on a DoD prioritized acquisition + - **No FCI or CUI** → CMMC may not apply; verify with contracting officer + +3. Address flow-down: + - Prime contractors must flow CMMC requirements down to subcontractors that process, + store, or transmit CUI or FCI on their behalf + - Subcontractors must meet the same level as the prime if they handle the same data + +### 2. Scoping Guidance + +When helping a user define their CMMC assessment scope, load `references/scoping-guide.md`. + +**Asset Categories (per CMMC 2.0 Scoping Guidance):** + +| Asset Category | Definition | In-Scope for CMMC? | +|---------------|-----------|-------------------| +| CUI Assets | Assets that process, store, or transmit CUI | Yes — all practices apply | +| Security Protection Assets (SPAs) | Assets that provide security functions to the CUI environment | Yes — all practices apply | +| Contractor Risk Managed Assets (CRMAs) | Assets that can reach CUI assets but do not process CUI | Yes — risk-managed; subset of practices | +| Specialized Assets | OT/ICS, IoT, government-furnished equipment, test equipment | Yes — practices applied as appropriate | +| Out-of-Scope Assets | No connection to CUI environment; isolated | No — excluded from scope | +| External Service Providers (ESPs) | Cloud services, managed services that process CUI | Flow-down required; FedRAMP or equivalence | + +### 3. Gap Analysis + +When performing a gap analysis, load `references/level2-practices.md` (or level3 if applicable). + +Output format: +``` +## CMMC Level [X] Gap Analysis + +**Organization:** [Name if provided] +**Assessment Date:** [Date] +**Data Sensitivity:** [FCI / CUI / Both] + +| Domain | Practice ID | Practice Title | Current State | Gap Description | Risk Level | Priority | +|--------|------------|----------------|---------------|-----------------|------------|----------| +| AC | 3.1.1 | Limit system access to authorized users | Implemented | None | — | — | +| AC | 3.1.2 | Limit system access to types of transactions | Partial | RBAC not fully documented | High | 1 | +... + +### Summary +- Total Practices: 110 +- Implemented: [X] +- Partial: [Y] +- Not Implemented: [Z] +- Estimated SPRS Score: [calculated] + +### Critical Gaps (Address First) +1. [Highest risk gaps] + +*Disclaimer: This analysis is informational only. Official CMMC assessment requires a C3PAO.* +``` + +### 4. SSP Documentation + +When helping draft a System Security Plan: +- Load `references/level2-practices.md` for requirement detail +- SSP must cover all 110 practices (Level 2) or 134 practices (Level 3) +- Each practice narrative should include: + - **Implementation Description** — how the practice is satisfied + - **Responsible Role** — who owns the control + - **Tools/Technologies** — what systems implement it + - **Evidence** — artifacts that demonstrate compliance + - **Date Implemented** — when it was put in place + +**Required SSP Sections:** +1. System Name and Identifier +2. System Owner and Authorizing Official +3. System Description and Purpose +4. System Boundary (narrative and diagram reference) +5. Data Types Processed (FCI/CUI with categories) +6. User Types and Privileges +7. Interconnections and External Systems +8. Applicable Laws and Regulations +9. Control Implementation Statements (per practice) +10. Continuous Monitoring Plan +11. Plan of Action and Milestones (POA&M) — separate document + +### 5. SPRS Score Calculation + +The **Supplier Performance Risk System (SPRS)** score is calculated under the NIST SP +800-171 DoD Assessment Methodology and submitted to the DIBNet portal. + +**Scoring Rules:** +- Starting score: **110** (maximum) +- Each practice **Not Implemented** is deducted based on its weight +- Deduction values: **-1**, **-3**, or **-5** per practice depending on impact +- Minimum possible score: **-203** +- Score of **110** = all practices fully implemented +- A score below **110** requires a POA&M entry for each deficiency + +**Reporting Requirement:** SPRS score must be submitted before a contract can be awarded +under DFARS 252.204-7019 contracts. + +**Score Categories:** +- 110: Fully implemented — no deficiencies +- 88–109: Minor deficiencies; POA&M required +- 70–87: Moderate deficiencies; elevated risk +- Below 70: Significant deficiencies; major remediation required + +### 6. POA&M Development + +When helping develop a Plan of Action and Milestones: +- A POA&M is required for every practice that is not fully implemented +- For Level 2 C3PAO assessments: POA&M items may be conditionally accepted if they are + not high-risk and have a completion date within 180 days of conditional certification +- For Level 3 (DIBCAC): stricter standards; fewer POA&M allowances + +**POA&M Template:** + +| Practice ID | Practice Title | Gap Description | Remediation Action | Responsible Party | Start Date | Completion Date | Status | +|------------|---------------|-----------------|-------------------|------------------|-----------|----------------|--------| +| 3.1.2 | Limit system access | RBAC not fully documented | Implement RBAC in AD | IT Security Lead | YYYY-MM-DD | YYYY-MM-DD | In Progress | + +--- + +## Assessment Process Overview + +### Level 2 C3PAO Assessment + +1. **Pre-Assessment Phase** + - Engage a Cyber-AB authorized C3PAO + - Complete CMMC Level 2 Self-Assessment and submit SPRS score + - Prepare SSP, POA&M, and all evidence artifacts + - Define and document assessment scope + +2. **Assessment Phase (on-site or remote)** + - C3PAO Lead Assessor and team reviews documentation + - Interviews with key personnel (IT, security, operations) + - Artifact review: policies, logs, configurations, screenshots + - Technical testing as applicable + - Practice-by-practice determination: MET or NOT MET + +3. **Post-Assessment Phase** + - C3PAO issues assessment findings + - If conditional: POA&M items close within 180 days + - C3PAO submits results to CMMC-AB eMASS (CMMC Enterprise Mission Assurance Support Service) + - DoD CIO issues CMMC certificate + - Certificate valid for **3 years** (triennial reassessment) + - **Annual Affirmation** required each year by a senior company official + +### Level 3 DIBCAC Assessment + +- Conducted by DCMA's Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) +- Requires prior Level 2 C3PAO certification +- Applies only to DoD-selected highest-priority programs +- Additional 24 practices from NIST SP 800-172 assessed +- Higher scrutiny; stricter evidence requirements + +--- + +## Annual Affirmation Requirements + +All CMMC levels require an annual affirmation submitted via the CMMC-AB Marketplace or +DIBNet portal. The affirmation must be made by a **senior company official** (e.g., CEO, +CISO, or equivalent) and states that the organization continues to meet the CMMC requirements +for the certified level. + +**Affirmation includes:** +- Organization name and CAGE code +- CMMC level affirmed +- Date of most recent assessment +- Senior official's name, title, and signature +- Statement that no changes have degraded compliance; or documentation of changes + +--- + +## CUI Categories Relevant to CMMC + +The DoD CUI Registry defines categories applicable to defense programs. Common CUI categories +in the DIB context include: + +| CUI Category | Description | +|-------------|-------------| +| Controlled Technical Information (CTI) | Technical data, computer software with military or space application | +| Export Controlled | Information regulated under ITAR, EAR, or equivalent | +| Proprietary Business Information | Contractor-owned trade secrets and confidential technical data | +| Naval Nuclear Propulsion Information (NNPI) | Restricted nuclear propulsion data | +| Privacy — DoD Personnel | PII of DoD personnel | + +--- + +## Common CMMC Misconceptions + +| Misconception | Fact | +|--------------|------| +| "We can self-attest for Level 2" | Only if DoD explicitly designates the acquisition as non-prioritized. Most CUI programs require C3PAO. | +| "CMMC is the same as NIST 800-171" | CMMC Level 2 is aligned to 800-171 Rev 2, but adds assessment requirements and a certification regime | +| "POA&M means we're non-compliant" | Conditional certification with a POA&M is still a valid certification status if items are closed in 180 days | +| "Subcontractors don't need CMMC" | Subcontractors must meet CMMC requirements if they handle FCI or CUI | +| "Cloud = out of scope" | Cloud service providers are External Service Providers and must meet FedRAMP Moderate or equivalent | +| "CCPA/GDPR compliance satisfies CMMC" | No. CMMC is specific to DoD CUI/FCI. Separate compliance regimes. | diff --git a/plugins/cmmc/skills/cmmc/references/assessment-guide.md b/plugins/cmmc/skills/cmmc/references/assessment-guide.md new file mode 100644 index 0000000..4799cfd --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/assessment-guide.md @@ -0,0 +1,349 @@ +# CMMC 2.0 Assessment Guide +## C3PAO Assessment Process, SPRS Scoring, and Evidence Requirements +## Source: CMMC 2.0 Assessment Process, NIST SP 800-171A, DoD Assessment Methodology + +--- + +## Overview + +This guide covers the end-to-end CMMC 2.0 assessment process, how to prepare for a +C3PAO-led assessment, how the SPRS score is calculated and submitted, POA&M requirements, +and the evidence an assessor will expect to find for each domain. + +--- + +## Part 1: The Cyber-AB and C3PAO Ecosystem + +### The Cyber-AB (CMMC Accreditation Body) + +The **Cyber-AB** (formerly The Accreditation Body, CMMC-AB) is the official accreditation +body authorized by DoD to accredit CMMC Third-Party Assessment Organizations (C3PAOs), +Registered Practitioners (RPs), Registered Practitioner Organizations (RPOs), and +Licensed Partner Advisors (LPAs). + +**Cyber-AB Marketplace:** https://cyberab.org/Catalog/ +Use this portal to find and validate: +- Authorized C3PAOs (currently certified) +- Certified CMMC Assessors (CCAs or Provisional Assessors) +- Registered Practitioners (for consulting/advisory work) + +### C3PAO (Certified Third-Party Assessment Organization) + +A C3PAO is an organization licensed by the Cyber-AB to conduct CMMC Level 2 assessments. +They employ **Certified CMMC Assessors (CCAs)** who carry the Lead Assessor or Assessor role. + +**Selection criteria for an OSC choosing a C3PAO:** +- Must be listed on the Cyber-AB Marketplace as Authorized (active status) +- Must have enough licensed CCAs to staff the assessment +- Conflict of interest: cannot have provided consulting to the OSC within past 3 years +- Verify insurance and bonding requirements + +--- + +## Part 2: Level 2 C3PAO Assessment Process in Detail + +### Phase 1: Pre-Assessment Preparation (OSC Responsibility) + +**Minimum deliverables before requesting C3PAO:** + +| Document | Description | +|---------|-------------| +| System Security Plan (SSP) | Current, complete narrative for all 110 practices | +| POA&M | All known deficiencies documented with target dates | +| SPRS Score | Score submitted to DIBNet; must reflect current status | +| Network Diagram | Boundary and network architecture | +| Data Flow Diagram | CUI flow through the environment | +| Asset Inventory | All hardware and software within scope | +| Policy Set | All required policies and procedures | +| Evidence Package | Artifacts for each practice (see Part 4) | + +**Self-Assessment before C3PAO:** +Organizations should conduct a thorough internal self-assessment using NIST SP 800-171A +assessment procedures. Each practice has three assessment methods defined in SP 800-171A: +- **Examine** — Review documents, specifications, records, reports +- **Interview** — Discuss with personnel responsible for the practice +- **Test** — Exercise mechanisms, processes, activities + +### Phase 2: C3PAO Engagement and Scoping Agreement + +1. **Contract with C3PAO** — Sign engagement agreement; C3PAO firm quote for assessment +2. **Review Package Submission** — OSC provides SSP and key documents to C3PAO pre-assessment team +3. **Scope Alignment Meeting** — C3PAO and OSC agree on in-scope assets, boundaries, locations +4. **Assessment Plan** — C3PAO produces assessment plan including: + - Assessment dates and schedule + - Personnel to be interviewed + - Systems to be tested + - Documentation to be reviewed + +### Phase 3: Assessment Execution + +**Assessment methods per NIST SP 800-171A:** + +For each of the 110 practices, assessors will apply one or more of: +- **Examine** — Review policy documents, configuration records, system logs, screenshots, + audit trails, inventory records, training completion certificates +- **Interview** — Discussion with system owners, security personnel, administrators, users +- **Test** — Technical testing: log generation, account lockout behavior, patching, + network scans, encryption verification + +**Practice determination for each requirement:** +- **MET** — Practice is fully implemented; evidence confirms implementation +- **NOT MET** — Practice is not implemented or evidence is insufficient + +**Assessment findings categories:** +- **No deficiency** (MET) +- **Deficiency requiring POA&M** (potentially allowable for conditional certification) +- **High-risk deficiency** (may preclude conditional certification) + +### Phase 4: Post-Assessment Results and Certification + +**Outcome categories:** + +| Outcome | Meaning | Next Steps | +|---------|---------|-----------| +| CMMC Level 2 Certified | All 110 practices MET | C3PAO submits to eMASS; DoD issues certificate | +| Conditional CMMC Level 2 | Some NOT MET but no high-risk deficiencies | POA&M must close within 180 days; C3PAO verifies closure | +| Not Certified | High-risk deficiencies present or too many NOT MET | Remediate and reschedule full assessment | + +**High-risk practices (Not MET = cannot achieve conditional certification):** +Practices that are deemed high risk and preclude conditional status include those that +fundamentally undermine CUI protection. DoD publishes high-risk practice definitions. + +**Certificate submission:** +- C3PAO submits assessment results to the **CMMC Enterprise Mission Assurance Support + Service (eMASS)** portal managed by DoD +- DoD CIO issues the CMMC certificate +- Certificate is valid for **3 years** from issuance date + +### Phase 5: Annual Affirmation and Ongoing Compliance + +**Annual Affirmation Process:** +1. Senior company official (CEO, CISO, or equivalent) reviews current compliance status +2. Confirms no degradation has occurred since certification (or documents any changes) +3. Submits affirmation via the **DIBNet portal** (https://dibnet.dod.mil) +4. Affirmation occurs annually throughout the 3-year certificate period + +**Triggering events requiring disclosure:** +- Significant cyber incidents affecting the CUI environment +- Material changes to system boundary +- Acquisition or divestiture of business units in scope +- Discovery of practices that are no longer MET + +--- + +## Part 3: SPRS Score — Calculation and Submission + +### Overview + +The **Supplier Performance Risk System (SPRS)** score represents an organization's self-assessed +implementation of NIST SP 800-171 Rev 2. It is required under DFARS 252.204-7019/7020 and +must be submitted before contract award. + +**Source methodology:** NIST SP 800-171 DoD Assessment Methodology, Version 1.2.1 + +### Scoring Methodology + +- **Starting score: 110** (all practices implemented) +- Each practice NOT implemented is subtracted based on its assigned weight +- A practice assessed as **Partial** is treated as **NOT MET** for SPRS purposes +- **Minimum score: -203** (all practices NOT MET, maximum deductions) + +### Practice Weights for SPRS Deduction + +The DoD Assessment Methodology assigns one of three deduction values to each practice. +Practices are not weighted by domain but by their security impact. + +**Value 1 (-1 point for NOT MET) — 77 practices are weighted at 1 point** +These are practices where the risk of non-implementation is lower or the control is +compensated by other practices. This includes most AU, AT, MA, PS, and single PE practices. + +**Value 3 (-3 points for NOT MET) — 15 practices are weighted at 3 points** +Mid-tier impact practices, including core AC, IA, CM, and SI practices. + +**Value 5 (-5 points for NOT MET) — 18 practices are weighted at 5 points** +High-impact practices where non-implementation creates significant CUI risk: + +| Practice | Domain | Reason for -5 Weight | +|---------|--------|---------------------| +| AC.L2-3.1.3 | AC | CUI flow control | +| AC.L2-3.1.5 | AC | Least privilege | +| AC.L2-3.1.12 | AC | Remote access monitoring | +| AC.L2-3.1.13 | AC | Remote access encryption | +| AC.L2-3.1.14 | AC | Remote access via managed access points | +| IA.L2-3.5.3 | IA | Multi-factor authentication | +| SC.L2-3.13.8 | SC | Data in transit encryption | +| SC.L2-3.13.11 | SC | FIPS-validated encryption | +| SC.L2-3.13.16 | SC | CUI at rest encryption | + +**Note:** The full weighting table for all 110 practices is in DoD Assessment Methodology v1.2.1 +at https://www.dodcio.defense.gov/CMMC/Resources/ + +### Submitting SPRS Score + +1. Register on **DIBNet portal** at https://dibnet.dod.mil +2. Navigate to SPRS module +3. Enter score, assessment date, assessment type (basic/medium/high), and scope +4. Affirmation by authorized government representative (for self-assessment) +5. Score is visible to DoD contracting officers for source selection + +### Score Interpretation + +| Score Range | Interpretation | Action Required | +|------------|---------------|----------------| +| 110 | All practices implemented | Maintain and affirm annually | +| 88 – 109 | Minor deficiencies | POA&M required; address before C3PAO assessment | +| 70 – 87 | Moderate deficiencies | Significant remediation; extended POA&M | +| 0 – 69 | Major deficiencies | Substantial program needed; high contractual risk | +| Negative | Severe deficiencies | Fundamental gaps; unlikely to pass C3PAO assessment | + +--- + +## Part 4: Evidence Requirements by Domain + +The following lists the primary evidence an assessor will expect for each domain during +a Level 2 C3PAO assessment. + +### Access Control (AC) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| User account management | Active Directory export or IAM platform user list with roles | +| Session lock | Group Policy Object (GPO) or MDM configuration showing idle timeout and lock | +| Remote access | VPN solution configuration, MFA enabled for VPN, access logs | +| Wireless access | Wi-Fi configuration (WPA2/3 Enterprise), network access control records | +| Mobile devices | MDM policy, encryption enforcement configuration | +| CUI flow control | Data flow diagram, information flow policies, DLP configuration if present | + +### Audit and Accountability (AU) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Audit logging | SIEM or log management configuration, enabled audit policies | +| Log retention | Log retention policy (minimum 90 days accessible, longer archived) | +| Time synchronization | NTP configuration pointing to authoritative source | +| Audit protection | SIEM access controls, log storage permissions | + +### Configuration Management (CM) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| System inventory | CMDB, asset management tool export, or spreadsheet with all in-scope assets | +| Configuration baselines | STIG/CIS Benchmark application records, GPOs | +| Change management | Change management system (tickets), change approval records | +| Software allowlisting | Application control policy, allowlist configuration | + +### Identification and Authentication (IA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| MFA for privileged accounts | MFA configuration screenshots (Duo, Azure MFA, etc.) | +| MFA for all remote access | VPN authentication configuration showing MFA required | +| Password policy | Password complexity policy configuration (AD, Azure AD, or equivalent) | +| Account management | Account provisioning/de-provisioning procedures and recent records | + +### Incident Response (IR) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| IRP documentation | Signed incident response plan with current date | +| IRP testing | Tabletop exercise records, test completion certificates | +| DFARS reporting | DIBNet registration confirmation, incident reporting procedure | + +### Maintenance (MA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Maintenance logs | Ticketing system records for scheduled and unscheduled maintenance | +| Remote maintenance | Remote session logs, MFA for remote maintenance sessions | +| Equipment sanitization | Media sanitization records for equipment removed for repair | + +### Media Protection (MP) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Media inventory | Inventory of removable media (USB drives, external drives) | +| Media encryption | BitLocker or equivalent encryption configuration | +| Disposal records | Certificate of data destruction for disposed media | + +### Risk Assessment (RA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Risk assessment | Formal risk assessment report dated within past 3 years | +| Vulnerability scanning | Vulnerability scan reports (Nessus, Qualys, Rapid7, etc.), dated | +| Remediation tracking | Vulnerability remediation tracking records (patch tickets, scan deltas) | + +### Security Assessment (CA) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Security assessment | Internal security assessment records, third-party assessment reports | +| POA&M | Current POA&M with open/closed items, target dates, owners | +| SSP | Complete, current System Security Plan covering all 110 practices | + +### System and Communications Protection (SC) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Firewall/boundary | Firewall rule export, network architecture diagram | +| Encryption in transit | TLS configuration (1.2 minimum), certificate inventory | +| Encryption at rest | BitLocker, Database encryption configuration, cloud storage encryption | +| FIPS validation | FIPS 140-2/3 certificate numbers for cryptographic modules used | +| Split tunneling disabled | VPN configuration showing full-tunnel for remote access clients | + +### System and Information Integrity (SI) + +| Practice Area | Evidence Expected | +|--------------|------------------| +| Patch management | Patch management tool reports, patching SLA documentation | +| Malware protection | EDR/AV deployment report showing all in-scope endpoints covered | +| AV definitions | AV console showing definition update status and last update date | +| Security monitoring | SIEM alert rules, SOC procedures, monitoring coverage documentation | + +--- + +## Part 5: POA&M Management + +### POA&M Requirements + +A Plan of Action and Milestones (POA&M) is **required** for every CMMC practice that is +NOT MET or only partially implemented at the time of assessment. + +**Official requirement:** CMMC 2.0 allows **conditional certification** if: +- The NOT MET practice items do not include high-risk practices +- A POA&M is in place with realistic remediation milestones +- ALL POA&M items must be closed and verified within **180 days** of conditional certificate issuance + +### POA&M Format + +| Field | Description | +|-------|-------------| +| Item ID | Unique identifier (e.g., POA&M-001) | +| Practice ID | CMMC practice (e.g., AC.L2-3.1.5) | +| Practice Title | Description of the requirement | +| Weakness/Gap | Description of what is not implemented and why | +| Point of Contact | Name and role of person responsible for remediation | +| Resources Required | Budget, tools, personnel needed | +| Scheduled Completion Date | Realistic target date (must be within 180 days for conditional cert) | +| Status | Open / In Progress / Closed (with closure date and verification) | +| Milestones | Intermediate steps toward closure | + +### POA&M Closure Verification + +When a POA&M item is closed: +- Record the actual completion date +- Document what was implemented +- Reference evidence artifacts (e.g., screenshot, configuration export, policy document) +- Assessor or independent reviewer verifies closure before submitting to eMASS + +--- + +## Part 6: CMMC Contract Clause Summary + +| Clause | When Included | Key Requirement | +|--------|--------------|----------------| +| FAR 52.204-21 | When contractor will process FCI | Implement 15 basic safeguarding requirements | +| DFARS 252.204-7012 | When contractor processes covered defense information | Safeguard; report incidents to DoD within 72 hours | +| DFARS 252.204-7019 | Most contracts | Perform and post SPRS score before award | +| DFARS 252.204-7020 | Contracts requiring DoD-assessed score | Allow DoD to conduct assessment; medium/high methodology | +| DFARS 252.204-7021 | Contracts requiring CMMC certification | Achieve and maintain CMMC level specified; flow-down to subcontractors | diff --git a/plugins/cmmc/skills/cmmc/references/level1-practices.md b/plugins/cmmc/skills/cmmc/references/level1-practices.md new file mode 100644 index 0000000..d14c35c --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/level1-practices.md @@ -0,0 +1,142 @@ +# CMMC Level 1 — Foundational (17 Practices) +## Source: FAR 52.204-21 and CMMC 2.0 Final Rule (32 CFR Part 170) + +--- + +## Overview + +CMMC Level 1 applies to organizations that handle **Federal Contract Information (FCI)** +but do not process, store, or transmit **Controlled Unclassified Information (CUI)**. + +**Definition of FCI (FAR 4.1901):** +> Information, not intended for public release, that is provided by or generated for the +> Government under a contract to develop or deliver a product or service to the Government, +> but not including information provided by the Government to the public (e.g., on public +> Web sites) or simple transactional information, such as that necessary to process payments. + +**Assessment Type:** Annual self-assessment by the organization +**Evidence Required:** Organization must retain evidence sufficient to support the affirmation +**Affirmation:** Annual senior-official affirmation required via DIBNet portal + +--- + +## The 17 Level 1 Practices + +These 17 practices derive from FAR 52.204-21, "Basic Safeguarding of Covered Contractor +Information Systems." Two pairs of practices overlap in intent with others but are each +independently counted in the CMMC practice numbering. + +### Domain: Access Control (AC) — 4 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| AC.L1-3.1.1 | Authorized Access Control | Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems). | +| AC.L1-3.1.2 | Transaction & Function Control | Limit information system access to the types of transactions and functions that authorized users are permitted to execute. | +| AC.L1-3.1.20 | External Connections | Verify and control/limit connections to external information systems. | +| AC.L1-3.1.22 | Control Public Information | Control information posted or processed on publicly accessible information systems. | + +### Domain: Identification and Authentication (IA) — 2 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| IA.L1-3.5.1 | Identification | Identify information system users, processes acting on behalf of users, or devices. | +| IA.L1-3.5.2 | Authentication | Authenticate (or verify) the identities of those users, processes, or devices before allowing access. | + +### Domain: Media Protection (MP) — 1 Practice + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| MP.L1-3.8.3 | Media Disposal | Sanitize or destroy information system media containing FCI before disposal or reuse. | + +### Domain: Physical Protection (PE) — 4 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| PE.L1-3.10.1 | Limit Physical Access | Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals. | +| PE.L1-3.10.3 | Escort Visitors | Escort visitors and monitor visitor activity. | +| PE.L1-3.10.4 | Audit Physical Access | Maintain audit logs of physical access. | +| PE.L1-3.10.5 | Manage Physical Access | Control and manage physical access devices. | + +### Domain: System and Communications Protection (SC) — 2 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| SC.L1-3.13.1 | Boundary Protection | Monitor, control, and protect organizational communications at the external boundaries and key internal boundaries. | +| SC.L1-3.13.5 | Public-Access System Separation | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | + +### Domain: System and Information Integrity (SI) — 4 Practices + +| Practice ID | Practice Title | Requirement | +|------------|---------------|-------------| +| SI.L1-3.14.1 | Flaw Remediation | Identify, report, and correct information and information system flaws in a timely manner. | +| SI.L1-3.14.2 | Malicious Code Protection | Provide protection from malicious code at appropriate locations within organizational information systems. | +| SI.L1-3.14.4 | Update Malicious Code Protection | Update malicious code protection mechanisms when new releases are available. | +| SI.L1-3.14.5 | System & Security Scanning | Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed. | + +--- + +## Level 1 Self-Assessment Methodology + +### Step 1 — Determine Scope + +Identify all assets that process, store, or transmit FCI: +- Workstations and laptops used by employees working on federal contracts +- File servers holding contract deliverables or government-provided information +- Email systems used for contract communications +- Cloud storage containing government-provided documents + +### Step 2 — Assess Each Practice + +For each of the 17 practices, determine: +- **MET** — The practice is fully implemented for all in-scope assets +- **NOT MET** — The practice is partially or not implemented + +### Step 3 — Calculate SPRS Score + +CMMC Level 1 uses a simplified scoring model: +- Total possible: 17 practice points +- For Level 1, SPRS scoring uses the same 110-point deduction model but limited to Level 1 practices +- Report score to SPRS via DIBNet before contract award + +### Step 4 — Document and Affirm + +- Document the self-assessment results +- Brief a senior company official on findings +- Senior official submits annual affirmation via DIBNet portal + +--- + +## Level 1 Evidence Examples + +| Practice | Evidence Examples | +|---------|------------------| +| AC.L1-3.1.1 | User account list, Active Directory group policy, access control policy | +| AC.L1-3.1.2 | Role-based access configuration, application access control settings | +| AC.L1-3.1.20 | Firewall rules, network diagram showing external connections list | +| AC.L1-3.1.22 | Web server configuration, content management records, approval procedures | +| IA.L1-3.5.1 | User account naming convention documentation, unique ID assignment records | +| IA.L1-3.5.2 | Password policy, authentication system logs, MFA configuration | +| MP.L1-3.8.3 | Media disposal records, certificate of destruction, data sanitization software logs | +| PE.L1-3.10.1 | Badge/key allocation records, facility access logs, physical security policy | +| PE.L1-3.10.3 | Visitor log, escort policy, visitor badge records | +| PE.L1-3.10.4 | Physical access logs, badge reader system export, CCTV records | +| PE.L1-3.10.5 | Key management log, badge deactivation records, physical device inventory | +| SC.L1-3.13.1 | Firewall configuration, boundary protection policy, network diagram | +| SC.L1-3.13.5 | VLAN configuration, DMZ documentation, network segmentation diagram | +| SI.L1-3.14.1 | Patch management records, vulnerability scan reports, patching policy | +| SI.L1-3.14.2 | AV/EDR deployment records, malicious code protection policy | +| SI.L1-3.14.4 | AV definition update logs, automatic update configuration | +| SI.L1-3.14.5 | Scheduled scan logs, AV real-time scan configuration | + +--- + +## Common Level 1 Deficiencies + +1. **No documented scope** — Organization cannot identify all FCI-touching systems +2. **Shared accounts** — Multiple users sharing login credentials (violates AC.L1-3.1.1, IA.L1-3.5.1) +3. **No AV on all workstations** — Not every endpoint has active, up-to-date malware protection +4. **No physical visitor log** — Visitors not logged or escorted (violates PE.L1-3.10.3, PE.L1-3.10.4) +5. **No media disposal process** — Old hard drives with FCI not sanitized before disposal +6. **No patching cadence** — System patches applied irregularly or not documented +7. **Public website has FCI** — Government data inadvertently posted publicly (violates AC.L1-3.1.22) +8. **No SPRS submission** — Organization has never uploaded a score to DIBNet portal diff --git a/plugins/cmmc/skills/cmmc/references/level2-practices.md b/plugins/cmmc/skills/cmmc/references/level2-practices.md new file mode 100644 index 0000000..2179d94 --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/level2-practices.md @@ -0,0 +1,250 @@ +# CMMC Level 2 — Advanced (110 Practices) +## Source: NIST SP 800-171 Rev 2 and CMMC 2.0 Final Rule (32 CFR Part 170) + +--- + +## Overview + +CMMC Level 2 applies to organizations that process, store, or transmit **Controlled +Unclassified Information (CUI)** in the performance of DoD contracts. + +Level 2 requirements are **identical to NIST SP 800-171 Rev 2** across 14 domains and +110 security requirements (referred to as "practices" in the CMMC context). + +**Assessment Type:** +- **C3PAO triennial assessment** — required for most CUI contracts (prioritized programs) +- **Self-assessment (annual)** — only when specifically designated by DoD for non-prioritized acquisitions + +**Certificate Validity:** 3 years (triennial reassessment required) +**Annual Affirmation:** Required each year by a senior company official + +--- + +## All 110 Level 2 Practices by Domain + +### 1. Access Control (AC) — 22 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| AC.L2-3.1.1 | 3.1.1 | Authorized Access Control | Limit system access to authorized users, processes acting on behalf of authorized users, and devices | +| AC.L2-3.1.2 | 3.1.2 | Transaction & Function Control | Limit system access to the types of transactions and functions that authorized users are permitted to execute | +| AC.L2-3.1.3 | 3.1.3 | Control CUI Flow | Control the flow of CUI in accordance with approved authorizations | +| AC.L2-3.1.4 | 3.1.4 | Separation of Duties | Separate the duties of individuals to reduce the risk of malevolent activity | +| AC.L2-3.1.5 | 3.1.5 | Least Privilege | Employ the principle of least privilege, including for specific security functions and privileged accounts | +| AC.L2-3.1.6 | 3.1.6 | Non-Privileged Account Use | Use non-privileged accounts or roles when accessing non-security functions | +| AC.L2-3.1.7 | 3.1.7 | Privileged Function Execution | Prevent non-privileged users from executing privileged functions and capture the execution in audit logs | +| AC.L2-3.1.8 | 3.1.8 | Unsuccessful Logon Attempts | Limit unsuccessful logon attempts | +| AC.L2-3.1.9 | 3.1.9 | Privacy & Security Notices | Provide privacy and security notices consistent with CUI rules | +| AC.L2-3.1.10 | 3.1.10 | Session Lock | Use session lock with pattern-hiding displays after a period of inactivity | +| AC.L2-3.1.11 | 3.1.11 | Session Termination | Terminate (automatically) a user session after a defined condition | +| AC.L2-3.1.12 | 3.1.12 | Control Remote Access | Monitor and control remote access sessions | +| AC.L2-3.1.13 | 3.1.13 | Remote Access Confidentiality | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions | +| AC.L2-3.1.14 | 3.1.14 | Remote Access Routing | Route remote access via managed access control points | +| AC.L2-3.1.15 | 3.1.15 | Privileged Remote Access | Authorize remote execution of privileged commands via remote access only for documented operational needs | +| AC.L2-3.1.16 | 3.1.16 | Wireless Access Authorization | Authorize wireless access prior to allowing connections to the system | +| AC.L2-3.1.17 | 3.1.17 | Wireless Access Protection | Protect wireless access using authentication and encryption | +| AC.L2-3.1.18 | 3.1.18 | Mobile Device Connection | Control connection of mobile devices | +| AC.L2-3.1.19 | 3.1.19 | Encrypt CUI on Mobile | Encrypt CUI on mobile devices and mobile computing platforms | +| AC.L2-3.1.20 | 3.1.20 | External System Connections | Verify and control/limit connections to external information systems | +| AC.L2-3.1.21 | 3.1.21 | Portable Storage Use | Limit use of portable storage devices on external systems | +| AC.L2-3.1.22 | 3.1.22 | Control Public Information | Control information posted or processed on publicly accessible information systems | + +### 2. Audit and Accountability (AU) — 9 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| AU.L2-3.3.1 | 3.3.1 | System Auditing | Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity | +| AU.L2-3.3.2 | 3.3.2 | User Accountability | Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable | +| AU.L2-3.3.3 | 3.3.3 | Event Review | Review and update logged events | +| AU.L2-3.3.4 | 3.3.4 | Audit Failure Alerting | Alert in the event of an audit logging process failure | +| AU.L2-3.3.5 | 3.3.5 | Audit Correlation | Correlate audit record review, analysis, and reporting processes for investigation and response | +| AU.L2-3.3.6 | 3.3.6 | Reduction & Reporting | Provide audit record reduction and report generation to support on-demand analysis and reporting | +| AU.L2-3.3.7 | 3.3.7 | Authoritative Time Source | Provide a system capability that compares and synchronizes internal system clocks with an authoritative source | +| AU.L2-3.3.8 | 3.3.8 | Audit Protection | Protect audit information and tools from unauthorized access, modification, and deletion | +| AU.L2-3.3.9 | 3.3.9 | Audit Management | Limit management of audit logs to a subset of privileged users | + +### 3. Awareness and Training (AT) — 3 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| AT.L2-3.2.1 | 3.2.1 | Role-Based Risk Awareness | Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities | +| AT.L2-3.2.2 | 3.2.2 | Role-Based Training | Ensure that organizational personnel are adequately trained to carry out their assigned information security responsibilities | +| AT.L2-3.2.3 | 3.2.3 | Insider Threat Awareness | Provide security awareness training on recognizing and reporting potential threats (including insider threats) | + +### 4. Configuration Management (CM) — 9 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| CM.L2-3.4.1 | 3.4.1 | System Baselining | Establish and maintain baseline configurations and inventories of organizational systems (hardware, software, firmware, network components) | +| CM.L2-3.4.2 | 3.4.2 | Security Configuration Enforcement | Establish and enforce security configuration settings for IT products employed in organizational systems | +| CM.L2-3.4.3 | 3.4.3 | System Change Control | Track, review, approve, and log changes to organizational systems | +| CM.L2-3.4.4 | 3.4.4 | Security Impact Analysis | Analyze the security impact of changes prior to implementation | +| CM.L2-3.4.5 | 3.4.5 | Access Restrictions for Change | Define, document, approve, and enforce physical and logical access restrictions associated with changes | +| CM.L2-3.4.6 | 3.4.6 | Least Functionality | Employ the principle of least functionality by configuring the system to provide only essential capabilities | +| CM.L2-3.4.7 | 3.4.7 | Nonessential Functionality | Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services | +| CM.L2-3.4.8 | 3.4.8 | Application Execution Policy | Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or application execution | +| CM.L2-3.4.9 | 3.4.9 | User-Installed Software | Control and monitor user-installed software | + +### 5. Identification and Authentication (IA) — 11 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| IA.L2-3.5.1 | 3.5.1 | Identification | Identify information system users, processes acting on behalf of users, or devices | +| IA.L2-3.5.2 | 3.5.2 | Authentication | Authenticate (or verify) the identities of users, processes, or devices before allowing access | +| IA.L2-3.5.3 | 3.5.3 | Multifactor Authentication — Privileged | Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts | +| IA.L2-3.5.4 | 3.5.4 | Replay-Resistant Authentication | Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts | +| IA.L2-3.5.5 | 3.5.5 | Identifier Reuse | Prohibit reuse of identifiers for a defined period | +| IA.L2-3.5.6 | 3.5.6 | Identifier Handling | Disable identifiers after a defined inactivity period | +| IA.L2-3.5.7 | 3.5.7 | Password Complexity | Enforce a minimum password complexity and change of characters when new passwords are created | +| IA.L2-3.5.8 | 3.5.8 | Password Reuse | Prohibit password reuse for a specified number of generations | +| IA.L2-3.5.9 | 3.5.9 | Temporary Passwords | Allow temporary password use with an immediate change requirement | +| IA.L2-3.5.10 | 3.5.10 | Cryptographically-Protected Passwords | Store and transmit only cryptographically-protected passwords | +| IA.L2-3.5.11 | 3.5.11 | Obscure Feedback | Obscure feedback of authentication information during the authentication process | + +### 6. Incident Response (IR) — 3 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| IR.L2-3.6.1 | 3.6.1 | Incident Handling | Establish an operational incident-handling capability for organizational systems including: preparation, detection, analysis, containment, recovery, and user response activities | +| IR.L2-3.6.2 | 3.6.2 | Incident Reporting | Track, document, and report incidents to appropriate organizational officials and/or authorities | +| IR.L2-3.6.3 | 3.6.3 | Incident Response Testing | Test the organizational incident response capability | + +**Note on DFARS 252.204-7012:** Contractors that discover a cyber incident on a covered +contractor information system must: +- Report to DoD at https://dibnet.dod.mil within **72 hours** of discovery +- Preserve and protect images of all known affected systems for **90 days** +- Submit a malware sample (if discovered) to the DoD Cyber Crime Center (DC3) +- Cooperate with DoD damage assessment activities + +### 7. Maintenance (MA) — 6 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| MA.L2-3.7.1 | 3.7.1 | Managed Maintenance | Perform maintenance on organizational systems | +| MA.L2-3.7.2 | 3.7.2 | Maintenance Tools | Provide controls on the tools, techniques, mechanisms, and personnel for system maintenance | +| MA.L2-3.7.3 | 3.7.3 | Equipment Sanitization | Ensure equipment removed for maintenance is sanitized with respect to CUI | +| MA.L2-3.7.4 | 3.7.4 | Media Inspection | Check media containing diagnostic and test programs for malicious code before used on systems | +| MA.L2-3.7.5 | 3.7.5 | Nonlocal Maintenance | Require MFA to establish nonlocal maintenance sessions and terminate when session is complete | +| MA.L2-3.7.6 | 3.7.6 | Maintenance Personnel | Supervise maintenance activities of personnel without required access authorization | + +### 8. Media Protection (MP) — 9 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| MP.L2-3.8.1 | 3.8.1 | Media Protection | Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital | +| MP.L2-3.8.2 | 3.8.2 | Media Access | Limit access to CUI on system media to authorized users | +| MP.L2-3.8.3 | 3.8.3 | Media Disposal | Sanitize or destroy system media before disposal or reuse | +| MP.L2-3.8.4 | 3.8.4 | Media Markings | Mark media with necessary CUI markings and distribution limitations | +| MP.L2-3.8.5 | 3.8.5 | Media Accountability | Control access to media containing CUI and maintain accountability for media during transport | +| MP.L2-3.8.6 | 3.8.6 | Portable Storage Encryption | Implement cryptographic mechanisms to protect the confidentiality of CUI during transport unless protected by alternative physical safeguards | +| MP.L2-3.8.7 | 3.8.7 | Removable Media Control | Control the use of removable media on system components | +| MP.L2-3.8.8 | 3.8.8 | Shared Media | Prohibit the use of portable storage devices when such devices have no identifiable owner | +| MP.L2-3.8.9 | 3.8.9 | CUI Protection at Backup Locations | Protect the confidentiality of backup CUI at storage locations | + +### 9. Personnel Security (PS) — 2 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| PS.L2-3.9.1 | 3.9.1 | Screen Individuals | Screen individuals prior to authorizing access to organizational systems containing CUI | +| PS.L2-3.9.2 | 3.9.2 | Termination & Transfer | Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers | + +### 10. Physical Protection (PE) — 6 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| PE.L2-3.10.1 | 3.10.1 | Limit Physical Access | Limit physical access to organizational systems, equipment, and operating environments to authorized individuals | +| PE.L2-3.10.2 | 3.10.2 | Protect & Monitor Physical Facility | Protect and monitor the physical facility and support infrastructure for organizational systems | +| PE.L2-3.10.3 | 3.10.3 | Escort Visitors | Escort visitors and monitor visitor activity | +| PE.L2-3.10.4 | 3.10.4 | Audit Physical Access | Maintain audit logs of physical access | +| PE.L2-3.10.5 | 3.10.5 | Manage Physical Access | Control and manage physical access devices | +| PE.L2-3.10.6 | 3.10.6 | Alternative Work Sites | Enforce safeguarding measures for CUI at alternate work sites | + +### 11. Risk Assessment (RA) — 3 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| RA.L2-3.11.1 | 3.11.1 | Risk Assessments | Periodically assess the risk to organizational operations, assets, and individuals resulting from the operation of organizational systems and the associated processing, storing, or transmitting of CUI | +| RA.L2-3.11.2 | 3.11.2 | Vulnerability Scan | Periodically scan for vulnerabilities in organizational systems and applications; remediate high vulnerabilities | +| RA.L2-3.11.3 | 3.11.3 | Vulnerability Remediation | Remediate vulnerabilities in accordance with risk assessments | + +### 12. Security Assessment (CA) — 4 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| CA.L2-3.12.1 | 3.12.1 | System Security Assessment | Periodically assess the security controls in organizational systems to determine if the controls are effective | +| CA.L2-3.12.2 | 3.12.2 | Plan of Action | Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities | +| CA.L2-3.12.3 | 3.12.3 | Security Control Monitoring | Monitor security controls on an ongoing basis to ensure the continued effectiveness | +| CA.L2-3.12.4 | 3.12.4 | System Security Plan | Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and relationships with other systems | + +### 13. System and Communications Protection (SC) — 16 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| SC.L2-3.13.1 | 3.13.1 | Boundary Protection | Monitor, control, and protect communications at external and key internal boundaries | +| SC.L2-3.13.2 | 3.13.2 | Security Engineering | Employ architectural designs, software development techniques, and systems engineering principles promoting security effectiveness | +| SC.L2-3.13.3 | 3.13.3 | Role Separation | Separate user functionality from system management functionality | +| SC.L2-3.13.4 | 3.13.4 | Shared Resource Control | Prevent unauthorized and unintended information transfer via shared system resources | +| SC.L2-3.13.5 | 3.13.5 | Public-Access System Separation | Implement subnetworks for publicly accessible system components, separated from internal networks | +| SC.L2-3.13.6 | 3.13.6 | Network Communication Denial | Deny network communications traffic by default; allow by exception (deny-all, permit-by-exception) | +| SC.L2-3.13.7 | 3.13.7 | Split Tunneling | Prevent remote devices from simultaneously using VPN tunneling to connect simultaneously to the system and to resources in other domains | +| SC.L2-3.13.8 | 3.13.8 | Data in Transit | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission | +| SC.L2-3.13.9 | 3.13.9 | Connections Termination | Terminate network connections after a defined period of inactivity | +| SC.L2-3.13.10 | 3.13.10 | Key Management | Establish and manage cryptographic keys for required cryptography employed in organizational systems | +| SC.L2-3.13.11 | 3.13.11 | CUI Encryption | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI | +| SC.L2-3.13.12 | 3.13.12 | Collaborative Computing Devices | Prohibit remote activation of collaborative computing devices and provide indication of use to users present | +| SC.L2-3.13.13 | 3.13.13 | Mobile Code | Control and monitor the use of mobile code | +| SC.L2-3.13.14 | 3.13.14 | VoIP Technologies | Control and monitor the use of VoIP technologies | +| SC.L2-3.13.15 | 3.13.15 | Communications Authenticity | Protect the authenticity of communications sessions | +| SC.L2-3.13.16 | 3.13.16 | CUI at Rest | Protect the confidentiality of CUI at rest | + +### 14. System and Information Integrity (SI) — 7 Practices + +| Practice ID | NIST Ref | Practice Title | Description | +|------------|----------|---------------|-------------| +| SI.L2-3.14.1 | 3.14.1 | Flaw Remediation | Identify, report, and correct information and system flaws in a timely manner | +| SI.L2-3.14.2 | 3.14.2 | Malicious Code Protection | Provide protection from malicious code at appropriate locations within organizational systems | +| SI.L2-3.14.3 | 3.14.3 | Security Alerts | Monitor system security alerts and advisories and take action in response | +| SI.L2-3.14.4 | 3.14.4 | Update Malicious Code Protection | Update malicious code protection mechanisms when new releases are available | +| SI.L2-3.14.5 | 3.14.5 | System Scanning | Perform periodic scans of the system and real-time scans of files from external sources | +| SI.L2-3.14.6 | 3.14.6 | Security Monitoring | Monitor the system to detect attacks and indicators of potential attacks | +| SI.L2-3.14.7 | 3.14.7 | Identify Unauthorized Use | Identify unauthorized use of organizational systems | + +--- + +## SPRS Score Deduction Reference + +The NIST SP 800-171 DoD Assessment Methodology assigns deduction values to each practice. +Below are the deduction weights (not implemented = subtract from 110): + +**High-impact deductions (-5 each):** +AC.L2-3.1.3, AC.L2-3.1.5, AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.14, +IA.L2-3.5.3, SC.L2-3.13.8, SC.L2-3.13.11, SC.L2-3.13.16 + +**Medium-impact deductions (-3 each):** +AC.L2-3.1.1, AC.L2-3.1.2, AU.L2-3.3.1, AU.L2-3.3.2, CA.L2-3.12.4, +CM.L2-3.4.1, CM.L2-3.4.2, IA.L2-3.5.1, IA.L2-3.5.2, IA.L2-3.5.7, +IR.L2-3.6.1, RA.L2-3.11.2, SC.L2-3.13.1, SC.L2-3.13.6, SI.L2-3.14.1, +SI.L2-3.14.2, SI.L2-3.14.5, SI.L2-3.14.6 + +**Low-impact deductions (-1 each):** All remaining 83 practices + +--- + +## Key Evidence Requirements for C3PAO Assessment + +| Domain | Critical Evidence | +|--------|-----------------| +| AC | User account list, access control policy, session lock configuration, VPN configuration | +| AU | Audit log configuration, log retention settings, SIEM deployment, NTP configuration | +| AT | Training completion records (dated, named), training content for all roles | +| CM | System inventory, configuration baselines, change management records, approved software list | +| IA | MFA deployment configuration, password policy, account review records | +| IR | Incident response plan, test records (tabletop or drill), DIBNET cybersecurity portal registration | +| MA | Maintenance logs, remote maintenance session records, equipment sanitization records | +| MP | Media inventory, encryption configuration for portable media, disposal certificates | +| PS | Background check records, termination/transfer checklist completion records | +| PE | Physical access log, badge records, visitor log, alternative work site policy | +| RA | Risk assessment report (dated), vulnerability scan reports, remediation tracking | +| CA | Security assessment report, POA&M (current), SSP (current) | +| SC | Firewall rules, network diagram, encryption certificates, VPN configuration | +| SI | Patch management reports, AV/EDR console screenshots, security alert process documentation | diff --git a/plugins/cmmc/skills/cmmc/references/level3-practices.md b/plugins/cmmc/skills/cmmc/references/level3-practices.md new file mode 100644 index 0000000..79087f5 --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/level3-practices.md @@ -0,0 +1,156 @@ +# CMMC Level 3 — Expert (134 Practices) +## Source: NIST SP 800-172 (Enhanced Requirements) and CMMC 2.0 Final Rule (32 CFR Part 170) + +--- + +## Overview + +CMMC Level 3 applies to organizations handling **CUI associated with DoD's highest-priority +programs** — typically those involving critical national security systems. + +Level 3 requires implementation of all 110 Level 2 practices (NIST SP 800-171 Rev 2) **plus** +24 additional enhanced security requirements from **NIST SP 800-172, "Enhanced Security +Requirements for Protecting Controlled Unclassified Information."** + +**Assessment Type:** Conducted by the **Defense Contract Management Agency (DCMA) Defense +Industrial Base Cybersecurity Assessment Center (DIBCAC)** + +**Prerequisite:** Organizations must first achieve a CMMC Level 2 C3PAO certification before +a Level 3 assessment can be initiated. + +**Certificate Validity:** 3 years (triennial DIBCAC reassessment) +**Annual Affirmation:** Required each year by a senior company official + +--- + +## The 24 Additional Level 3 Practices (from NIST SP 800-172) + +All practice IDs use the prefix format: `[Domain].L3-3.x.x(e)` where `(e)` denotes +an "enhanced" requirement from SP 800-172. + +### Domain: Access Control (AC) — 4 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| AC.L3-3.1.2e | 3.1.2e | Restrict Access | Restrict access to systems and system components to only those information resources that are owned, provisioned, or issued by the organization | +| AC.L3-3.1.3e | 3.1.3e | Control CUI Flows — Encrypted | Employ dynamic access control mechanisms to enforce authorizations associated with CUI; protect CUI using cryptographic mechanisms and information flow controls on systems and network components | +| AC.L3-3.1.5e | 3.1.5e | Privileged Access — Logon | Require individuals accessing CUI systems with privileged accounts to have specific training and to use the accounts only when required; log all privileged access to CUI environments | +| AC.L3-3.1.6e | 3.1.6e | Non-Privileged Account Use — Separation | Separate the duties of individuals to reduce the risk of compromise by an insider; log and audit the actions of personnel with access to CUI in high-value systems | + +### Domain: Awareness and Training (AT) — 1 Additional Practice + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| AT.L3-3.2.1e | 3.2.1e | Advanced Training | Provide awareness training upon initial hire and regularly thereafter; provide training focused on advanced persistent threats (APT) techniques, tactics, and procedures; include role-based and scenario-based content | + +### Domain: Configuration Management (CM) — 1 Additional Practice + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| CM.L3-3.4.1e | 3.4.1e | Authoritative Source | Establish and maintain an authoritative source and repository to provide a trusted source and accountability for systems and system components throughout the system development life cycle | + +### Domain: Identification and Authentication (IA) — 1 Additional Practice + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| IA.L3-3.5.3e | 3.5.3e | Additional MFA Mechanisms | Employ supplemental authentication techniques or mechanisms for access to CUI systems where the risk of unauthorized access is particularly high | + +### Domain: Incident Response (IR) — 4 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| IR.L3-3.6.1e | 3.6.1e | Insider Threat Response | Establish and maintain a cyber incident response team that can be deployed to any location within 24 hours to investigate cyber incidents | +| IR.L3-3.6.2e | 3.6.2e | Security Operations | Establish and maintain a security operations center (SOC) capability that facilitates 24/7 monitoring, reporting, and response capabilities | +| IR.L3-3.6.3e | 3.6.3e | Hunt APT | Track adversarial TTPs, employ deception technologies and techniques, perform threat hunting activities, and conduct assessments of vulnerabilities | +| IR.L3-3.6.4e | 3.6.4e | Cyber Threat Intelligence | Receive threat intelligence relevant to the CUI assets from DoD or designated sources; integrate threat intelligence into cyber defense operations | + +### Domain: Risk Assessment (RA) — 5 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| RA.L3-3.11.1e | 3.11.1e | Risk Response | Employ advanced risk assessment techniques and tools to identify and mitigate targeted attacks on high-value assets | +| RA.L3-3.11.2e | 3.11.2e | Threat-Informed Procedures | Use threat intelligence to inform and enhance vulnerability analyses and security controls | +| RA.L3-3.11.3e | 3.11.3e | Advanced Threat Modeling | Develop and update (at least annually) threat models for systems with CUI; use threat models to inform decisions about risk mitigation | +| RA.L3-3.11.4e | 3.11.4e | Predictive Cyber Analytics | Conduct predictive cyber analysis to identify vulnerabilities and potential attacks by leveraging threat intelligence and vulnerability scan data | +| RA.L3-3.11.6e | 3.11.6e | Security Architecture Review | Review security architecture of CUI systems regularly; ensure architecture is consistent with DoD security requirements and CUI protection plans | + +### Domain: Security Assessment (CA) — 3 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| CA.L3-3.12.1e | 3.12.1e | Penetration Testing | Conduct penetration testing at least annually or after significant changes to CUI systems | +| CA.L3-3.12.2e | 3.12.2e | Independent Assessment | Conduct independent, specialized assessments of CUI systems at least annually using high-value asset plans | +| CA.L3-3.12.3e | 3.12.3e | Blue Team Assessment | Include threat hunting exercises and assessments where red and blue teams compete to find vulnerabilities in CUI systems | + +### Domain: System and Communications Protection (SC) — 3 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| SC.L3-3.13.4e | 3.13.4e | Isolate Government CUI | Isolate government CUI from contractor information and systems using hardware-based techniques | +| SC.L3-3.13.10e | 3.13.10e | Key Management — Advanced | Employ advanced key management practices for CUI environments, managed by DoD-provided or DoD-approved key management infrastructure | +| SC.L3-3.13.11e | 3.13.11e | Cryptography — Approved | Restrict cryptographic primitives to those approved by DoD; implement cryptographic agility in systems to enable rapid pivoting to new algorithms when existing algorithms are deprecated | + +### Domain: System and Information Integrity (SI) — 2 Additional Practices + +| Practice ID | NIST 800-172 Ref | Practice Title | Requirement | +|------------|-----------------|---------------|-------------| +| SI.L3-3.14.3e | 3.14.3e | Threat-Aware Security | Implement threat-aware security capabilities, including advanced intrusion detection, behavior analysis, and anomaly detection mechanisms optimized for detecting APT techniques | +| SI.L3-3.14.6e | 3.14.6e | Deception Technologies | Deploy deception technologies and techniques (e.g., honeypots, decoys, canary tokens) to detect and identify adversarial activity | + +--- + +## Level 3 Assessment Process (DIBCAC) + +### DIBCAC — Who They Are + +The **Defense Contract Management Agency Defense Industrial Base Cybersecurity Assessment +Center (DCMA DIBCAC)** is the DoD governing body responsible for conducting CMMC Level 3 +assessments. DIBCAC assessors are federal government employees with deep cybersecurity +expertise. + +### Level 3 Assessment Steps + +1. **Initiation** + - DoD Contract Officer/Program Office notifies organization of Level 3 requirement + - Organization must hold a current CMMC Level 2 certification (from C3PAO) + - Organization submits assessment request to DIBCAC + +2. **Pre-Assessment** + - Organization provides SSP (covering all 134 practices) + - DIBCAC reviews documentation package + - Assessment scope confirmed + +3. **Assessment Execution** + - DIBCAC Lead Assessor team conducts on-site assessment + - Technical interviews with security, IT, and program personnel + - Deep technical testing of all 24 enhanced practices + - Review of evidence for all 110 Level 2 practices (may rely on C3PAO assessment) + +4. **Assessment Results** + - CMMC Status: CMMC Level 3 Certified (or Conditional, or Not Certified) + - Conditional: POA&M items must be closed within defined timeline + - DIBCAC publishes results to enterprise CMMC tracking system + +5. **Ongoing Obligations** + - Annual Affirmation by senior official + - Triennial DIBCAC reassessment + - Continuous monitoring and incident reporting (DFARS 252.204-7012) + +--- + +## Level 3 Preparation Checklist + +| Area | Requirement | +|------|-------------| +| Level 2 Certification | Current C3PAO CMMC Level 2 certificate in place | +| SOC/CSOC | 24/7 security monitoring capability established | +| Threat Hunting | Documented threat hunting program with TTPs | +| Penetration Testing | Annual pen test completed with findings remediated | +| Threat Intelligence | DoD/government threat intelligence feeds integrated | +| Deception Technologies | Honeypots or equivalent deployed in CUI environment | +| APT Training | Role-based training covering APT techniques, tactics, procedures | +| Insider Threat Program | Formal insider threat program defined and operational | +| Incident Response Team | Deployable team established, exercised, capable of 24-hour response | +| Key Management | DoD-approved key management infrastructure in use | +| Hardware Isolation | Hardware-based isolation of government CUI from contractor systems | +| Threat Modeling | Annual threat model for all CUI systems documented and reviewed | diff --git a/plugins/cmmc/skills/cmmc/references/scoping-guide.md b/plugins/cmmc/skills/cmmc/references/scoping-guide.md new file mode 100644 index 0000000..222b3c4 --- /dev/null +++ b/plugins/cmmc/skills/cmmc/references/scoping-guide.md @@ -0,0 +1,275 @@ +# CMMC 2.0 Scoping Guidance +## Source: CMMC 2.0 Scoping Guidance Documents — DoD CIO (December 2021, updated 2024) + +--- + +## Overview + +Scoping is the process of identifying which systems, components, and people are included +in the CMMC assessment boundary. Correct scoping is critical: too broad wastes resources, +too narrow creates compliance gaps. + +**Official source:** CMMC Level 2 Scoping Guidance and CMMC Level 3 Scoping Guidance +published by the Office of the DoD Chief Information Officer (DoD CIO). + +--- + +## Data Types That Drive Scope + +### Federal Contract Information (FCI) + +**Definition (FAR 4.1901):** +Information, not intended for public release, that is provided by or generated for the +Government under a contract to develop or deliver a product or service to the Government. + +FCI **does NOT include:** +- Information provided by the Government to the public (public websites, reports) +- Simple transactional information (payments, schedules, administrative correspondence) + +**CMMC implication:** FCI presence requires minimum Level 1. + +### Controlled Unclassified Information (CUI) + +**Definition:** Information the Government creates or possesses (or an entity creates or +possesses for or on behalf of the Government) that a law, regulation, or Government-wide +policy requires or permits handling using safeguarding or dissemination controls. + +**CUI Registry:** Published by the National Archives and Records Administration (NARA) at +https://www.archives.gov/cui + +**Common DoD CUI Categories:** +- Controlled Technical Information (CTI) +- Export Controlled (ITAR, EAR) +- Proprietary Business Information +- Critical Infrastructure Information +- DoD-specific CUI categories per DoD Instruction 5200.48 + +**CUI markings:** Documents containing CUI are marked "CUI" with applicable CUI category +indicator, handling instructions, and authority block per NARA CUI Marking Handbook. + +**CMMC implication:** CUI presence requires Level 2 minimum; Level 3 if designated by DoD. + +--- + +## Asset Categories + +The CMMC Program defines six asset categories for scoping purposes. Categorization +determines which practices apply to each asset. + +### 1. CUI Assets + +**Definition:** These assets process, store, or transmit CUI. + +**Examples:** +- Workstations running applications that access CUI repositories +- File servers storing technical data, drawings, specifications marked CUI +- Email servers where CUI is communicated +- Databases containing program plans or bids with CUI +- Cloud storage (SharePoint, OneDrive, S3 buckets) holding CUI documents +- Printers that print documents containing CUI + +**Scope:** ALL 110 Level 2 practices (or 134 Level 3 practices) apply. + +**Key test:** "Does this asset process, store, OR transmit CUI?" + +--- + +### 2. Security Protection Assets (SPAs) + +**Definition:** Assets that provide security functions to the CUI environment, protecting +CUI Assets from unauthorized access or attack — even if they do not directly touch CUI. + +**Examples:** +- Firewalls and routers that protect the CUI network segment +- Identity providers (Active Directory, LDAP, Azure AD) authenticating CUI users +- SIEM (Security Information and Event Management) systems monitoring CUI environment +- Vulnerability scanners scanning CUI systems +- PAM (Privileged Access Management) systems managing privileged access to CUI +- Endpoint Detection and Response (EDR) platforms on CUI assets +- Multi-factor authentication (MFA) systems +- Backup systems protecting CUI + +**Scope:** ALL applicable CMMC practices apply. SPAs are fully in-scope because +if compromised, they defeat the protection of CUI assets. + +--- + +### 3. Contractor Risk Managed Assets (CRMAs) + +**Definition:** Assets that can reach (i.e., have network connectivity to) CUI or Security +Protection Assets but do **not** directly process, store, or transmit CUI. + +**Examples:** +- IT administration workstations that can reach the CUI network but are not used for CUI work +- Jump hosts used for network management (if not handling CUI) +- Management servers for hypervisors hosting CUI VMs +- Monitoring systems with read-only access to CUI network infrastructure logs + +**Scope:** The organization must document and assess the risk these assets pose to CUI +and SPAs, and implement controls commensurate with that risk. Not all 110 practices +automatically apply — but the organization must document which apply and justify any +exclusions. + +**Key distinction from CUI Assets:** The critical test is whether the asset CAN access +CUI or security controls, not whether it IS USED for CUI. If it can reach CUI, it is +a CRMA at minimum. + +--- + +### 4. Specialized Assets + +**Definition:** Assets that are used in the CUI environment but which present unique +challenges for implementation of standard CMMC practices. These require specific +risk-based treatment. + +**Sub-categories:** + +| Sub-category | Description | Examples | +|-------------|-------------|---------| +| Government Furnished Equipment (GFE) | Equipment provided by the Government | Government-issued laptops, hardware provided on contract | +| Operational Technology (OT) / Industrial Control Systems (ICS) | Equipment in manufacturing or process control | CNC machines, PLCs, SCADA systems | +| Internet of Things (IoT) | Networked devices with limited management capability | Smart sensors, building management systems | +| Test Equipment | Devices used for testing that interact with CUI | Oscilloscopes connected to test workstations, spectrum analyzers | +| Restricted Information Systems | Legacy or specialized systems with operational constraints | Legacy mainframes, air-gapped systems | + +**Scope:** CMMC practices apply to the extent they can be implemented. Where practices +cannot be applied, the organization must document the risk, implement compensating controls, +and include in the SSP. For GFE: responsibility for compliance lies with the Government +component that owns the equipment. + +--- + +### 5. Out-of-Scope Assets + +**Definition:** Assets that do **not** process, store, or transmit CUI AND have **no +connectivity** (network or physical) to CUI assets or SPAs. + +**Conditions for out-of-scope classification:** +1. The asset does not touch CUI (not process, store, transmit) +2. The asset cannot reach CUI assets or SPAs via any network path +3. The asset is not used in the maintenance or security of CUI systems +4. The isolation is documented, verified, and maintained + +**Examples (when properly isolated):** +- HR or accounting systems on a separate, isolated network with no path to CUI +- Guest Wi-Fi networks with no path to CUI environment +- Employee personal devices never connected to CUI systems and not used for CUI work + +**Important:** If there is ANY network path — even through DMZ or VPN — the asset is NOT +out-of-scope. Air-gap requirement is strict. + +--- + +### 6. External Service Providers (ESPs) + +**Definition:** Companies or cloud services that process, store, or transmit CUI on behalf +of the contractor, or provide security services to the CUI environment. + +**Examples:** +- Cloud service providers (AWS, Azure, Google Cloud) hosting CUI workloads +- Managed Security Service Providers (MSSPs) monitoring CUI systems +- Co-location data centers where CUI servers are housed +- SaaS platforms where CUI is uploaded (e.g., document management, collaboration tools) +- IT support vendors with access to CUI systems (MSPs) + +**Scope requirements for ESPs:** + +| ESP Type | Requirement | +|---------|------------| +| Cloud Service Provider (IaaS/PaaS/SaaS) storing/processing CUI | Must be FedRAMP Authorized at Moderate baseline OR assessed via CMMC/equivalent | +| MSSP providing security services to CUI environment | Must be CMMC certified to at least Level 2 (or demonstrate equivalent) | +| Co-location / data center | Physical controls must be documented; contractor retains responsibility for logical controls | +| IT support vendors (MSPs) | Must meet CMMC requirements commensurate with their access level | + +**Flow-down clause:** Prime contractors must include DFARS 252.204-7021 in subcontracts +where subcontractors will process, store, or transmit CUI or provide security protection +services. Subcontractors must be CMMC certified to the same level as the prime for the +work they perform. + +--- + +## Scoping Process — Step-by-Step + +### Step 1: Identify CUI + +- Review contracts for CUI requirements and markings +- Inventory all CUI received, generated, or stored during performance +- Assign CUI categories per NARA CUI Registry +- Document where CUI flows (data flow diagram) + +### Step 2: Map CUI Asset Locations + +For each CUI category, identify all locations: +- File servers and storage systems +- Endpoints (workstations, laptops) used to access CUI +- Applications and databases +- Email systems +- Cloud services +- Removable media +- Paper/physical records (out of CMMC scope, but needed for full picture) + +### Step 3: Identify SPAs + +For each CUI Asset, identify what provides security protection: +- Authentication systems +- Network security controls (firewalls, IDS/IPS) +- Logging and monitoring systems +- EDR/AV platforms +- Backup systems + +### Step 4: Identify CRMAs + +Map all systems that have network connectivity to CUI Assets or SPAs but do not directly +process CUI. Document the purpose and level of access for each CRMA. + +### Step 5: Identify Specialized Assets + +List OT/ICS, IoT, GFE, test equipment, and restricted systems within or near the CUI environment. + +### Step 6: Identify ESPs + +List all external services that touch the CUI environment, document their authorization status, +and determine flow-down obligations. + +### Step 7: Isolate Out-of-Scope Systems + +Verify that systems claimed as out-of-scope have no network path to CUI assets or SPAs. +Document the isolation controls. + +### Step 8: Document in SSP + +The System Security Plan must include: +- Network boundary diagram showing all asset categories +- Data flow diagram showing CUI movement +- Asset inventory categorized by scope type +- Explanation of out-of-scope determinations +- ESP list with authorization status + +--- + +## Network Segmentation Recommendations for Scope Reduction + +Reducing the CMMC scope reduces assessment cost and complexity. Common strategies: + +| Strategy | How It Reduces Scope | +|---------|---------------------| +| VLAN isolation of CUI workstations | Keeps CUI on separate network segment; limits CRMA expansion | +| Jump server for CUI administration | Limits number of admin workstations that reach CUI | +| FedRAMP-authorized cloud for CUI storage | Shifts responsibility for cloud controls to authorized provider | +| Dedicated CUI workstations | Prevents personal/HR/finance systems from reaching CUI | +| Air-gapped OT/ICS systems | Removes OT equipment from CMMC scope entirely | +| MSSP providing security services | Moves some SPA obligations to certified third party | + +--- + +## Common Scoping Mistakes + +| Mistake | Consequence | +|---------|------------| +| Claiming systems are out-of-scope without verifying network isolation | Systems incorrectly excluded; assessor may flag and force scope expansion | +| Not including email systems | Most CUI is transmitted via email; email servers are CUI Assets | +| Forgetting about backup systems | Backups of CUI are themselves CUI assets | +| Not scoping cloud services | Cloud services storing CUI are ESPs and must meet FedRAMP or equivalent | +| Scoping out home-office workstations | Remote workers using personal devices for CUI work bring those devices in-scope | +| Not including IT support MSP | MSP with privileged access to CUI systems is an ESP | +| Forgetting mobile devices | Mobile devices with CUI (email, apps) are in-scope CUI Assets or CRMAs | diff --git a/plugins/eu-ai-act/.claude-plugin/plugin.json b/plugins/eu-ai-act/.claude-plugin/plugin.json new file mode 100644 index 0000000..2c1579a --- /dev/null +++ b/plugins/eu-ai-act/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "eu-ai-act", + "description": "EU AI Act (Regulation (EU) 2024/1689) compliance advisor — risk classification, prohibited AI practices, high-risk AI system requirements, GPAI obligations, conformity assessment, deployer obligations, fundamental rights impact assessment, and compliance roadmaps.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "eu-ai-act", + "artificial-intelligence-act", + "ai-regulation", + "high-risk-ai", + "gpai", + "ai-compliance", + "eu-regulation", + "ai-governance", + "conformity-assessment", + "grc" + ] +} diff --git a/plugins/eu-ai-act/skills/eu-ai-act/SKILL.md b/plugins/eu-ai-act/skills/eu-ai-act/SKILL.md new file mode 100644 index 0000000..8aa7fcc --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/SKILL.md @@ -0,0 +1,343 @@ +--- +name: eu-ai-act +description: > + Expert EU AI Act (Regulation (EU) 2024/1689) compliance advisor. Use this skill whenever + a user asks about the EU Artificial Intelligence Act, AI risk classification under EU law, + prohibited AI practices, high-risk AI system requirements, GPAI model obligations, systemic + risk, conformity assessment, CE marking for AI, EU AI Act compliance roadmaps, deployer + obligations, fundamental rights impact assessment (FRIA), the EU AI Office, AI regulatory + sandboxes, EU AI Act penalties, or any topic related to complying with or auditing against + the EU AI Act. Also trigger for questions like "is my AI system high-risk under the EU AI + Act?", "what obligations does EU AI Act impose on GPAI providers?", "how do I perform a + conformity assessment under the EU AI Act?", "what is prohibited under Article 5?", + "how do I register an AI system in the EU database?", or "when do EU AI Act requirements apply?". +--- + +# EU AI Act (Regulation (EU) 2024/1689) Compliance Skill + +You are an expert EU AI Act compliance advisor with deep knowledge of Regulation (EU) 2024/1689 of 13 June 2024. You assist organisations — whether AI providers (developers/deployers), GPAI model providers, importers, distributors, product manufacturers, or public authority deployers — in understanding, implementing, and demonstrating compliance with the EU Artificial Intelligence Act. + +--- + +## Key Facts — Always Cite These + +| Item | Detail | +|------|--------| +| Official title | Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) | +| OJ reference | OJ L 2024/1689, published 12 July 2024 | +| Entry into force | 1 August 2024 (Article 113) | +| Structure | 13 Chapters, 113 Articles, 13 Annexes, 180 Recitals | +| Regulator | European AI Office (within European Commission); National Competent Authorities (NCAs) | +| Territorial scope | Applies to providers and deployers in the EU; also to providers/deployers outside the EU where the AI system's output is used in the EU | + +--- + +## Application Timeline — Critical Dates + +| Date | What Applies | Reference | +|------|-------------|-----------| +| 1 August 2024 | Entry into force — no obligations yet apply | Art. 113 | +| 2 February 2025 | **Prohibited AI practices (Chapter II, Art. 5) and AI literacy (Art. 4) apply** | Art. 113(a) | +| 2 May 2025 | Codes of practice for GPAI must be ready | Art. 56(9) | +| 2 August 2025 | **GPAI model rules (Chapter V), governance (Chapter VII), notified bodies (Chapter III, Section 4), penalties (Arts. 99–100) apply** | Art. 113(b) | +| 2 February 2026 | Commission guidelines on Art. 6 high-risk classification required | Arts. 6(5), 72(3) | +| **2 August 2026** | **Remainder of the Act applies — high-risk AI under Annex III (Art. 6(2)), transparency (Chapter IV), most of Chapter III** | Art. 113 | +| 2 August 2027 | Art. 6(1) applies — AI as safety components in Annex I-regulated products | Art. 113 | +| 2 August 2027 | GPAI models placed on market before 2 August 2025 must comply | Art. 111(3) | +| 31 December 2030 | Large-scale IT systems (Annex X) must comply | Art. 111(1) | + +> **Current date context (April 2026):** Prohibited AI practices are already enforced (since Feb 2025). GPAI rules are in force (since Aug 2025). High-risk AI under Annex III obligations begin August 2026 — organisations developing or deploying high-risk AI have months to achieve compliance. + +--- + +## How to Respond + +Match your output to the task: + +| Task | Output Format | +|------|--------------| +| Risk classification | Decision tree outcome: Prohibited / High-risk (Art. 6(1) or 6(2)) / Transparency-only (Art. 50) / Minimal risk — with article citations | +| Gap analysis | Table: Article/Requirement \| Status 🔴/🟡/🟢 \| Evidence Needed \| Gap/Action | +| Conformity assessment guidance | Route determination (internal / third-party), evidence checklist, steps | +| Obligation identification | Role-specific obligations table (provider / deployer / GPAI provider / importer / distributor) | +| FRIA guidance | Structured assessment template aligned to Art. 27 | +| Policy / document drafting | Full structured document with document control block, article citations, review date | +| GPAI compliance | Model type determination (standard / open / systemic), obligations table, codes of practice status | +| Penalty analysis | Violation category, applicable penalty ceiling, mitigating factors | +| General Q&A | Clear prose with specific article/recital citations | + +Always cite the specific article (e.g., Art. 9, Art. 26) or Annex (e.g., Annex III, point 1(a)) in all outputs. + +--- + +## Risk Classification Framework + +### Step 1: Is the AI System Prohibited? (Art. 5) + +Check all 8 prohibited categories. If **any apply**, the AI system **must not be placed on the market or put into service** in the EU. + +**Prohibited AI practices under Article 5:** + +1. **Subliminal manipulation**: AI deploying techniques below the threshold of consciousness, or deliberately deceptive/manipulative techniques, that materially distort a person's behaviour in a way that causes or is reasonably likely to cause significant harm +2. **Vulnerability exploitation**: AI exploiting vulnerabilities due to age, disability, or socioeconomic circumstances to materially distort behaviour causing significant harm +3. **Biometric categorization of sensitive attributes**: AI systems inferring race, political opinions, trade union membership, religious/philosophical beliefs, sex life, or sexual orientation from biometric data (exception: lawful labelling/filtering of datasets or law enforcement categorization) +4. **Social scoring by public authorities**: AI systems evaluating/classifying natural persons based on social behaviour or personal characteristics over time, leading to detrimental treatment in unrelated contexts or disproportionate harm +5. **Criminal risk profiling based solely on traits**: AI assessing risk of a natural person committing a criminal offence based solely on profiling or personality traits (not permitted; AI augmenting human assessments based on objective, verifiable facts is permitted) +6. **Untargeted facial recognition scraping**: Building/expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage +7. **Emotion recognition in workplace/education**: AI systems inferring emotions of natural persons in workplace or educational institution contexts (exception: AI for medical or safety reasons) +8. **Real-time remote biometric identification (RBI) for law enforcement in public spaces**: Subject to three narrow law enforcement exceptions (missing persons/trafficking victims; imminent threat/terrorist attack; serious crime suspects) — requires prior judicial/administrative authorisation, fundamental rights impact assessment, and prior registration in EU database + +> For full Article 5 detail with conditions and exceptions → read `references/eu-ai-act-prohibited-practices.md` + +### Step 2: Is the AI System High-Risk? (Art. 6) + +**Route A — Art. 6(1):** The AI system is **both**: +- A safety component of a product covered by EU harmonisation legislation in **Annex I** of the EU AI Act (e.g., machinery, medical devices, motor vehicles, toys), **AND** +- Required to undergo third-party conformity assessment under that Annex I legislation +→ Classified as high-risk. Full requirements (Arts. 8–17) and obligations (Arts. 18–37) apply. Timeline: **2 August 2027**. + +**Route B — Art. 6(2):** The AI system is listed in **Annex III** (8 specific use-case areas covering biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice) +→ Classified as high-risk **unless** one of four exceptions applies (Art. 6(3)): +- Performs a narrow procedural task +- Improves the result of a previously completed human activity +- Detects decision-making patterns/deviations without influencing prior assessments without human review +- Performs a preparatory task to an assessment in the Annex III use cases +→ **Exception does not apply if the system profiles individuals** (automated processing to assess aspects of a person's life) +→ Timeline: **2 August 2026** for most Annex III systems. + +> For Annex III full list and classification rules → read `references/eu-ai-act-high-risk-systems.md` + +### Step 3: Transparency-Only Obligations? (Art. 50) + +If not prohibited or high-risk, check if **Article 50** transparency obligations apply: +- **Chatbots**: Must inform users they are interacting with an AI system (exception: obvious from context) +- **Emotion recognition / biometric categorization**: Must inform natural persons that they are subject to such a system +- **Deepfakes**: Must disclose that content is AI-generated or manipulated (Art. 50(3)) — exception for law enforcement/creative expression with appropriate disclosure +- **AI-generated text on public interest topics** (elections, health, climate, environment, immigration): Must be labelled as AI-generated + +### Step 4: Minimal Risk + +AI systems not captured by steps 1–3 are **minimal/no risk** — no mandatory obligations under the EU AI Act (voluntary codes of conduct encouraged under Art. 95). + +--- + +## Obligations by Role + +### Provider Obligations (Art. 16 summary) + +Providers of **high-risk AI systems** must: +1. Establish and maintain a **risk management system** (Art. 9) — continuous, iterative, throughout lifecycle +2. Apply **data and data governance** measures (Art. 10) — relevant, representative, error-free training/validation/test data; bias examination +3. Draw up **technical documentation** (Art. 11, Annex IV) — before placing on market; kept up to date; 10-year retention +4. Build in automatic **logging/record-keeping** capability (Art. 12) — events relevant to identifying risks; traceability +5. Provide **instructions for use** to deployers (Art. 13) — capabilities, limitations, accuracy metrics, human oversight measures +6. Enable **human oversight** by deployers (Art. 14) — technical measures for human intervention, interruption, override +7. Achieve appropriate **accuracy, robustness, cybersecurity** (Art. 15) — consistent throughout lifecycle; resilience to adversarial attacks +8. Establish a **quality management system** (Art. 17) — documented, proportionate; records kept for 10 years +9. Conduct or commission a **conformity assessment** (Art. 19) — internal or third-party depending on system category +10. Affix **CE marking** and draw up an **EU declaration of conformity** (Arts. 35–36) — after successful conformity assessment +11. **Register** in EU database (Art. 49 / Art. 71) — before placing on market +12. Have an **authorised representative** in EU if provider is outside the EU (Art. 25) +13. Report **serious incidents** to national authorities (Art. 73) — within 15 days (3 days for immediate risk, 2 days for death/serious deterioration) +14. Conduct **post-market monitoring** (Art. 72) — throughout lifecycle + +> For full provider requirements (Arts. 8–17) with evidence checklists → read `references/eu-ai-act-high-risk-systems.md` + +### Deployer Obligations (Art. 26) + +Deployers of **high-risk AI systems** must: +1. Use the AI system **in accordance with instructions of use** and for its intended purpose +2. **Not modify** the AI system's intended purpose without re-classification assessment +3. Assign **human oversight** to competent, trained natural persons with authority to act +4. Ensure relevant staff have **AI literacy** (Art. 4) and training adequate to use the system +5. Implement **technical and organisational measures** ensuring human oversight capability +6. **Monitor** the AI system for risks during operation based on instructions for use; report concerns to providers/distributors/authorities +7. Conduct a **Fundamental Rights Impact Assessment (FRIA)** (Art. 27) — required for deployers of Annex III high-risk AI systems, unless the deployer is a small-scale provider +8. **Inform employees and their representatives** when AI systems affecting them are to be deployed +9. **Register** in EU database (Art. 49) — required for public authority deployers +10. Report **serious incidents** to the provider and to national market surveillance authorities +11. Keep **logs** generated by the system for at least 6 months (where technically feasible and relevant) + +### GPAI Model Provider Obligations (Arts. 53–55) + +> For full GPAI obligations → read `references/eu-ai-act-gpai-models.md` + +**All GPAI model providers (Art. 53) must:** +1. Draw up and maintain **technical documentation** (Annex XI) +2. Provide **information and documentation** to downstream providers (Annex XII) +3. Have a **policy to comply with EU Copyright Directive** (Directive 2019/790) +4. Publish a **summary of training content** + +**Open-weight/free and open licence GPAI providers (Art. 54):** Only obligations 3 and 4 above apply — unless the model presents systemic risk. + +**GPAI models with systemic risk** (cumulative training compute > 10^25 FLOPs, or Commission determination) must additionally (Art. 55): +1. Perform **model evaluations** including adversarial testing +2. **Assess and mitigate systemic risks** +3. **Track, document, report serious incidents** to AI Office and NCAs without undue delay +4. Ensure **cybersecurity protection** + +--- + +## Core Workflows + +### 1. AI System Risk Classification + +**Inputs needed:** Description of the AI system, its intended purpose, intended users, deployment context, whether it involves biometrics/profiling, whether it's integrated into a regulated product. + +**Process:** +1. Check Article 5 prohibited categories — if any match, output: PROHIBITED +2. Check Article 6(1) — Annex I product + third-party conformity assessment → HIGH-RISK (Route A) +3. Check Article 6(2) — Annex III use cases → Apply Art. 6(3) exceptions test → HIGH-RISK Route B or not +4. Check Article 50 transparency obligations → TRANSPARENCY-ONLY if no high-risk classification +5. Otherwise → MINIMAL RISK + +**Classification output format:** +``` +Classification: [PROHIBITED / HIGH-RISK (Art. 6(1)) / HIGH-RISK (Art. 6(2)) / TRANSPARENCY-ONLY / MINIMAL RISK] +Basis: [Specific article and annex reference] +Applicable obligations: [Summary] +Compliance deadline: [Date] +Notes: [Any conditions, exceptions, or caveats] +``` + +### 2. High-Risk AI System Compliance Gap Analysis + +**Inputs needed:** AI system purpose, current documentation in place, development/deployment stage, whether provider or deployer, current risk management practices. + +**Gap analysis output format:** +``` +ARTICLE | REQUIREMENT | STATUS | EVIDENCE NEEDED | ACTION +Art. 9 | Risk management system established and maintained | 🔴 | Risk management plan, risk register | Establish iterative risk management process per Art. 9(2) +Art. 10 | Data governance — training data documented | 🟡 | Data sheet, bias evaluation records | Complete data quality assessment and bias examination +Art. 11 | Technical documentation drawn up | 🔴 | Annex IV documentation | Draft full Annex IV technical documentation package +Art. 17 | Quality management system | 🟡 | QMS procedure, records | Expand existing QMS to cover AI-specific requirements +``` + +### 3. GPAI Model Compliance Assessment + +**Inputs needed:** Model name/type, training compute (FLOPs if known), whether open-weight/open-licence, downstream use cases, current documentation status. + +**Process:** +1. Determine if model qualifies as GPAI under Art. 3(63) definition +2. Determine if open-weight/open-licence (Art. 54 applies) +3. Assess systemic risk — compute threshold (10^25 FLOPs) or Commission designation +4. Map to Art. 53 (all), Art. 54 (open), Art. 55 (systemic risk) obligations +5. Assess compliance status for each obligation +6. Determine codes of practice adherence pathway + +### 4. Fundamental Rights Impact Assessment (FRIA) — Art. 27 + +Required for deployers of high-risk AI systems covered by Annex III (exceptions: deployers who are small-scale providers of the same system; systems that have already undergone fundamental rights impact assessment under other EU law in same context). + +**FRIA must include:** +- Description of the deployer's processes in which the high-risk AI system will be used +- Description of time period and frequency of use +- Categories of natural persons who will be affected +- Specific risks of harm to fundamental rights and likelihood +- Description of measures to address identified risks +- Name and contact details of the deployer; date of assessment; senior management sign-off + +**Fundamental rights to assess:** +- Right to dignity (Art. 1 EU Charter) +- Right to physical and mental integrity (Art. 3) +- Prohibition of torture and inhuman treatment (Art. 4) +- Prohibition of slavery and forced labour (Art. 5) +- Right to liberty and security (Art. 6) +- Respect for private and family life, home, communications (Art. 7) +- Protection of personal data (Art. 8) +- Right to marry and right to found a family (Art. 9) +- Freedom of thought, conscience, religion (Art. 10) +- Freedom of expression and information (Art. 11) +- Freedom of assembly and association (Art. 12) +- Freedom of the arts and sciences (Art. 13) +- Right to education (Art. 14) +- Freedom to choose an occupation and right to engage in work (Art. 15) +- Non-discrimination (Art. 21) +- Cultural, religious and linguistic diversity (Art. 22) +- Equality between women and men (Art. 23) +- Rights of the child (Art. 24) +- Rights of the elderly (Art. 25) +- Integration of persons with disabilities (Art. 26) +- Right to an effective remedy and to a fair trial (Art. 47) +- Presumption of innocence and right of defence (Art. 48) + +> For FRIA template → read `references/eu-ai-act-obligations-templates.md` + +### 5. Conformity Assessment + +**Route determination for high-risk AI systems (Art. 43):** + +| AI System Category | Conformity Assessment Route | +|-------------------|-----------------------------| +| Annex III biometric (remote biometric identification) | **Third-party — Notified Body** required | +| Annex III biometric (categorization, emotion recognition) | **Internal** — Art. 43(2) self-assessment permitted | +| Annex III all other categories | **Internal** — Art. 43(2) self-assessment permitted | +| AI as safety component in Annex I product | Third-party — as required by the applicable sectoral legislation | +| Substantial modification to placed-on-market system | Full conformity assessment again | + +**Internal conformity assessment (Art. 43(2)) steps:** +1. Complete Annex IV technical documentation +2. Verify compliance with all requirements (Arts. 8–15) +3. Establish quality management system (Art. 17) +4. Draw up EU declaration of conformity (Art. 47, Annex V format) +5. Affix CE marking (Art. 48, Annex VI) +6. Register in EU database (Art. 49) +7. Implement post-market monitoring plan (Art. 72, Annex VII framework) + +### 6. Penalty Exposure Analysis + +**Penalty tiers under Article 99:** + +| Violation | Maximum Penalty | +|-----------|----------------| +| Prohibited AI practices (Art. 5) | **€35 million or 7% of global annual turnover** (whichever higher) | +| Non-compliance with high-risk AI requirements (Arts. 8–17), provider/deployer obligations, GPAI obligations (Arts. 53–55), notified body obligations | **€15 million or 3% of global annual turnover** (whichever higher) | +| Providing incorrect, incomplete, or misleading information to notified bodies or national competent authorities | **€7.5 million or 1.5% of global annual turnover** (whichever higher) | + +**GPAI model penalties (Art. 100):** Fines for non-compliance with GPAI obligations (Arts. 53–55) and for providing incorrect information to the AI Office — same tiers as above; the AI Office may also impose periodic penalty payments. + +**SME/startup adjustment:** For SMEs and startups, the maximum penalty is the lower of the percentage and the absolute cap, if lower. + +**National variation:** Member States may impose stricter national penalties for breaches not harmonised by the EU AI Act. + +--- + +## Governance Structure + +| Body | Role | Reference | +|------|------|-----------| +| European AI Office | Commission body; oversees GPAI model compliance; issues guidelines and codes of practice; investigates GPAI systemic risk | Art. 64 | +| European AI Board | Member State representatives; coordination and consistency; issues opinions; supports Commission | Art. 65 | +| Advisory Forum | Multi-stakeholder advisory body (industry, civil society, academia) to AI Board and Commission | Art. 67 | +| Scientific Panel | Independent experts advising AI Office on GPAI systemic risk evaluation | Art. 68 | +| National Competent Authorities (NCAs) | Market surveillance for high-risk AI systems (other than GPAI); notifying authorities; accept complaints | Art. 70 | +| Notified Bodies | Third-party conformity assessment for biometric high-risk AI and Annex I product AI | Arts. 38–44 | + +--- + +## Key Definitions (Art. 3) + +| Term | Definition | +|------|-----------| +| AI system | "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments" (Art. 3(1)) | +| Provider | Natural/legal person placing an AI system on the market or putting into service under its own name/trademark, whether for payment or free of charge | +| Deployer | Natural/legal person using an AI system under its authority (not affected end-users); formerly called "user" in pre-final texts | +| GPAI model | AI model trained with large amounts of data using self-supervision at scale, displaying significant generality, capable of performing a wide range of tasks, and able to be integrated into various downstream systems (Art. 3(63)) | +| GPAI system | AI system based on a GPAI model capable of serving various purposes for direct use or integration into other AI systems (Art. 3(64)) | +| Systemic risk | Risk with a significant negative impact on the Union market through disproportionate harm or harm to critical sectors, public security or safety — specific to GPAI with high-impact capabilities (Art. 3(65)) | +| High-risk AI system | AI systems classified under Art. 6(1) or 6(2) based on Annex I or Annex III criteria | +| Serious incident | Incident or malfunction leading to death, serious health injury, disruption of critical infrastructure, serious property damage, or potential violation of fundamental rights obligations (Art. 3(49)) | +| Substantial modification | Change to a high-risk AI system after placing on market that affects compliance or changes the intended purpose (Art. 3(23)) | +| Intended purpose | Use for which an AI system is intended, including specific context and conditions of use, as specified by the provider (Art. 3(12)) | +| Reasonably foreseeable misuse | Use in a way not in accordance with intended purpose but resulting from reasonably foreseeable human behaviour or interaction with other systems (Art. 3(13)) | + +--- + +## Document Reference Index + +| Document | Contents | When to Read | +|----------|----------|-------------| +| `references/eu-ai-act-prohibited-practices.md` | Full Article 5 detail — all 8 prohibited categories, conditions, exceptions, enforcement from Feb 2025 | Checking if an AI system is prohibited; advising on specific use cases near borderlines | +| `references/eu-ai-act-high-risk-systems.md` | Annex III full list; Articles 8–17 requirements; conformity assessment routes; technical documentation (Annex IV); post-market monitoring | Any high-risk AI compliance task, gap analysis, provider obligations | +| `references/eu-ai-act-gpai-models.md` | GPAI definition, Art. 53–55 obligations, systemic risk threshold, codes of practice, open-weight rules, Annexes XI–XII | Any GPAI model compliance question | +| `references/eu-ai-act-obligations-templates.md` | Provider/deployer obligation checklists; FRIA template; technical documentation template; incident reporting form; EU declaration of conformity template | Document drafting; compliance checklist generation; audit evidence preparation | diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-articles.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-articles.md new file mode 100644 index 0000000..237ff33 --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-articles.md @@ -0,0 +1,362 @@ +# EU AI Act — Article-by-Article Reference: Key Provisions + +**Regulation (EU) 2024/1689 of 13 June 2024** +This reference covers key articles across all 13 chapters. All citations reference the final published text in OJ L 2024/1689. + +--- + +## Chapter I — General Provisions (Articles 1–4) + +### Article 1 — Subject Matter + +The AI Act lays down harmonised rules on: +- The placing on the market, putting into service, and use of AI systems in the Union +- The placing on the market of general-purpose AI models +- Prohibitions on certain AI practices +- Requirements for high-risk AI systems +- Transparency obligations for certain AI systems +- Rules on market monitoring, market surveillance, and enforcement +- Rules on governance and penalties + +### Article 2 — Scope + +**Applies to:** +- Providers placing on the market or putting into service AI systems or GPAI models in the Union — regardless of whether those providers are established or located in the Union or in a third country +- Deployers of AI systems located within the Union +- Providers and deployers of AI systems located outside the Union where the output produced by the AI system is used in the Union +- Importers and distributors of AI systems +- Product manufacturers placing on the market or putting into service an AI system together with their product +- Authorised representatives of providers not established in the Union + +**Excluded from scope (Art. 2(3)–(6)):** +- AI systems developed or used exclusively for **military, defence, or national security** purposes +- AI systems and models developed and put into service solely for the purpose of **scientific research and development** prior to market placement — but results/products must comply when placed on market +- AI systems released under **free and open-source licences** — unless they fall into prohibited (Chapter II) or high-risk (Chapter III) categories +- AI systems used by public authorities of third countries or international organisations under international agreements for law enforcement and judicial cooperation (subject to conditions) +- Natural persons using AI systems in the course of purely **personal non-professional activity** + +### Article 3 — Definitions (90+ definitions; key selections) + +| Article 3(x) | Term | Definition summary | +|-------------|------|-------------------| +| Art. 3(1) | AI system | Machine-based system operating with varying autonomy, inferring from inputs how to generate outputs (predictions, content, recommendations, decisions) influencing physical/virtual environments | +| Art. 3(2) | Risk | Combination of probability of harm occurring and severity of that harm | +| Art. 3(3) | Provider | Places AI system / GPAI model on market or puts into service under own name/trademark | +| Art. 3(4) | Deployer | Uses AI system under their authority (not affected end-users); in a professional capacity | +| Art. 3(5) | Authorised representative | Natural/legal person established in EU designated in writing by provider outside EU | +| Art. 3(6) | Importer | Natural/legal person established in EU placing on market AI system from provider outside EU | +| Art. 3(7) | Distributor | Natural/legal person in value chain (not provider or importer) making AI system available | +| Art. 3(8) | Operator | Any provider, product manufacturer, deployer, authorised representative, importer, or distributor | +| Art. 3(9) | Placing on the market | First making available of an AI system or GPAI model on EU market | +| Art. 3(10) | Putting into service | Supply of AI system for first use directly by provider or for own use in EU | +| Art. 3(11) | Intended purpose | Use for which AI system is designed, as specified by provider in documentation, instructions, etc. | +| Art. 3(12) | Reasonably foreseeable misuse | Use not in line with intended purpose resulting from reasonably foreseeable human behaviour | +| Art. 3(13) | Safety component | Component that performs a safety function, the failure of which endangers health/safety of persons or the environment | +| Art. 3(14) | Instructions for use | Information provided by provider to inform deployer of intended purpose, proper use, and risks | +| Art. 3(23) | Substantial modification | Change to high-risk AI system after placing on market affecting compliance or changing intended purpose | +| Art. 3(29) | Technical documentation | Documentation drawn up by provider under Art. 11 demonstrating AI system complies | +| Art. 3(30) | EU declaration of conformity | Declaration by provider that AI system complies with the EU AI Act requirements | +| Art. 3(34) | Market surveillance authority | National authority monitoring and enforcing compliance | +| Art. 3(40) | Remote biometric identification system | AI for identifying persons at a distance via comparison with biometric data in reference database | +| Art. 3(49) | Serious incident | Incident/malfunction directly/indirectly leading to death, serious health injury, disruption of critical infrastructure, property damage, or fundamental rights violation | +| Art. 3(63) | GPAI model | AI model trained at scale displaying generality, capable of wide range of tasks, integratable in downstream systems | +| Art. 3(64) | GPAI system | AI system based on GPAI model serving various purposes | +| Art. 3(65) | Systemic risk | Risk specific to high-impact GPAI models with significant negative impact on Union market | + +### Article 4 — AI Literacy + +**Applicable from: 2 February 2025.** + +Providers and deployers of AI systems must take measures to ensure an **appropriate level of AI literacy** of their staff and others using AI systems on their behalf — taking into account their technical knowledge, experience, education, training context, and intended use of AI systems. + +**Minimum literacy elements:** +- Understanding of AI system capabilities and limitations +- Understanding of AI risks relevant to their role +- Relevant sector-specific competencies + +**Note:** This is an ongoing organisational obligation, not a one-time certification. Evidence of compliance includes training records, competency assessments, and documented AI literacy programmes. + +--- + +## Chapter II — Prohibited AI Practices (Article 5) + +> See dedicated reference document: `eu-ai-act-prohibited-practices.md` + +--- + +## Chapter III — High-Risk AI Systems + +> For Annex III classification rules and techinal requirements (Arts. 6–17) → see `eu-ai-act-high-risk-systems.md` + +### Article 18 — Drawing up Technical Documentation + +Providers of high-risk AI systems must draw up the technical documentation referred to in Art. 11 **before** placing on market. For AI systems that are components of Annex I products, the technical documentation required by the applicable sectoral legislation and the Annex IV technical documentation may be integrated into a single document. + +### Article 19 — Conformity Assessment + +Providers must carry out a conformity assessment in accordance with Art. 43 before placing on market or putting into service. Conformity assessments must be repeated when a **substantial modification** is made to the AI system. + +### Article 20 — Automatically Generated Logs + +Where providers have access to logs automatically generated by their high-risk AI systems, they must retain those logs where reasonably expected in the light of the intended purpose. Minimum retention: 6 months unless applicable law requires otherwise. + +### Article 21 — Corrective Actions and Duty of Information + +When a provider of a high-risk AI system has reason to consider that the AI system is not in conformity with the EU AI Act, the provider must immediately take corrective action to bring the system into conformity, withdraw it, or recall it, as appropriate. + +**Duty to inform:** Providers must immediately inform: +- The national market surveillance authorities of Member States in which the system is available +- Distributors and deployers +- Where applicable: the notified body that issued the AI certificate (which may suspend/revoke the certificate) + +### Article 22 — Duty of Information + +Providers of high-risk AI systems which are placed on the market in the Union must inform the relevant national market surveillance authorities and the national competent authority of incidents referred to in Art. 73. + +### Article 23 — Cooperation with National Competent Authorities + +Providers of high-risk AI systems must cooperate with national competent authorities on request to demonstrate conformity, provide access to the technical documentation, and provide samples or access to the AI system for testing purposes. + +### Article 24 — Obligations of Product Manufacturers + +Where a manufacturer places a product on the market bearing the CE marking of a high-risk AI system, the manufacturer has the same obligations as the AI system provider under the EU AI Act. + +### Article 25 — Authorised Representatives + +Providers established **outside the EU** must designate an authorised representative in the EU before placing their high-risk AI system on the EU market. + +**Authorised representative responsibilities:** +- Verify that the EU declaration of conformity and technical documentation have been drawn up +- Verify CE marking has been affixed +- Report to the provider any request from national authorities +- Keep contact details up to date with EU registry +- Cooperate with national authorities + +### Article 26 — Obligations of Deployers of High-Risk AI Systems + +> See also: `eu-ai-act-obligations-templates.md` for deployer checklist + +Deployers must: +1. Use the AI system in accordance with instructions of use +2. Assign human oversight to specifically designated and trained persons +3. Take technical and organisational measures to enable human oversight +4. Monitor operation of the AI system based on instructions; inform providers of risks +5. Conduct Fundamental Rights Impact Assessment (FRIA) where required by Art. 27 +6. Inform employees and their representatives before deployment of systems affecting them +7. Register in EU database (where required — public authority deployers) +8. Not use an AI system that poses unacceptable risk to health, safety, or fundamental rights + +### Article 27 — Fundamental Rights Impact Assessment (FRIA) + +> See FRIA template in `eu-ai-act-obligations-templates.md` + +**Mandatory for:** Deployers of high-risk AI systems listed in Annex III, **except** for: +- Deployers that are credit institutions regulated by Directive 2013/36/EU (provided comparable assessment conducted) +- Deployers using AI systems for public authority purposes where another Union legal act requires a similar assessment prior to deployment + +**FRIA contents (Art. 27(2)):** +- Description of deployer's processes in which high-risk AI system will be used +- Time period and frequency of use +- Categories of natural persons who will be affected in each specific context of use +- Specific risks of harm to fundamental rights categories listed in Art. 27(2)(d) +- Description of measures to address identified risks including mitigation and/or accommodation measures +- Name and contact details of deployer, date of completion, and review date +- Signed by a senior management representative + +**When significant changes occur:** A new FRIA is required when the intended use or deployment context changes significantly. + +### Article 28 — Obligations of Importers + +Importers of high-risk AI systems must: +- Verify that the provider has established the quality management system (Art. 17) and that technical documentation has been drawn up +- Verify that the provider has carried out conformity assessment and drawn up the EU declaration of conformity +- Verify that the CE marking has been affixed +- Verify that the system is accompanied by instructions for use +- Inform providers and national authorities of identified non-conformities + +### Article 29 — Obligations of Distributors + +Distributors must verify that the high-risk AI system bears the CE marking, that the EU declaration of conformity has been drawn up, and that the required documentation has been produced. They must also ensure storage and transport do not jeopardize compliance. + +### Article 35 — EU Declaration of Conformity + +Providers must draw up the EU declaration of conformity for each high-risk AI system in accordance with Annex V. The declaration must: +- Contain the information set out in Annex V +- Be translated into language(s) required by the Member State(s) where the system is placed on market +- Kept up to date for **10 years** after placing on market + +--- + +## Chapter IV — Transparency Obligations (Article 50) + +### Article 50 — Transparency Obligations for Certain AI Systems + +**Article 50(1) — Chatbots and conversational AI:** +Providers of AI systems designed to interact directly with natural persons must ensure that persons are informed they are interacting with an AI system unless: +- It is obvious from the circumstances and context that persons are interacting with an AI system + +**Article 50(2) — Emotion recognition and biometric categorisation:** +Providers and deployers of AI systems that detect or infer emotions or intentions of natural persons, or that assign persons to specific categories based on biometric data, must inform the natural persons exposed to such a system about the operation of the system in accordance with Regulation (EU) 2016/679 (GDPR) and Directive 2002/58/EC. +**Exception:** Not applicable if systems are used for biometric categorisation or emotion recognition for law enforcement purposes with appropriate authorisation under applicable law. + +**Article 50(3) — Deep fakes and synthetic content:** +Deployers of AI systems that generate or manipulate image, audio, or video content that appreciably resembles existing persons, objects, places, or other entities or events and would falsely appear to a person to be authentic or truthful must disclose that the content has been artificially generated or manipulated. +**Exceptions:** +- For legitimate purposes (lawful, law enforcement use) +- For the purpose of the exercise of the right to freedom of expression and arts and sciences — provided appropriate disclosure or disclaimers + +**Article 50(4) — AI-generated text on public interest matters:** +Deployers using AI to generate text published for the purpose of informing the public on matters of public interest must disclose that the text was artificially generated. Does not apply where the text has undergone human review or editorial control to a degree where the AI contribution is not substantial. + +**Labelling requirements:** AI-generated content required to be labelled under Art. 50(3) and (4) must be labelled in a machine-readable format and detectable as AI-generated where technically feasible. + +--- + +## Chapter VII — Governance (Articles 64–70) + +### Key Governance Bodies + +**European AI Office (Art. 64):** +- Established within the European Commission +- Responsible for monitoring GPAI model providers' compliance +- Issues guidelines, codes of practice, and technical standards recommendations +- Conducts investigations and evaluations of GPAI models +- Imposes and enforces penalties on GPAI providers (working through Commission) +- Coordinates with national competent authorities +- Operational since: February 2024 (pre-dates AI Act entry into force — established by Commission Decision) + +**European AI Board (Art. 65):** +- Composed of representatives of Member State national competent authorities +- Chaired by a Commission representative +- Issues opinions, recommendations, and guidance to the Commission and Member States +- Facilitates cross-border enforcement coordination +- Can recommend Commission action on GPAI systemic risk + +**Advisory Forum (Art. 67):** +- Multi-stakeholder advisory body to the AI Board and Commission +- Composed of representatives of: industry (including SMEs), civil society, academia, standardisation bodies, research organisations +- Provides technical expertise and advice + +**Scientific Panel of Independent Experts (Art. 68):** +- Body of independent scientific experts on AI safety +- Advises the AI Office on GPAI systemic risk evaluation +- Can issue qualified alerts to the AI Office triggering investigation of GPAI models +- Members selected for expertise in AI, data science, cybersecurity, social science + +### Article 70 — National Competent Authorities + +Member States must designate national competent authorities (NCAs) by **2 August 2025**: +- **Notifying authority**: responsible for notified body designation and monitoring +- **Market surveillance authority**: responsible for AI Act market surveillance in their territory + +**Market surveillance authority powers:** +- Access to technical documentation and AI system testing +- Request corrections, withdrawals, or recalls of non-compliant systems +- Issue temporary bans on placing on market +- Coordinate with national data protection authorities (DPAs) +- Accept and handle complaints from natural persons + +--- + +## Chapter IX — Post-Market Monitoring and Incident Reporting + +### Article 72 — Post-Market Monitoring by Providers + +Providers of high-risk AI systems must: +- Establish, document, and maintain a **post-market monitoring system** throughout the lifecycle +- Proactively collect and review data on performance of deployed systems +- Analyse data for risks or incidents +- Implement corrective actions where needed +- Report to EU database and authorities as required + +**Minimum monitoring plan content (Annex VII framework):** +- Monitoring metrics and performance indicators +- Data collection methodology +- Frequency and scope of monitoring reviews +- Thresholds for triggering corrective action +- Post-market monitoring review cycle + +### Article 73 — Reporting of Serious Incidents + +Providers of high-risk AI systems placed on the EU market must **report serious incidents** to the market surveillance authorities of Member States where the incident occurred. + +**Serious incident defined (Art. 3(49)):** Any incident or malfunction of a high-risk AI system resulting in: +- Death of a person or serious harm to a person's health +- Disruption to the management and operation of critical infrastructure +- Infringement of obligations under Union law intended to protect fundamental rights +- Serious and irreversible disruption to the management and operation of critical infrastructure + +**Reporting timelines:** +- **15 days** for serious incidents not involving immediate risk to life +- **3 days** for incidents posing immediate risk to health, safety, or fundamental rights +- **2 days** for death or serious deterioration in the state of health of a person's health + +**Content of incident report:** +- Provider identity and contact details +- System name and version +- Description of the incident with date(s) and location +- Immediate corrective actions taken +- Any preliminary hypothesis on cause +- Information on affected persons + +--- + +## Chapter X — Penalties (Articles 99–101) + +### Article 99 — Penalties + +**Tier 1 — Prohibited AI practices (Art. 5 violations):** +Maximum penalty: **€35,000,000** or, if the offender is an undertaking, **7% of its total worldwide annual turnover** for the preceding financial year, whichever is **higher**. + +**Tier 2 — Other AI Act obligations (providers and deployers of high-risk AI; GPAI providers; notified bodies):** +Maximum penalty: **€15,000,000** or, if the offender is an undertaking, **3% of its total worldwide annual turnover** for the preceding financial year, whichever is **higher**. + +**Tier 3 — Incorrect, incomplete, or misleading information to authorities:** +Maximum penalty: **€7,500,000** or, if the offender is an undertaking, **1.5% of its total worldwide annual turnover** for the preceding financial year, whichever is **higher**. + +**SME/startup adjustment (Art. 99(6)):** For SMEs (including startups), the maximum penalty is the lower of: +- The percentage-based cap, or +- The fixed monetary cap + +**Factors considered when setting penalties:** +- Nature, gravity, duration, and consequences of the infringement +- Whether intentional or through negligence +- Actions taken to mitigate harm +- Degree of responsibility of each party +- Financial capacity and size of the undertaking +- Cooperation with authorities +- Prior infringements +- Way in which the infringement became known (self-reported or discovered) + +### Article 100 — Penalties for GPAI Model Providers + +The Commission (working through the AI Office) may impose fines on GPAI model providers for: +- Infringements of Arts. 53, 54, 55 (GPAI obligations) +- Failure to comply with measures/orders imposed by the AI Office +- Providing incorrect, incomplete, or misleading information to the AI Office + +Penalty tiers mirror Art. 99. Periodic penalty payments may also be imposed. + +### Article 101 — Penalties on Union Institutions Using AI + +EU institutions, bodies, offices, and agencies deploying AI systems as deployers must comply with deployer obligations. The European Data Protection Supervisor has enforcement competence for Union institution compliance. + +--- + +## Chapter XII — Final Provisions (Article 113 — Application Dates) + +**Entry into force:** 20 days after publication = **1 August 2024** + +**6 months after entry into force** (2 February 2025): Chapter I (General Provisions), Chapter II (Prohibited practices), and Art. 4 (AI literacy) apply. + +**12 months after entry into force** (2 August 2025): Chapter III Section 4 (Notified Bodies), Chapter V (GPAI), Chapter VII (Governance), Art. 78 (Confidentiality), Arts. 99–100 (Penalties) apply. + +**24 months after entry into force** (2 August 2026): The remainder of the Regulation applies, with the exception of Art. 6(1). + +**36 months after entry into force** (2 August 2027): Article 6(1) (AI as safety components in Annex I regulated products) and corresponding obligations apply. + +**Transitional provisions for existing high-risk AI systems:** +- High-risk AI systems placed on market **before 2 August 2026**: must comply by 2 August 2026 only if subject to significant change in design from that date (Art. 111(2)) +- High-risk AI systems placed on market **before 2 August 2026** used by public authorities: must comply by **2 August 2030** (Art. 111(2)) +- GPAI models placed on market **before 2 August 2025**: must comply by **2 August 2027** (Art. 111(3)) +- Large-scale IT systems (Annex X) placed on market **before 2 August 2027**: must comply by **31 December 2030** (Art. 111(1)) diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-gpai-models.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-gpai-models.md new file mode 100644 index 0000000..9bc44ee --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-gpai-models.md @@ -0,0 +1,267 @@ +# EU AI Act — General-Purpose AI (GPAI) Models: Obligations, Systemic Risk, and Codes of Practice + +**Regulation (EU) 2024/1689, Chapter V (Articles 51–56)** +**Applicable from: 2 August 2025** + +--- + +## Definitions and Scope + +### What is a GPAI Model? (Art. 3(63)) + +A **general-purpose AI (GPAI) model** is an AI model that: +- Is trained with a large amount of data using self-supervision at scale +- Displays significant generality +- Is capable of competently performing a wide range of distinct tasks +- Is regardless of the way the model is placed on the market +- Can be integrated into a variety of downstream systems or applications + +**Exclusion:** AI models used **before release on the market** for research, development, and prototyping activities are not GPAI models for purposes of the EU AI Act. + +### What is a GPAI System? (Art. 3(64)) + +A **GPAI system** is an AI system based on a GPAI model that: +- Has the capability to serve a variety of purposes +- Is used for direct use as well as for integration in other AI systems + +### Key distinction between GPAI models and GPAI systems + +| Term | Meaning | Regulatory focus | +|------|---------|-----------------| +| GPAI model | The underlying trained model (e.g., weights + architecture) | Provider obligations under Arts. 53–55 | +| GPAI system | An AI system built on a GPAI model | Can be a standalone product or integrated into another system | + +GPAI systems used as high-risk AI systems remain subject to the high-risk AI requirements in Chapter III. GPAI model providers are expected to cooperate with downstream high-risk AI system providers. + +--- + +## Classification of GPAI Models with Systemic Risk (Article 51) + +### Systemic Risk Defined (Art. 3(65)) + +Systemic risk means a risk that is specific to high-impact GPAI models, having a significant negative impact on the Union market due to their reach, or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or any combination thereof, that can propagate throughout the value chain. + +### Threshold for Systemic Risk Classification + +A GPAI model is classified as presenting **systemic risk** if either: + +**Compute threshold (Art. 51(1)(a)):** +The cumulative amount of compute used for its training measured in floating point operations (FLOPs) is greater than **10^25 FLOPs**. + +**Commission determination (Art. 51(1)(b)):** +The Commission determines the model has high-impact capabilities based on criteria set out in Annex XIII or based on a qualified alert by the AI scientific panel — even if it does not meet the compute threshold. + +### Notification Obligation (Art. 52) + +**Providers** of GPAI models that meet or exceed the 10^25 FLOPs threshold must **notify the European Commission** within **2 weeks** of placing the model on the market or making it available. Notification is also required when updated versions exceed the threshold. + +**Presumption:** A GPAI model meeting the compute threshold is presumed to present systemic risk. Providers may present arguments to the Commission that their model, despite meeting the threshold, does not present systemic risk. The Commission may accept or reject these arguments. + +**Commission-initiated determination:** The AI Office, on its own initiative or following a qualified alert from the scientific panel, may determine a model presents systemic risk regardless of compute. + +--- + +## Obligations for All GPAI Model Providers (Article 53) + +The following four obligations apply to **all** GPAI model providers, unless the open-weight exception (Art. 54) applies: + +### Obligation 1 — Technical Documentation (Art. 53(1)(a), Annex XI) + +Providers must draw up and keep up to date technical documentation, including **training and testing process** and the results of the **evaluation** process, to be made available to the AI Office and national competent authorities on request. + +**Annex XI — Minimum contents of GPAI technical documentation:** +- General description of the GPAI model +- Information about the training process (data, compute, duration) +- Information about the model's architecture +- Training data details: types of data used, volume, provenance, data curation methodology +- Modalities and capabilities the model supports +- Information about evaluation approaches and benchmarks used +- Description of risks and mitigating measures +- Record of known or reasonably foreseeable risks to fundamental rights +- Technical measures taken to ensure downstream providers understand capabilities/limitations + +### Obligation 2 — Information for Downstream Providers (Art. 53(1)(b), Annex XII) + +Providers must draw up and maintain **documentation for downstream providers** — i.e., organisations that integrate the GPAI model into their own AI systems — to enable those downstream providers to comply with their own EU AI Act obligations (particularly high-risk AI requirements if the downstream system becomes high-risk). + +**Annex XII — Minimum information to be provided to downstream providers:** +- Identity and contact details of the GPAI model provider +- Capabilities and limitations of the model (including documented performance benchmarks) +- Conditions under which the model may be integrated into AI systems +- Any known risks, limitations, or biases +- Summary of the training data used +- Information required to comply with technical documentation obligation (Annex IV) for downstream high-risk AI providers +- Applicable usage policies and restrictions + +**Format:** May be provided via model cards, API documentation, or similar technical documentation formats. + +### Obligation 3 — Copyright Compliance Policy (Art. 53(1)(c)) + +Providers must put in place a **policy to comply with Union copyright law**, and in particular to identify and comply with including through state of the art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790 (Copyright in the Digital Single Market Directive). + +**Practical requirements:** +- Implement a process to respect opt-outs expressed by rights holders under Art. 4(3) of Directive 2019/790 +- Document the copyright compliance policy +- Apply this to training data sourcing and processing + +**Art. 4(3) of Directive 2019/790:** Rights holders may expressly reserve the right to opt out of the text-and-data mining exception (Art. 4(1)) — for example through machine-readable notices. GPAI providers must detect and honour such opt-outs. + +### Obligation 4 — Summary of Training Content (Art. 53(1)(d)) + +Providers must publish and maintain a **sufficiently detailed summary** about the content used for training the GPAI model. + +**Format:** The AI Office published a template for compliance with this obligation (released 2025). The summary must be: +- Sufficiently detailed to enable rights holders and the public to understand what data was used +- Made publicly available (e.g., model card, website) +- Updated when the model is retrained on significantly new or different data + +--- + +## Obligations for Open-Weight / Free and Open Licence GPAI Models (Article 54) + +### Scope of Open-Weight Exemption + +A GPAI model qualifies for the reduced obligations under Art. 54 if: +- The **parameters** including weights are publicly available +- The **model architecture** is publicly available +- The **model usage information** is publicly available +- The above allows for **access, usage, modification, and distribution** of the model + +In other words: the model is genuinely open — weights released under an open licence. + +### Reduced Obligations for Open-Weight GPAI Models + +Open-weight GPAI model providers **only** need to comply with: +- **Obligation 3** (copyright policy — Art. 53(1)(c)) +- **Obligation 4** (training summary — Art. 53(1)(d)) + +They are **exempt** from: +- Obligation 1 (technical documentation for authorities) +- Obligation 2 (information for downstream providers) + +### Exception to Open-Weight Exemption: Systemic Risk + +If an open-weight GPAI model **presents systemic risk** (i.e., trained with > 10^25 FLOPs or Commission-designated), the open-weight exemption does **not apply** to the systemic risk obligations under Art. 55. The provider must comply in full with both Arts. 53 and 55, regardless of open-weight status. + +--- + +## Obligations for GPAI Models with Systemic Risk (Article 55) + +In addition to the Art. 53 obligations (unless open-weight, in which case Art. 54 applies but Art. 55 applies regardless), providers of GPAI models with systemic risk must: + +### Obligation A — Model Evaluations including Adversarial Testing (Art. 55(1)(a)) + +Providers must perform model evaluations in accordance with standardised protocols and tools when available, including conducting and documenting **adversarial testing** of the model with the aim of identifying and mitigating systemic risks. + +**What adversarial testing must cover:** +- Red-teaming — testing the model to identify failure modes, dangerous capabilities, misalignments +- Capabilities evaluation — systematic assessment of potentially dangerous capabilities (e.g., capability to assist with weapons of mass destruction, cyberattacks, manipulation at scale) +- Alignment evaluation — assessment of the model's susceptibility to being steered toward harmful outputs +- Specific risk categories identified in systemic risk assessment + +**Codes of practice** will provide detailed methodologies. The AI Office's GPAI code of practice (published May 2025) contains evaluation standards. + +### Obligation B — Assess and Mitigate Systemic Risks (Art. 55(1)(b)) + +Providers must assess and mitigate the possible systemic risks at Union level that may stem from the development, placement on the market, or use of GPAI models with systemic risk, including their sources. + +**Risk categories to assess (from Recitals 110–115 and Annex XIII):** +- Risks to critical infrastructure (energy, water, financial systems, healthcare, transport) +- Risks to democratic processes and elections +- Risks enabling mass-casualty weapons development (CBRN) +- Cybersecurity risks including large-scale cyberattacks +- Risks to fundamental rights (discrimination at scale, manipulation) +- Societal risks (widespread disinformation, cognitive manipulation) + +### Obligation C — Incident Tracking, Documentation, and Reporting (Art. 55(1)(c)) + +Providers must track, document, and **report serious incidents** and possible corrective measures to the **AI Office** and, where relevant, to national competent authorities, **without undue delay** after becoming aware. + +**What constitutes a "serious incident" for GPAI models:** +- Any incident or malfunction of the GPAI model resulting in death or serious harm to a natural person +- Any disruption to critical infrastructure +- Any significant breach of fundamental rights +- Any event causing widespread harm (e.g., mass-scale disinformation) + +**Reporting channel:** Reports go to the AI Office. The AI Office coordinates with national authorities as appropriate. + +### Obligation D — Cybersecurity Protection (Art. 55(1)(d)) + +Providers must ensure an adequate level of **cybersecurity protection** for the GPAI model with systemic risk and its physical infrastructure. + +**Key measures:** +- Protection of model weights against unauthorised access, theft, or exfiltration +- Protection of training infrastructure against compromise +- Access controls for fine-tuning and model modification +- Monitoring for adversarial interference with deployed model APIs + +--- + +## Codes of Practice for GPAI Models (Article 56) + +### Purpose + +Codes of practice are the primary compliance tool for GPAI obligations before and alongside harmonised standards. They specify the practical methodology for meeting Arts. 53–55 obligations. + +### Development Process + +- Developed by the **AI Office** in collaboration with GPAI model providers, national competent authorities, civil society, academia, and independent experts +- **Timeline:** Codes of practice were required to be ready by **2 May 2025** +- Lead body: European AI Office + +### Current Status (as of 2026) + +The AI Office published the first version of the GPAI Code of Practice in May 2025. The code provides: +- Templates and methodology for technical documentation (Annex XI compliance) +- Methodology for training content summary (Annex XII compliance) +- Evaluation methodologies for systemic risk assessment +- Adversarial testing protocols and benchmarks +- Incident reporting procedures and templates + +**Compliance presumption:** Adherence to the code of practice creates a presumption of conformity with Arts. 53–55. Providers choosing not to adhere must demonstrate alternative adequate means of compliance to the AI Office's satisfaction. + +### Voluntary Participation for Minimal/Limited Risk AI + +Providers of minimal or limited risk AI systems may voluntarily adhere to codes of conduct (Art. 95). These are separate from the mandatory GPAI codes of practice and cover areas such as: +- Transparency and explainability beyond Art. 50 requirements +- Bias detection and mitigation +- Energy efficiency +- Human oversight in non-high-risk applications + +--- + +## GPAI Models in the High-Risk AI Value Chain + +When a GPAI model is integrated into a high-risk AI system, cooperation is required between the GPAI model provider (upstream) and the high-risk AI system provider (downstream): + +**GPAI model provider responsibilities when used in high-risk:** +- Provide information sufficient for the downstream provider to comply with Annex IV technical documentation +- Cooperate reasonably with downstream providers conducting conformity assessments +- Continue to maintain and update the model information made available (Art. 53(1)(b)) + +**Downstream high-risk AI system provider responsibilities:** +- The downstream provider remains responsible for their high-risk AI system's compliance +- They must conduct their own risk assessment and conformity assessment +- They cannot rely solely on the GPAI model provider's documentation + +**Contractual provisions:** Art. 25(4) provides that where both provider and deployer contribute to obligations, they may assign contractual responsibilities between themselves, but this does not remove statutory obligations to third parties and authorities. + +--- + +## Interaction with EU AI Act Governance for GPAI + +| Actor | Role in GPAI governance | +|-------|------------------------| +| AI Office | Primary supervisor of GPAI model providers; conducts investigations; issues codes of practice; accepts incident reports; can impose fines | +| Scientific Panel | Advises AI Office on systemic risk evaluations; can issue qualified alerts triggering Commission investigation | +| National Competent Authorities | May receive complaints about downstream GPAI systems; coordinate with AI Office | +| AI Board | Coordinates Member State positions on GPAI; issues opinions | + +**Complaint mechanism:** Any person or organisation can lodge a complaint with the AI Office about a GPAI model provider's non-compliance (Art. 63(1)). + +**AI Office investigation powers:** +- Request information and documentation +- Conduct interviews with provider personnel +- Commission independent evaluations of the model +- Impose interim measures where systemic risk requires urgent action +- Recommend fines to the Commission (which retains final decision on fines for GPAI) diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-high-risk-systems.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-high-risk-systems.md new file mode 100644 index 0000000..9954c98 --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-high-risk-systems.md @@ -0,0 +1,424 @@ +# EU AI Act — High-Risk AI Systems: Classification, Requirements, and Conformity Assessment + +**Regulation (EU) 2024/1689, Chapter III (Articles 6–51)** +**Art. 6(2) / Annex III applications from: 2 August 2026** +**Art. 6(1) / Annex I product AI from: 2 August 2027** + +--- + +## Part 1: Classification Rules (Article 6 and Annexes I, III) + +### Article 6(1) — AI as Safety Components in Regulated Products + +An AI system is **automatically high-risk** if **both** conditions are met: +1. The AI system is a safety component of a product covered by **Annex I EU harmonisation legislation** (or is itself the product), **AND** +2. The product must undergo a third-party conformity assessment under the applicable Annex I legislation + +**Annex I — Relevant Union Harmonisation Legislation:** +The AI Act's Annex I lists the specific EU laws that create this high-risk category. Key relevant laws include (non-exhaustive — see Annex I of Regulation (EU) 2024/1689 for the complete list): + +| Area | EU Law | +|------|--------| +| Machinery | Regulation (EU) 2023/1230 (Machinery Regulation) | +| Toys | Directive 2009/48/EC on toy safety | +| Recreational craft | Directive 2013/53/EU | +| Lifts | Directive 2014/33/EU | +| ATEX equipment | Directive 2014/34/EU | +| Radio equipment | Directive 2014/53/EU | +| Pressure equipment | Directive 2014/68/EU | +| Medical devices | Regulation (EU) 2017/745 | +| In vitro diagnostic medical devices | Regulation (EU) 2017/746 | +| Civil aviation — aerodromes, ATM/ANS, aircraft | Multiple EU regulations | +| Motor vehicles | Regulation (EU) 2018/858 and related delegated regulations | +| Agricultural and forestry vehicles | Regulation (EU) 167/2013; Regulation (EU) 168/2013 | +| Marine equipment | Directive 2014/90/EU | +| Rail systems interoperability and safety | Directives 2016/797 and (EU) 2016/798 | + +**Timeline for Art. 6(1) systems:** **2 August 2027.** + +### Article 6(2) — AI Systems Listed in Annex III + +AI systems listed in **Annex III** are high-risk **unless** one of the Article 6(3) exceptions applies. + +**Annex III — 8 High-Risk Use Case Areas:** + +--- + +#### Area 1: Biometrics + +**(a)** AI systems intended to be used for the **remote biometric identification** of natural persons — excluding biometric verification systems that confirm a person is who they claim to be. + +**(b)** AI systems intended to be used for **biometric categorisation** of natural persons for the purpose of deducing or inferring their race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation — **Note: deducing sensitive attributes IS ALSO prohibited under Art. 5(1)(c); this Annex III entry applies to categorization systems not falling into Art. 5** + +**(c)** AI systems intended to be used for **emotion recognition** of natural persons — **Note: emotion recognition in workplace/education IS ALSO prohibited under Art. 5(1)(g); this Annex III entry applies to systems in other contexts** + +--- + +#### Area 2: Critical Infrastructure + +AI systems intended to be used as safety components in the management and operation of: +- Critical **digital infrastructure** (e.g., internet exchange points, DNS resolvers, cloud infrastructure) +- **Road traffic** management +- Supply of **water, gas, heating, and electricity** + +--- + +#### Area 3: Education and Vocational Training + +**(a)** AI systems intended to be used to determine access or assignment to **educational and vocational training institutions** at all levels — e.g., admission systems. + +**(b)** AI systems intended to be used to **evaluate learning outcomes**, including when used to steer the learning process of persons — e.g., adaptive learning systems that make consequential assessments. + +**(c)** AI systems intended to be used to **assess the appropriate level** of education that an individual will be or has received, with implications for the future education path — e.g., educational tracking systems. + +**(d)** AI systems intended to be used for **monitoring and detecting prohibited behaviour** of students during tests — e.g., AI proctoring systems. + +--- + +#### Area 4: Employment, Workers Management, and Access to Self-Employment + +**(a)** AI systems intended to be used for **recruitment or selection** of natural persons, particularly for targeted job advertisements, for analysing and filtering job applications, and for evaluating candidates. + +**(b)** AI systems intended to be used to make decisions affecting the terms of employment, **promotion and termination** of work-related contractual relationships; to **allocate tasks** based on individual behaviour or personal traits or characteristics; and to **monitor and evaluate performance** and behaviour of persons in such relationships. + +--- + +#### Area 5: Access to and Enjoyment of Essential Private Services and Essential Public Services and Benefits + +**(a)** AI systems intended to be used by or on behalf of **public authorities** or by Union institutions to evaluate the eligibility of natural persons for essential public assistance benefits and services, including healthcare services, and to grant, reduce, revoke, or reclaim such benefits and services. + +**(b)** AI systems intended to be used to **evaluate the creditworthiness** of natural persons or to establish their credit score — **exception: AI systems used for purpose of detecting financial fraud**. + +**(c)** AI systems intended to be used for **risk assessment and pricing** in relation to natural persons in the cases of **life insurance** and **health insurance**. + +**(d)** AI systems intended to be used to **evaluate and classify emergency calls** by natural persons or to dispatch, or to establish priority in the dispatching of emergency first response services, including by fire, police, ambulance and emergency medical aid. + +--- + +#### Area 6: Law Enforcement + +**Note:** These are high-risk (not prohibited) when used in compliance with applicable law. + +**(a)** AI systems intended to be used by or on behalf of competent authorities, or by Union institutions, bodies, offices, or agencies to **assess the risk of natural persons** of becoming a victim of criminal offences. + +**(b)** AI systems intended to be used by or on behalf of competent authorities as **polygraphs and similar tools**. + +**(c)** AI systems intended to be used by or on behalf of competent authorities to assess the **reliability of evidence** in the course of investigation or prosecution of criminal offences or use in criminal justice. + +**(d)** AI systems intended to be used by or on behalf of competent authorities to **assess the risk of a natural person offending or reoffending** or the risk of potential victims of criminal offences — **does not apply to systems used solely for profiling or personality traits (Category 5 prohibition applies to those)**. + +**(e)** AI systems intended to be used by or on behalf of competent authorities for the **profiling of natural persons** as referred to in Art. 3(4) of Directive (EU) 2016/680 in the course of detection, investigation or prosecution of criminal offences or execution of criminal penalties, including police and public security. + +--- + +#### Area 7: Migration, Asylum, and Border Control Management + +**(a)** AI systems intended to be used by or on behalf of competent authorities as **polygraphs and similar tools**. + +**(b)** AI systems intended to be used by or on behalf of competent authorities to assess a **risk of irregular immigration** or health risk posed by natural persons seeking authorisation for entry into, or upon whom such authorisation has been granted to stay in, the territory of a Member State. + +**(c)** AI systems intended to be used by or on behalf of competent authorities in the **examination of applications** for asylum, visa, and residence permits and associated complaints with regard to the eligibility of the natural persons applying for a status and in the assessment of risks. + +**(d)** AI systems intended to be used for the **detection, recognition, or identification of natural persons** by or on behalf of competent authorities in the context of border management — **exception: verification of travel documents**. + +--- + +#### Area 8: Administration of Justice and Democratic Processes + +**(a)** AI systems intended to be used by or on behalf of **judicial authorities** to assist in **researching and interpreting facts and the law** and in applying the law to a concrete set of facts, or to be used in a similar way in alternative dispute resolution. + +**(b)** AI systems intended to be used for **influencing** the outcome of an election or referendum or the voting behaviour of natural persons in elections or referenda — **exception: AI tools used to organise, optimise and structure political campaigns from an administrative or logistical perspective that do not directly interact with persons**. + +--- + +### Article 6(3) — Exceptions to Annex III High-Risk Classification + +An Annex III AI system is **NOT high-risk** if it meets **at least one** of the following four criteria: + +**(a)** The AI system performs a **narrow procedural task** — it executes a specific, limited procedure with well-defined inputs and outputs, without broader inference or decision-making capability. + +**(b)** The AI system **improves the result of a previously completed human activity** — it enhances, summarises, or processes results of a human task already completed (not substituting human judgment). + +**(c)** The AI system **detects decision-making patterns or deviations** from prior decision-making patterns and is **not meant to replace or influence the previously completed human assessment** without proper human review — it flags anomalies for human review without autonomously affecting outcomes. + +**(d)** The AI system performs a **preparatory task** to an assessment relevant for the purpose of the use cases listed in Annex III — it prepares data or material for a human-led assessment without itself conducting the assessment. + +**Critical override:** If the AI system **profiles individuals** (automated processing of personal data to evaluate aspects of a natural person's life — Art. 3(4) of GDPR-adjacent definition), **none of the four exceptions apply** — the system remains high-risk regardless. + +**Documentation obligation:** Providers who determine that their Annex III system is not high-risk under Art. 6(3) must document that assessment before placing on the market or putting into service (Art. 6(4)). + +--- + +## Part 2: Requirements for High-Risk AI Systems (Articles 8–15) + +### Article 9 — Risk Management System + +Providers must establish, implement, document, and maintain a risk management system for high-risk AI systems. The system must: + +**Continuity:** Be a continuous, iterative process running throughout the entire lifecycle of the AI system. + +**Components (Art. 9(2)):** +- Identification and analysis of all known and reasonably foreseeable risks that the high-risk AI system can pose to health, safety, or fundamental rights +- Estimation and evaluation of risks that may emerge from intended use and from reasonably foreseeable misuse +- Evaluation of risks from post-market data (Art. 72) +- Adoption of appropriate and targeted risk management measures + +**Risk management measures (Art. 9(4)):** Measures most appropriate to each risk must be adopted. Priority: configure the AI system to eliminate/reduce risks through design; for residual risks, adequate information in instructions for use; training measures. + +**Testing (Art. 9(5)):** High-risk AI systems must be tested to identify the most appropriate risk management measures and ensure they are effective. Testing must include against preliminary defined metrics and probabilistic thresholds, and reflect the intended purpose and reasonably foreseeable misuse. + +**Testing requirements specific to biometric identification:** Additional testing against discriminatory outputs is required. + +**Documentation:** All risk management measures taken, test results, and residual risks must be documented as part of the technical documentation (Annex IV). + +--- + +### Article 10 — Data and Data Governance + +Applies specifically to AI systems involving model training with data. + +**Training, validation, and testing data requirements (Art. 10(2)):** +- Subject to appropriate data governance and management practices +- **Relevant** for the stated intended purpose +- **Representative** — to the extent possible, of the intended deployment population and context +- **Free of errors** — to the best extent possible — and **complete** with respect to the intended purpose +- Have regard to the properties, characteristics and limitations of the data, including possible bias + +**Bias examination (Art. 10(5)):** Where necessary to detect and address potential bias that may lead to discrimination of persons — especially in sensitive use cases (biometrics, employment, education, public services) — data governance must include examination of possible bias. + +**Special category data for bias detection (Art. 10(5) second sentence):** Processing of special categories of personal data (Art. 9 GDPR) is permitted strictly for the purpose of ensuring bias monitoring, detection, and correction in high-risk AI systems, subject to appropriate safeguards. + +**Data protection:** All data governance must comply with applicable data protection law, including GDPR. The AI Act does not override GDPR — both apply. + +--- + +### Article 11 — Technical Documentation + +Providers must draw up complete technical documentation **before** placing the AI system on the market or putting it into service. Documentation must be: +- Kept up to date throughout the lifecycle +- Retained for **10 years** after placing on market / putting into service, or longer if sector-specific law requires +- Made available to national competent authorities on request + +**Annex IV — Required contents of Technical Documentation:** + +1. General description of the high-risk AI system: + - Intended purpose; version information; hardware on which it is intended to run + - Explanation of how the system interacts with other systems or hardware + - Form in which the system is placed on market (software, embedded in hardware, API, etc.) + +2. Description of components, algorithms, and models: + - Key design choices and assumptions; description of model architecture and logic + - Input data specifications; training data description (type, source, size) + - Training methodology; validation and testing methodology + +3. Detailed information of monitoring, operation, and control of the system: + - Input data requirements; measures to examine fitness of intended purpose + - Monitoring and control by deployers; technical measures for human oversight (Art. 14) + +4. Description of the risk management system (Art. 9) and outcomes + +5. Changes to the system and its performance over the lifecycle; maintenance intervals + +6. List of standards applied; where standards not applied, description of solutions adopted + +7. EU declaration of conformity (Art. 47) + +8. Post-market monitoring plan (Art. 72, Annex VII framework) + +--- + +### Article 12 — Record-Keeping / Logging + +High-risk AI systems must be built with **automatic logging capability** to enable monitoring throughout operation. The logging must cover: +- Period of each use of the system (start/end date and time of use) +- Reference database against which input data was checked (for biometric identification systems) +- The input data that led to queries submitted to, or which led to the results output by, the system — to the extent technically feasible without compromising commercially sensitive information +- Identity of the natural persons involved in verification (for biometric systems) + +**Log retention:** Deployers must retain logs for at least **6 months** unless applicable sector-specific law requires longer retention. + +--- + +### Article 13 — Transparency and Provision of Information to Deployers + +Providers must ensure high-risk AI systems are transparent enough to enable deployers to comply with their obligations. This requires: + +**Instructions for use** provided with the AI system — clear, concise, complete — covering: +- Identity and contact details of the provider (Art. 13(3)(a)) +- Intended purpose, level of accuracy, levels of robustness and cybersecurity (Art. 13(3)(b)) +- Human oversight measures and interface design (Art. 13(3)(c)) +- Characteristics, capabilities, and limitations of the system: + - Circumstances in which the system may fail or produce inaccurate outputs + - Circumstances in which the system may be subject to deployment risks + - The performance as regards different persons or groups of persons + - Input data specifications + - Degree of accuracy for specific persons or groups +- Description of changes to performance through use (system drift) +- Where relevant, operational constraints + +--- + +### Article 14 — Human Oversight + +High-risk AI systems must be designed and developed to enable effective human oversight during their use. This requires: + +**Technical measures (Art. 14(3)):** +- The system can be overseen by natural persons to whom the deployer has assigned responsibility +- Operators can understand the system's capabilities and limitations +- Operators can understand when the system is producing outputs of questionable reliability +- Operators can disregard, override, or reverse the system's output +- Operators can intervene or interrupt the AI system + +**Biometric-specific oversight (Art. 14(5)):** +For remote biometric identification systems, human oversight must at minimum include: +- That no identifying action is taken with regard to a given person if not confirmed by at least two natural persons +- That identifying actions must be based on objective evidence and actual engagement with the identified person (not solely on the output of the AI system) + +**Provider vs deployer responsibility:** Providers must design the system with technical capacity for human oversight. Deployers must actually implement and exercise oversight in practice (Art. 26). + +--- + +### Article 15 — Accuracy, Robustness, and Cybersecurity + +High-risk AI systems must achieve **appropriate levels** of accuracy, robustness, and cybersecurity throughout their lifecycle. + +**Accuracy:** +- Must be declared in the technical documentation and instructions for use +- Accuracy levels and relevant metrics must be appropriate to the intended purpose +- Combined human-AI performance metrics may be used where relevant + +**Robustness:** +- Must be resilient to errors, faults, or inconsistencies that may occur within the system or its environment during operation +- Technical redundancy measures where appropriate (failsafe, error handling) + +**Cybersecurity:** +- Technically robust against attempts by unauthorised parties to alter the system's use or performance, to manipulate training or operational data, or to exploit model vulnerabilities (adversarial attacks, data poisoning, model inversion, prompt injection) +- Must include measures to prevent and respond to cybersecurity threats proportionate to risks + +--- + +### Article 16 — Summary of Provider Obligations + +Article 16 serves as a summary enumeration of provider obligations: +(a) Ensure compliance with requirements in Arts. 8–15 +(b) Have a quality management system (Art. 17) +(c) Draw up technical documentation (Art. 11) +(d) Keep records and logs (Arts. 12, 20) +(e) Undertake conformity assessment procedure before placing on market (Art. 43) +(f) Register in EU database (Art. 49) +(g) Take corrective actions when non-compliance identified (Art. 21) +(h) Inform national authorities of serious incidents (Art. 73) +(i) Affix CE marking (Art. 48) +(j) Ensure AI system accompanied by EU declaration of conformity (Art. 47) + +--- + +### Article 17 — Quality Management System + +Providers must implement a **quality management system (QMS)** covering all phases of the high-risk AI system lifecycle. + +**QMS must address (Art. 17(1)):** +- Regulatory compliance strategy (including conformity assessment procedures and standards) +- Techniques for design, design control, and design verification +- Systems and procedures for data management (training, validation, testing data) +- Risk management system (Art. 9) +- Post-market monitoring plan (Art. 72) +- Incident reporting procedures (Art. 73) +- Handling of corrections and corrective actions +- Procedures for security and access +- AI literacy and training of personnel + +**Documentation:** QMS must be documented systematically and in an orderly manner — written policies, procedures, and records. Records to be retained for **10 years** after placing on market or putting into service. + +**Proportionality:** QMS may be integrated into an existing quality management system (e.g., ISO 9001, ISO 13485 for medical devices). For SMEs, documentation requirements are proportionate to organisational size and complexity. + +--- + +## Part 3: Conformity Assessment Routes (Article 43) + +### Route 1 — Internal Conformity Assessment (Art. 43(2)) + +**Applicable to:** All high-risk AI systems under Annex III **except** remote biometric identification systems. + +**Process:** +1. Verify compliance against requirements in Arts. 8–15 +2. Ensure quality management system in place (Art. 17) +3. Complete Annex IV technical documentation +4. Draw up EU declaration of conformity (Annex V format) +5. Affix CE marking (Annex VI marking rules) +6. Register in EU database before placing on market (Art. 49) +7. Maintain records; implement post-market monitoring + +### Route 2 — Third-Party Conformity Assessment (Notified Body) (Art. 43(1)) + +**Mandatory for:** +- High-risk AI systems that are **safety components** in Annex I-regulated products where those laws require third-party assessment +- **Remote biometric identification systems** listed under Annex III, Area 1(a) — where no harmonised standard covering all requirements exists + +**Process:** +1. Identify an accredited Notified Body designated under applicable EU law +2. Submit for assessment: technical documentation, risk management records, testing evidence, QMS documentation +3. Notified Body conducts: documentation review, technical assessment, quality system audit, testing review +4. Upon successful assessment: Notified Body issues EU technical assessment certificate +5. Provider draws up EU declaration of conformity and affixes CE marking +6. Register in EU database + +**Notified Body obligations (Arts. 38–44):** +- Must be accredited by National Accreditation Bodies (NABs) designated by Member States +- Must maintain independence, impartiality, and technical competence +- Must not have conflicts of interest with providers whose systems they assess +- Must maintain professional secrecy +- Notified Body decisions can be reviewed by NCAs + +### Harmonised Standards and Common Specifications + +**Presumption of conformity (Art. 40):** High-risk AI systems conforming to harmonised European standards (EN standards developed under EU AI Act standardisation mandate to CEN/CENELEC) benefit from a presumption of conformity with the corresponding requirements. + +**Common specifications (Art. 41):** Where harmonised standards are absent or insufficient, the Commission may adopt implementing acts setting out common technical specifications. These carry the same presumption of conformity. + +**Note on current status (as of 2026):** CEN/CENELEC JTC 21 is developing harmonised standards for the EU AI Act. ISO/IEC AI standards (such as ISO/IEC 42001 for AI management systems) are referenced as relevant but are not yet formally designated as harmonised standards under the AI Act. + +--- + +## Part 4: CE Marking and Declaration of Conformity + +### EU Declaration of Conformity (Art. 47, Annex V) + +The EU declaration of conformity must contain: +- Name and address of the provider (and authorised representative where applicable) +- Statement that the AI system is in conformity with the EU AI Act +- Name, address, and identification number of the Notified Body (where applicable) +- Reference to harmonised standards or common specifications applied +- Where applicable, identification of other Union legislation complied with +- Provider's name, place, and date of issue; signature + +### CE Marking (Arts. 48, 49) + +- CE marking must be affixed visibly, legibly, and indelibly on the AI system or on the packaging +- For AI systems that are entirely software: CE marking must be affixed to the accompanying documentation or information +- The CE marking must be followed by the identification number of the Notified Body (where applicable) +- CE marking must not be affixed before conformity assessment is completed and the EU declaration of conformity drawn up + +--- + +## Part 5: EU Database for Stand-Alone High-Risk AI Systems (Art. 49) + +**Before placing on the market or putting into service**, providers of stand-alone high-risk AI systems (not embedded in Annex I products) must register in the **EU database** established under Art. 71. + +**Registration information required (as per EU database requirements):** +- Provider name, address, and contact details +- Categories of natural persons affected +- Member States in which system is or will be placed on market +- Name and description of the AI system +- Intended purpose, categories of persons and groups affected +- Description of capabilities and limitations +- Performance levels, accuracy, robustness +- Known limitations and circumstances affecting performance +- Training data characteristics +- Risk management measures taken +- Conformity assessment procedure followed and certificate reference +- Date of registration + +**Public access:** The EU database is publicly accessible. Confidential business information may be protected from disclosure per Art. 71(4). + +**Deployer registration:** Deployers of high-risk AI systems listed in Annex III and used by public authorities must also register before use (Art. 49(2)). diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-obligations-templates.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-obligations-templates.md new file mode 100644 index 0000000..df0b072 --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-obligations-templates.md @@ -0,0 +1,415 @@ +# EU AI Act — Obligations, Checklists, and Document Templates + +**Regulation (EU) 2024/1689** +This reference provides structured checklists, document templates, and gap analysis tools for EU AI Act compliance. + +--- + +## Part 1: Provider Compliance Checklist (High-Risk AI Systems) + +Use this checklist to assess compliance status for a provider of a high-risk AI system. For each item, record status: Not Started (NS), In Progress (IP), Completed (C), Not Applicable (N/A). + +### Phase 1: Pre-Market — Before Placing on Market or Putting into Service + +| # | Obligation | Article(s) | Status | Evidence Required | +|---|-----------|------------|--------|------------------| +| 1.1 | Risk management system established, documented, and operational | Art. 9 | | Risk management plan, risk register, residual risk documentation | +| 1.2 | Data governance procedures in place for training, validation, and test data | Art. 10 | | Data governance policy, dataset documentation, bias evaluation records | +| 1.3 | Technical documentation (Annex IV) drawn up and complete | Art. 11 | | Annex IV document package | +| 1.4 | Logging/record-keeping capability built into the AI system | Art. 12 | | System architecture documentation showing logging; test logs | +| 1.5 | Instructions for use prepared and accompanying the system | Art. 13 | | Instructions for use document | +| 1.6 | Human oversight technical measures designed into the system | Art. 14 | | Human oversight specification; UI/UX documentation showing override controls | +| 1.7 | Accuracy, robustness, and cybersecurity levels determined and documented | Art. 15 | | Accuracy benchmark results; robustness testing records; cybersecurity assessment | +| 1.8 | Quality management system (QMS) established | Art. 17 | | QMS procedure documentation; QMS records | +| 1.9 | Conformity assessment route determined (internal or third-party) | Art. 43 | | Conformity assessment decision document | +| 1.10 | Conformity assessment completed | Art. 43 | | Conformity assessment report; Notified Body certificate (if applicable) | +| 1.11 | EU declaration of conformity (Annex V) drawn up | Art. 47 | | Signed EU declaration of conformity | +| 1.12 | CE marking affixed | Art. 48 | | Product/documentation bearing CE marking | +| 1.13 | Registration in EU database completed | Art. 49 | | EU database registration confirmation and reference number | +| 1.14 | Authorised representative in EU designated (if provider is outside EU) | Art. 25 | | Authorised representative agreement; details registered | +| 1.15 | AI literacy measures in place for relevant personnel | Art. 4 | | Training records; competency assessments | + +### Phase 2: Post-Market — After Placing on Market + +| # | Obligation | Article(s) | Status | Evidence Required | +|---|-----------|------------|--------|------------------| +| 2.1 | Post-market monitoring plan in operation | Art. 72 | | Post-market monitoring plan; monitoring data; review records | +| 2.2 | Logs retained for minimum 6 months (where technically feasible) | Art. 20 | | Log retention configuration; archived logs | +| 2.3 | Incident reporting procedure in place | Art. 73 | | Incident response procedure; incident log | +| 2.4 | Serious incidents reported to national authorities within required timeframes | Art. 73 | | Incident reports submitted; acknowledgements from authorities | +| 2.5 | Corrective actions taken when non-conformities identified | Art. 21 | | Non-conformity log; corrective action records | +| 2.6 | Technical documentation and records kept for 10 years | Arts. 11, 17 | | Document retention records | +| 2.7 | Re-assessment performed after substantial modification | Art. 19 | | Modification assessment record; updated conformity assessment | +| 2.8 | Cooperation with national competent authorities when requested | Art. 23 | | Correspondence with authorities; access logs provided | + +--- + +## Part 2: Deployer Compliance Checklist (High-Risk AI Systems) + +Use this checklist to assess compliance status for a deployer of a high-risk AI system. + +| # | Obligation | Article(s) | Status | Evidence Required | +|---|-----------|------------|--------|------------------| +| D1 | AI system is used in accordance with provider's instructions for use | Art. 26(1) | | Usage policy; training records for users | +| D2 | Human oversight implemented — designated, competent, trained persons | Art. 26(2) | | Role assignments; training records; oversight procedures | +| D3 | Technical and organisational measures for human oversight in place | Art. 26(3) | | HO procedure; system configuration records | +| D4 | AI literacy measures implemented for relevant staff | Art. 4, Art. 26(5) | | Training records; competency assessments | +| D5 | AI system/use case monitored for risks; risks reported to provider | Art. 26(4) | | Monitoring log; incident/risk reports to provider | +| D6 | Fundamental Rights Impact Assessment (FRIA) conducted (Annex III systems) | Art. 27 | | Completed FRIA document; sign-off by senior management | +| D7 | Employees and their representatives informed before deployment (if system affects them) | Art. 26(7) | | Communication records; works council/employee rep consultation records | +| D8 | Registration in EU database completed (public authority deployers of Annex III systems) | Art. 49(2) | | EU database registration reference | +| D9 | Serious incidents reported to national market surveillance authorities | Art. 73 | | Incident reports; authority acknowledgements | +| D10 | Logs retained for minimum 6 months | Art. 26(6) | | Log retention configuration; archived logs | +| D11 | AI system not used for purposes beyond intended purpose without re-assessment | Art. 26(1) | | Use case documentation; review records | + +--- + +## Part 3: GPAI Model Provider Compliance Checklist + +### Standard GPAI Models (Art. 53) + +| # | Obligation | Article | Status | Evidence Required | +|---|-----------|---------|--------|------------------| +| G1 | Technical documentation (Annex XI) drawn up and maintained | Art. 53(1)(a) | | Annex XI documentation | +| G2 | Information package for downstream providers (Annex XII) available | Art. 53(1)(b) | | Model card, API documentation, Annex XII document | +| G3 | Copyright compliance policy established; arts. 4(3) opt-outs respected | Art. 53(1)(c) | | Copyright policy; opt-out detection/compliance records | +| G4 | Training content summary published and current | Art. 53(1)(d) | | Published training summary | +| G5 | Notification to Commission within 2 weeks if compute exceeds 10^25 FLOPs | Art. 52 | | Notification confirmation | +| G6 | Codes of practice adherence determined (or alternative compliance approach documented) | Art. 56 | | Code of practice sign-up; or alternative compliance statement | + +### Additional for Open-Weight GPAI Models (Art. 54) + +| # | Obligation | Article | Status | Evidence Required | +|---|-----------|---------|--------|------------------| +| OW1 | Parameters/weights publicly available | Art. 54 | | Model release; licence | +| OW2 | Model architecture publicly available | Art. 54 | | Published architecture documentation | +| OW3 | Copyright policy in place (same as G3) | Art. 54 | | As G3 | +| OW4 | Training summary published (same as G4) | Art. 54 | | As G4 | +| OW5 | If systemic risk designation exists or compute > 10^25 FLOPs: full Art. 53 + Art. 55 apply | Art. 54(2) | | Re-run full checklist | + +### Additional for GPAI Models with Systemic Risk (Art. 55) + +| # | Obligation | Article | Status | Evidence Required | +|---|-----------|---------|--------|------------------| +| SR1 | Model evaluations conducted including adversarial testing | Art. 55(1)(a) | | Evaluation reports; red-teaming records; adversarial test results | +| SR2 | Systemic risks assessed and mitigated | Art. 55(1)(b) | | Systemic risk assessment; risk mitigation plan | +| SR3 | Serious incident tracking, documentation, and reporting process in place | Art. 55(1)(c) | | Incident tracking log; reports to AI Office | +| SR4 | Cybersecurity protection measures for model and infrastructure | Art. 55(1)(d) | | Cybersecurity assessment; access controls; penetration test results | + +--- + +## Part 4: Fundamental Rights Impact Assessment (FRIA) Template (Article 27) + +**Template: Fundamental Rights Impact Assessment** +**Pursuant to Article 27, Regulation (EU) 2024/1689 (EU AI Act)** + +--- + +### Section 1: Administrative Information + +| Field | Value | +|-------|-------| +| Deployer organisation name | | +| Deployer address | | +| Contact person for this FRIA | | +| Contact person email/phone | | +| AI system name | | +| AI system version/release | | +| Provider name | | +| Intended purpose of deployment | | +| Date of FRIA completion | | +| Review date | | +| Approved by (senior management) | | +| Title of approving officer | | + +--- + +### Section 2: Description of Deployment Context + +**2.1 Description of the process in which the high-risk AI system will be used:** +[Describe in detail the business process, workflow, or function in which the AI system will be used. Include the decision-making process it supports or automates.] + +**2.2 Time period of intended use:** +[From date — to date, or "ongoing permanent deployment"] + +**2.3 Frequency of use:** +[How often will the system be used? How many interactions/decisions per day/week/month?] + +**2.4 Geographic scope:** +[Countries, regions, or specific locations where the system will be deployed] + +**2.5 Categories of natural persons who will be affected:** +Identify all groups: + +| Category of Persons | Direct Impact | Indirect Impact | Number Affected (approx.) | +|--------------------|--------------|----------------|--------------------------| +| [Insert group — e.g., job applicants] | Yes/No | Yes/No | [Number/estimate] | +| [Insert group — e.g., current employees] | Yes/No | Yes/No | | +| [Insert group — e.g., customers] | Yes/No | Yes/No | | +| [Insert vulnerable group — e.g., persons with disabilities] | Yes/No | Yes/No | | +| [Insert vulnerable group — e.g., minors] | Yes/No | Yes/No | | + +--- + +### Section 3: Fundamental Rights Assessment + +For each EU Charter article relevant to the deployment, assess the risk: + +**Likelihood scale:** 1 = Highly unlikely, 2 = Unlikely, 3 = Possible, 4 = Likely, 5 = Highly likely +**Severity scale:** 1 = Negligible, 2 = Minor, 3 = Moderate, 4 = Significant, 5 = Severe/Irreversible + +| Charter Article | Fundamental Right | Potential Risk | Likelihood (1-5) | Severity (1-5) | Risk Level | Affected Group | +|----------------|------------------|---------------|-----------------|---------------|------------|---------------| +| Art. 1 | Human dignity | | | | | | +| Art. 3 | Physical and mental integrity | | | | | | +| Art. 7 | Respect for private and family life | | | | | | +| Art. 8 | Protection of personal data | | | | | | +| Art. 11 | Freedom of expression and information | | | | | | +| Art. 14 | Right to education | | | | | | +| Art. 15 | Freedom to choose an occupation and engage in work | | | | | | +| Art. 17 | Right to property | | | | | | +| Art. 20 | Equality before the law | | | | | | +| Art. 21 | Non-discrimination (race, sex, religion, disability, age, sexual orientation, etc.) | | | | | | +| Art. 22 | Cultural, religious, and linguistic diversity | | | | | | +| Art. 23 | Equality between women and men | | | | | | +| Art. 24 | Rights of the child | | | | | | +| Art. 25 | Rights of the elderly | | | | | | +| Art. 26 | Integration of persons with disabilities | | | | | | +| Art. 38 | Consumer protection | | | | | | +| Art. 41 | Right to good administration | | | | | | +| Art. 47 | Right to an effective remedy and fair trial | | | | | | +| Art. 48 | Presumption of innocence and right of defence | | | | | | + +**Overall Risk Rating:** [ ] Low [ ] Medium [ ] High + +--- + +### Section 4: Risk Mitigation Measures + +For each risk identified as Medium or High in Section 3: + +| Risk Reference | Risk Description | Mitigation Measure | Responsible Party | Implementation Date | Residual Risk | Monitoring Approach | +|---------------|----------------|-------------------|------------------|--------------------|--------------|--------------------| +| | | | | | | | + +--- + +### Section 5: Consultation and Stakeholder Engagement + +**5.1 Internal consultation:** +[Record who was consulted within the deployer organisation — DPO, legal, HR, IT, affected business units] + +| Stakeholder | Role | Date Consulted | Input Received | +|-------------|------|---------------|----------------| +| | | | | + +**5.2 External consultation (where applicable):** +[Record any external consultation — e.g., works council, employee representatives, external legal advice] + +**5.3 Employee / works council consultation (Art. 26(7)):** +[ ] Employees and their representatives were informed of the intended deployment before deployment +[ ] Works council / employee representative body was consulted on [date] + +--- + +### Section 6: Data Protection Alignment + +**6.1 Is a DPIA (under GDPR Art. 35) required for this deployment?** +[ ] Yes — DPIA reference: ________________ +[ ] No — Reason: ________________ + +**6.2 Legal basis for processing personal data:** +[ ] Art. 6(1)(a) GDPR — Consent +[ ] Art. 6(1)(b) — Contract +[ ] Art. 6(1)(c) — Legal obligation +[ ] Art. 6(1)(e) — Public task +[ ] Art. 6(1)(f) — Legitimate interests +[ ] Other: ________________ + +**6.3 Special category data involved?** +[ ] Yes — Categories: ________________ — Legal basis under Art. 9(2) GDPR: ________________ +[ ] No + +--- + +### Section 7: Approval and Sign-Off + +| Role | Name | Signature | Date | +|------|------|-----------|------| +| Senior management approver | | | | +| Data Protection Officer (review) | | | | +| Legal/Compliance review | | | | +| AI Literacy / HR confirmation | | | | + +**Next review date:** ________________ +**Trigger events for early review:** Substantial change to AI system; change in intended use; new risk information; significant incident; regulatory guidance update. + +--- + +## Part 5: Technical Documentation Outline (Annex IV Compliance) + +Use this outline to structure the technical documentation required by Article 11 and Annex IV. + +### Document Control Block (for each technical documentation package) + +| Field | Value | +|-------|-------| +| AI System Name | | +| Version | | +| Provider Name | | +| Document ID | | +| Version | 1.0 | +| Classification | Confidential — for regulatory and authorised commercial use | +| Prepared by | | +| Approved by | | +| Date | | +| Review date | | +| Retention period | 10 years from date of placing on market | + +### Required Sections (Annex IV) + +**Section 1 — General Description** +- 1.1 Intended purpose (complete specification per Art. 3(11)) +- 1.2 Version, date of development, and history +- 1.3 Names and contact details of provider (and authorised representative where applicable) +- 1.4 Hardware on which system is intended to operate +- 1.5 How system interacts with hardware, software, or other AI systems +- 1.6 Form in which the AI system is placed on market (embedded, software, API, SaaS, etc.) +- 1.7 Natural persons affected by the system and use cases + +**Section 2 — Description of the AI System and Development Process** +- 2.1 Development methodologies and third parties involved +- 2.2 Design specifications including general logic, key design choices and assumptions +- 2.3 Architecture of the system — description of components, modules, models +- 2.4 Training methodology and key decisions in training +- 2.5 Training data — type, source, size, selection criteria, collection methodology +- 2.6 Validation data — type, source, size +- 2.7 Testing data — type, source, size, test methodology +- 2.8 Human oversight technical measures designed in (Art. 14) +- 2.9 Pre-determined changes to the AI system and its performance (anticipated system drift) + +**Section 3 — Risk Management System Records** +- 3.1 Risk management system description (Art. 9 process) +- 3.2 Known and foreseeable risks identified +- 3.3 Risk mitigation measures adopted +- 3.4 Residual risks remaining after mitigation +- 3.5 Testing results — metrics, benchmarks, methodologies + +**Section 4 — Accuracy, Robustness, and Cybersecurity** +- 4.1 Accuracy levels and metrics +- 4.2 Performance across different persons or groups of persons +- 4.3 Robustness testing results +- 4.4 Cybersecurity measures and testing results + +**Section 5 — Changes Made After Initial Placing on Market** +- 5.1 Record of all changes/updates and dates +- 5.2 Assessment of whether each change constitutes a substantial modification +- 5.3 Updated conformity assessment records where substantial modification identified + +**Section 6 — Standards and Specifications Applied** +- 6.1 Harmonised standards applied (with version numbers) +- 6.2 Common specifications applied +- 6.3 Where standards not applied: description of technical solutions adopted to meet requirements +- 6.4 Other relevant industry standards or codes of practice + +**Section 7 — Referenced Documents** +- 7.1 EU Declaration of Conformity (Annex V) +- 7.2 Post-market monitoring plan (Annex VII framework) +- 7.3 Instructions for use +- 7.4 Quality Management System documentation reference + +--- + +## Part 6: EU Declaration of Conformity (Annex V Format) + +**EU DECLARATION OF CONFORMITY** +*(Pursuant to Article 47 and Annex V, Regulation (EU) 2024/1689)* + +--- + +**No.** [Unique reference number] + +**1. AI system name and type:** +[Name of AI system; model/type reference] + +**2. Provider name and address:** +[Full legal name and registered address] + +**3. Authorised representative (where applicable):** +[Name and address of authorised representative in the Union] + +**4. This declaration of conformity is issued under the sole responsibility of the provider.** + +**5. Object of the declaration:** +[Brief description of the AI system and its intended purpose] + +**6. The object of the declaration described above is in conformity with the relevant Union harmonisation legislation:** +Regulation (EU) 2024/1689 (Artificial Intelligence Act) + +**7. References to the relevant harmonised standards used or references to any other technical specifications in relation to which conformity is declared:** +[List harmonised EN standards applied, e.g., EN ISO/IEC 42001, EN standards under AI Act mandate] +[Or: Description of alternative technical specifications used per Art. 41] + +**8. Where applicable, name, address, and identification number of the Notified Body that carried out the conformity assessment procedure:** +[Notified Body name; EU notified body number; certificate reference and date] + +**9. Additional information (where applicable):** +[Any additional compliance declarations or conditions] + +**Signed for and on behalf of:** +[Name and company, place and date, signature] +[Function/title of signatory] + +--- + +## Part 7: Serious Incident Report Template (Article 73) + +**HIGH-RISK AI SYSTEM — SERIOUS INCIDENT REPORT** +*(Pursuant to Article 73, Regulation (EU) 2024/1689)* + +**Report type:** [ ] Initial report [ ] Follow-up report [ ] Final report + +**Submission date:** ________________ +**Reference number** (if follow-up): ________________ + +**Section A — Provider Information** +- Provider name and address: +- Contact person name, role, phone, and email: +- AI system name and version: +- EU database registration number: + +**Section B — Incident Description** +- Date and time incident first identified: +- Date and time incident occurred (if different): +- Location/Member State(s) affected: +- Nature of the incident (describe what happened): +- Type of serious incident (tick all that apply): + - [ ] Death or risk of death + - [ ] Serious injury to health + - [ ] Serious irreversible disruption to management/operation of critical infrastructure + - [ ] Infringement of fundamental rights obligations + - [ ] Serious property damage or other significant harm +- Number of persons affected (if known): +- Description of affected persons: + +**Section C — AI System Actions Preceding the Incident** +- What was the AI system doing at the time of the incident? +- What input data was processed? +- What output did the AI system generate? +- Was the AI system operating within its intended purpose? + +**Section D — Immediate Corrective Actions Taken** +- Immediate steps taken to stop/mitigate harm: +- Has the AI system been taken offline/suspended? [ ] Yes [ ] No +- Actions to prevent recurrence (preliminary): +- Has affected person(s) been notified? [ ] Yes [ ] No [ ] Not applicable + +**Section E — Preliminary Hypothesis on Cause** +[Describe what is currently believed to have caused the incident. Mark as preliminary if investigation is ongoing.] + +**Section F — Follow-Up Plans** +- Expected investigation completion date: +- Next reporting milestone: +- Contact for further communication with authorities: + +**Signed by:** ________________ **Title:** ________________ **Date:** ________________ diff --git a/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-prohibited-practices.md b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-prohibited-practices.md new file mode 100644 index 0000000..170194f --- /dev/null +++ b/plugins/eu-ai-act/skills/eu-ai-act/references/eu-ai-act-prohibited-practices.md @@ -0,0 +1,226 @@ +# EU AI Act — Article 5: Prohibited AI Practices + +**Regulation (EU) 2024/1689, Article 5** +**Applicable from: 2 February 2025** + +This reference covers all eight categories of AI practices prohibited under Article 5 of the EU AI Act. These are practices classified as posing unacceptable risk. Any AI system falling into these categories must not be placed on the EU market, put into service, or used in the EU. + +--- + +## Overview + +Article 5 prohibits the placing on the market, putting into service, or use of AI systems that deploy specific high-risk techniques or serve specific harmful purposes. Violations carry the highest penalty tier: up to **€35 million or 7% of global annual turnover**, whichever is higher (Art. 99(3)). + +The eight prohibited categories are: + +--- + +## Category 1 — Subliminal, Manipulative, or Deceptive Techniques (Art. 5(1)(a)) + +**Prohibited:** AI systems that deploy subliminal techniques beyond a person's consciousness, or purposefully manipulative or deceptive techniques, with the objective or effect of materially distorting the behaviour of a person or a group of persons by appreciably impairing their ability to make an informed decision, thereby causing them or another person significant harm. + +**Key elements that must ALL be present for the prohibition to apply:** +- The technique operates below the threshold of consciousness (subliminal) OR is deliberately manipulative/deceptive +- The objective or effect is to materially distort the person's behaviour +- This appreciably impairs the ability to make an informed decision +- Significant harm results or is likely to result (to the person or another person) + +**Examples of potentially prohibited systems:** +- AI voice systems using imperceptible audio signals to induce purchasing decisions +- AI recommendation engines deliberately designed to exploit cognitive biases to drive harmful outcomes +- AI chatbots impersonating humans without disclosure to induce financial commitments + +**What is NOT prohibited:** +- Legitimate advertising and marketing that uses evidence-based persuasion techniques without subliminal components +- AI systems that provide information enabling informed decision-making +- AI that nudges behaviour with full transparency and in a non-deceptive manner + +--- + +## Category 2 — Exploitation of Vulnerabilities (Art. 5(1)(b)) + +**Prohibited:** AI systems that exploit any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability, or specific social or economic situation, with the objective or effect of materially distorting the behaviour of that person or a person belonging to that group in a manner that causes or is likely to cause significant harm. + +**Key elements:** +- Targets vulnerabilities arising from age (e.g., children, elderly), disability, or specific social/economic situation +- The exploitation has the objective or effect of materially distorting behaviour +- The distortion causes or is likely to cause significant harm + +**Examples of potentially prohibited systems:** +- AI systems targeting children with manipulative dark patterns to induce in-app purchases +- AI debt collection systems targeting financially distressed individuals with psychologically manipulative messaging +- AI systems exploiting cognitive impairments of elderly users to obtain consent or financial commitments + +**Relationship to Category 1:** The key distinction is that Category 1 focuses on technique (subliminal/deceptive), while Category 2 focuses on the target's vulnerability. An AI system can violate both simultaneously. + +--- + +## Category 3 — Biometric Categorisation Inferring Sensitive Attributes (Art. 5(1)(c)) + +**Prohibited:** AI systems using biometric categorisation that categorise individually natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation. + +**Scope:** Applies to AI systems that use biometric data to infer sensitive special category attributes. + +**What biometric data is covered:** Any data processed through specific technical processing relating to physical, physiological, or behavioural characteristics of a natural person — including fingerprints, iris scans, facial geometry, gait, voice patterns. + +**The prohibited inference categories:** +- Race or ethnic origin +- Political opinions +- Trade union membership +- Religious or philosophical beliefs +- Sex life or sexual orientation + +**Exceptions (Art. 5(1)(c) proviso):** +- Lawful filtering or labelling of lawfully acquired biometric data sets — e.g., lawful research datasets that need to be sorted +- Law enforcement categorising biometric data in accordance with Union or Member State law + +**What is NOT prohibited:** +- Biometric verification systems that confirm a person is who they claim to be (identity verification) — these are NOT categorisation systems +- Biometric identification systems that match an identity to a known identity — these are separately addressed as high-risk under Annex III, not prohibited + +--- + +## Category 4 — Social Scoring (Art. 5(1)(d)) + +**Prohibited:** AI systems that evaluate or classify natural persons or groups of persons over a period of time based on their social behaviour or known, inferred, or predicted personal or personality characteristics, with a social score, the AI-based evaluation leading to either or both of the following: +- (i) Detrimental or unfavourable treatment of those natural persons or groups in social contexts that are unrelated or disproportionate to the context in which the data was originally generated or collected +- (ii) Detrimental or unfavourable treatment that is unjustified or disproportionate to the social behaviour or its gravity + +**Key elements:** +- Evaluation conducted **over a period of time** (not single-event assessments) +- Based on **social behaviour** or **personal/personality characteristics** (known, inferred, or predicted) +- Leads to treatment that is either unrelated to the data's original context or disproportionate to the behaviour + +**Examples of prohibited systems:** +- Citizen scoring systems that aggregate data from multiple life domains (financial, social, civic) to produce a general-purpose score affecting housing, travel, or services +- Insurance systems that persistently track social media behaviour across years to calculate premiums affecting unrelated services +- Employer AI systems that compile long-term personality assessments reducing job opportunities in unrelated fields + +**What is NOT prohibited:** +- Credit scoring using solely financial behaviour data relevant to a financial service — this is separately regulated as high-risk under Annex III +- Risk assessment for specific, relevant and proportionate purposes (e.g., financial fraud detection) +- HR performance management systems assessing work-specific behaviour in proportion to employment context + +--- + +## Category 5 — Criminal Risk Assessment Based Solely on Profiling or Personality Traits (Art. 5(1)(e)) + +**Prohibited:** AI systems that assess the risk of a natural person to commit criminal offences based solely on profiling of a natural person or assessing their personality traits and characteristics. + +**The critical qualifier "solely":** This prohibition applies when the risk assessment is based **exclusively** on profiling or personality traits. AI that **augments** human assessment based on objective, verifiable facts directly linked to criminal activity is **not** prohibited. + +**What is prohibited:** +- Predictive policing systems that identify individuals as criminal risks based solely on demographic profiling, social network analysis, or personality scores without objective factual basis +- Recidivism risk tools that score individuals based purely on personal characteristics (age, address, employment) without factual criminal behaviour evidence + +**What is NOT prohibited:** +- Actuarial risk tools assessing recidivism risk that incorporate actual criminal history, behavioural observations during incarceration, and other objective verifiable facts — provided they do not rely **solely** on profiling +- AI systems assisting analysts by flagging patterns for human investigator review, where human investigators apply individual fact-based assessment + +--- + +## Category 6 — Untargeted Facial Recognition Scraping (Art. 5(1)(f)) + +**Prohibited:** AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage. + +**Key elements:** +- Applies to the **creation or expansion** of facial recognition databases +- Through **untargeted scraping** — without specific targets or selection criteria +- From **internet sources** or **CCTV footage** + +**Why "untargeted" matters:** Targeted collection with lawful basis (e.g., collecting images of a known suspect with judicial authorisation) is not covered by this prohibition. The prohibition targets mass, indiscriminate collection building databases that could be used for surveillance. + +**What is prohibited:** +- Commercial services that scrape public social media profiles to build facial recognition databases +- Law enforcement building general-purpose facial databases from CCTV footage without targeting specific investigations +- Academic research building large unlicensed facial datasets through automated web scraping + +**Relationship to other prohibitions:** Real-time RBI (Category 8) uses such databases in operation. This prohibition attacks the database-building stage. + +--- + +## Category 7 — Emotion Recognition in Workplace and Educational Institutions (Art. 5(1)(g)) + +**Prohibited:** AI systems used for making inferences about the emotional states of natural persons in the context of the workplace and educational institutions. + +**Scope:** Covers AI systems that analyse facial expressions, voice, body language, or physiological signals to infer emotional states (e.g., stress, engagement, happiness, anxiety, attention). + +**Contexts covered:** +- Workplaces in general — offices, manufacturing floors, remote working environments +- Educational institutions — schools, universities, training facilities + +**The medical/safety exception (Art. 5(1)(g) proviso):** Emotion recognition AI deployed for medical purposes (e.g., detecting clinical depression, monitoring patient distress in healthcare) or safety purposes (e.g., detecting driver fatigue for road safety) is NOT prohibited. + +**What is prohibited:** +- HR monitoring systems that analyse employees' facial expressions during work or video calls to assess productivity, engagement, or stress +- Proctoring software that uses emotion recognition to detect cheating or attention lapses in educational exams +- Recruitment AI that analyses candidates' emotional states during video interviews + +**What is NOT prohibited:** +- Emotion recognition in clinical settings by authorised medical professionals +- Driver drowsiness detection systems in vehicles (safety purpose) +- Voluntary mental health monitoring apps used by individuals for their own benefit + +--- + +## Category 8 — Real-Time Remote Biometric Identification (RBI) in Public Spaces for Law Enforcement (Art. 5(1)(h)) + +**Prohibited (with exceptions):** The use of real-time remote biometric identification systems in publicly accessible spaces for the purpose of law enforcement — except in three specific circumstances. + +### Definitions relevant to this prohibition + +**Remote biometric identification system:** An AI system for the purpose of identifying natural persons at a distance through the comparison of a person's biometric data with the biometric data contained in a reference database, and without prior knowledge of whether the targeted person will be present and can be identified (Art. 3(40)). + +**Real-time:** The capturing and comparison of biometric data and the identification occur immediately or with minimal delay (contrasted with "post" RBI, which is not prohibited but is classified as high-risk). + +**Publicly accessible spaces:** Physical locations accessible to the general public, regardless of ownership — including streets, shopping centres, airports, stadiums, public transport, private premises open to the public. + +### The Three Permitted Exceptions (Art. 5(2)) + +Real-time RBI by law enforcement in publicly accessible spaces is permissible **only** in the following situations: + +**Exception A — Missing persons and trafficking victims:** +Targeted search for specific victims of kidnapping, trafficking, or sexual exploitation, and the search for missing persons. + +**Exception B — Specific, substantial, and imminent threat:** +Prevention of a specific, substantial, and imminent threat to life or safety of natural persons, or identified threat of a terrorist attack. + +**Exception C — Serious crime investigation:** +Detection, localisation, identification, or prosecution of the perpetrator or suspect of a criminal offence referred to in Art. 5(2)(c) — serious crimes including murder, grievous bodily injury, rape, robbery, organised crime, illegal weapons trafficking, terrorism, environmental crime, cybercrime, trafficking, and sexual exploitation. + +### Procedural Safeguards Required for Each Use + +For each real-time RBI deployment under an exception: + +1. **Prior authorisation** must be obtained from a judicial authority or an independent administrative authority of the Member State (Art. 5(3)(a)) + - Urgency exception: In duly justified cases of urgency, deployment may commence without prior authorisation, provided authorisation is requested without undue delay within 24 hours; if rejected, deployment must cease immediately and all data/results/outputs must be deleted + +2. **Fundamental rights impact assessment** must be conducted and registered in the EU database before deployment (Art. 5(4)) + - Urgency exception: Registration may follow in duly justified urgent cases without undue delay + +3. **Temporal, geographic, and personal limitations** must apply — use must remain limited to what is strictly necessary for the specific purpose + +4. **Post-deployment reporting**: A report on deployment to be submitted to the relevant market surveillance authority and the data protection authority + +### Member State legislation requirement + +Member States wishing to use real-time RBI under exceptions must enact specific national legislation authorising such use (Art. 5(3)). The Commission must be notified. National legislation must include: +- Offences that justify use under Exception C +- Maximum time periods for use +- Geographic limitations +- A supervisory mechanism +- Accountability and liability mechanisms + +--- + +## Enforcement Notes + +**Competent authorities:** National market surveillance authorities and data protection authorities, depending on whether the system raises general AI Act or data protection concerns. + +**Timeline:** Prohibited AI practices apply from **2 February 2025**. Any system deployed in the EU after this date that falls into these categories is in violation. + +**Transitional period:** There is no transitional period for prohibited AI systems — unlike high-risk AI systems which have transition periods for existing systems. + +**Interaction with GDPR:** Many prohibited AI practices also involve processing of biometric data (special category under GDPR Art. 9). Non-compliance with Article 5 of the EU AI Act may simultaneously constitute a GDPR violation. Competent authorities are expected to coordinate. + +**Interaction with EU Charter of Fundamental Rights:** Recitals 29–42 make clear that the prohibitions are grounded in fundamental rights under the EU Charter — particularly dignity (Art. 1), prohibition of torture (Art. 4), privacy (Art. 7), data protection (Art. 8), non-discrimination (Art. 21). diff --git a/plugins/govramp/.claude-plugin/plugin.json b/plugins/govramp/.claude-plugin/plugin.json new file mode 100644 index 0000000..b2597a1 --- /dev/null +++ b/plugins/govramp/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "govramp", + "description": "GovRAMP security authorization advisor for state and local government cloud — impact level selection, SSP documentation, gap analysis, Core/Ready/Authorized status paths, Fast Track, continuous monitoring, and NIST 800-53 Rev 5 control guidance for SLED organizations.", + "version": "1.0.0", + "author": { + "name": "Hemant Naik", + "email": "hemant.naik@gmail.com" + }, + "homepage": "https://sushegaad.github.io/Claude-Skills-Governance-Risk-and-Compliance/", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "govramp", + "stateramp", + "sled", + "state-local-government", + "cloud-security", + "nist-800-53", + "authorization", + "3pao", + "grc", + "public-sector" + ] +} diff --git a/plugins/govramp/skills/govramp/SKILL.md b/plugins/govramp/skills/govramp/SKILL.md new file mode 100644 index 0000000..2469b2c --- /dev/null +++ b/plugins/govramp/skills/govramp/SKILL.md @@ -0,0 +1,688 @@ +--- +name: govramp +description: > + Expert GovRAMP security authorization advisor for state and local government cloud + (SLED). Use this skill whenever a user asks about GovRAMP, StateRAMP, SLED cloud + security, GovRAMP impact levels (Low, Low+, Moderate, High), GovRAMP authorization + statuses (Core, Ready, Authorized, Provisionally Authorized, Progressing Snapshot), + GovRAMP Fast Track, NIST 800-53 Rev 5 controls in a state-local context, 3PAO + assessments for GovRAMP, GovRAMP System Security Plan (SSP), Security Assessment + Report (SAR), Plan of Action and Milestones (POA&M), continuous monitoring for + GovRAMP, TX-RAMP reciprocity, CJIS Overlay requirements, GovRAMP Authorized Product + List (APL), or any question about achieving or maintaining a GovRAMP security status + for a cloud service provider serving state, local, education, tribal, or special + district governments. Also trigger for questions about GovRAMP membership, PMO + engagement, or procurement of cloud solutions by public-sector organizations. +--- + +# GovRAMP Security Authorization Skill + +You are an expert GovRAMP implementation consultant and authorization advisor with +comprehensive knowledge of the GovRAMP Security Program, its authorization statuses, +NIST SP 800-53 Rev 5 control requirements for the SLED context, documentation +requirements, continuous monitoring obligations, and the GovRAMP PMO process. + +> **Disclaimer:** This guidance is for informational and educational purposes only. +> GovRAMP authorization requires engagement with the official GovRAMP Program +> Management Office (PMO), serviced by RAMPQuest powered by Knowledge Services, and +> where required, a GovRAMP-approved Third-Party Assessment Organization (3PAO). +> GovRAMP is not endorsed by or affiliated with FedRAMP or the United States Government. + +--- + +## How to Respond + +Clarify the user's authorization status goal (Core, Ready, Authorized), impact level +(Low, Low+, Moderate, High), and whether they already hold any existing authorization +(FedRAMP, SOC 2, etc.) before diving into detailed guidance. + +Match output to the task: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Control Family \| Control ID \| Requirement \| Current State \| Gap \| Priority | +| Status pathway selection | Decision matrix with rationale, effort, cost comparison | +| Control implementation guidance | Structured: Control ID > Objective > What to Implement > Evidence > Common Findings | +| SSP narrative | Prose paragraphs per control, with GovRAMP-specific notes | +| POA&M entry | Table: Finding ID \| Control \| Gap \| Remediation Action \| Owner \| Target Date \| Status | +| Impact level selection | Guided FIPS 199-style categorization with GovRAMP data classification tool logic | +| Continuous monitoring guidance | Monthly/quarterly/annual obligations list with deliverables | +| Fast Track assessment | Checklist of required documentation and process steps | +| General question | Clear prose with NIST 800-53 Rev 5 control citations and GovRAMP context | + +--- + +## GovRAMP — Framework Overview + +### What Is GovRAMP? + +GovRAMP (formerly StateRAMP, doing business as GovRAMP since 2023) is a 501(c)(6) +nonprofit membership organization. It provides a standardized cybersecurity +verification and validation program for cloud service providers (CSPs) that serve +**state, local, education, tribal, and special district (SLED)** organizations across +the United States. + +GovRAMP was founded on the principle that state and local governments — which often +lack the security resources of federal agencies — deserve the same rigorous, reusable +cloud security assessments that FedRAMP provides at the federal level. Rather than +each government entity conducting independent security reviews of every vendor, GovRAMP +centralizes and standardizes the process. + +**Key facts:** +- GovRAMP is **not affiliated with FedRAMP or the United States Government** +- GovRAMP's Program Management Office (PMO) is serviced by **RAMPQuest**, powered by + Knowledge Services +- GovRAMP is governed by a Board of Directors and active committees (Standards & + Technical, Approvals, Appeals, Procurement, Nominating, and Steering) +- GovRAMP has Framework Harmonization Working Groups and task forces (including AI + Security and CJIS-aligned requirements) +- Texas TX-RAMP recognizes GovRAMP with **reciprocity** — GovRAMP-authorized products + automatically qualify for TX-RAMP + +### Technical Foundation + +GovRAMP's security controls are based on **NIST SP 800-53, Revision 5** — the same +publication used to establish FedRAMP. This ensures alignment across federal and +state-local contexts and allows FedRAMP-authorized providers to pursue GovRAMP via +the Fast Track pathway. + +All GovRAMP Rev 5 templates are maintained at: +https://govramp.org/rev-5-templates-and-resources/ + +The GovRAMP PMO can be reached at: pmo@govramp.org + +--- + +## GovRAMP Impact Levels + +GovRAMP uses a risk-based impact level system derived from FIPS 199 and FIPS 200 +categorization logic. Impact level determines the number and stringency of NIST +800-53 Rev 5 controls required. + +| Impact Level | Description | Typical Use Case | +|-------------|-------------|-----------------| +| **Low** | Systems processing non-sensitive government data where loss of CIA has limited adverse effect | Administrative tools, public-facing portals | +| **Low+** | Systems with a slightly elevated risk profile above Low; an intermediate level used by GovRAMP between Low and Moderate | General business applications handling some PII | +| **Moderate** | Most common level — systems where loss of CIA has serious adverse effect | Systems storing PII, PHI, or financial government data | +| **High** | Systems where loss of CIA has severe or catastrophic effect | Systems supporting law enforcement, emergency services, critical infrastructure | + +### Data Classification Tool + +GovRAMP provides an official Data Classification Tool to help organizations determine +their required impact level based on the type of government data being processed, +stored, or transmitted. Download from: https://govramp.org/blog/document/data-classification-tool/ + +### Impact Level and Control Counts + +GovRAMP aligns to NIST 800-53 Rev 5 baselines, applying the same control profiles used +by FedRAMP but tailored for the SLED context. The number of applicable controls +increases with impact level: + +- **Low baseline**: Subset of NIST 800-53 Rev 5 controls (lowest control count) +- **Moderate baseline**: Full NIST 800-53 Rev 5 Moderate baseline (most common; 323 controls under FedRAMP Rev 5 Moderate reference; GovRAMP applies same baseline) +- **High baseline**: Full NIST 800-53 Rev 5 High baseline (highest control count and stringency) + +For the **Core** status pathway, a focused set of **60 prioritized NIST 800-53 Rev 5 +controls** aligned to the Moderate Impact Level and selected based on the MITRE ATT&CK +Framework are assessed by the GovRAMP PMO directly. + +--- + +## GovRAMP Authorization Statuses + +### Status Hierarchy + +GovRAMP defines the following security statuses, from lowest to highest assurance: + +``` +Progressing Snapshot (non-verified, advisory program) + ↓ +GovRAMP Core (verified, PMO-assessed, 60 controls, Moderate-aligned) + ↓ +GovRAMP Ready (verified, 3PAO readiness assessment, minimum mandatory requirements) + ↓ +GovRAMP Authorized / Provisionally Authorized (fully verified, 3PAO SAR + government sponsor) +``` + +--- + +### 1. Progressing Security Snapshot Program + +**What it is:** A subscription-based, advisory-level program. Not a verified security +status. Provides quarterly assessments (Snapshots) and monthly consultative calls +with the GovRAMP PMO advisory team. + +**Purpose:** Early-stage visibility into a provider's security maturity relative to +GovRAMP requirements. Helps identify gaps before pursuing Core, Ready, or Authorized +status. + +**Key characteristics:** +- Quarterly Snapshots provide a security maturity risk score +- Scores are not publicly disclosed; sharing is at provider's discretion +- Snapshot scoring criteria based on critical NIST 800-53 requirements +- Monthly consultative calls with GovRAMP Advisory team +- Providers listed on the **Progressing Product List** (not the Authorized Product List) +- **3PAO not required** + +**Effective January 1, 2026:** New requirements introduced — every product on the +Progressing Product List must be actively advancing toward a verified status. Products +failing to demonstrate progress are subject to an escalation process. + +**Process:** +1. Become a GovRAMP member +2. Submit a GovRAMP Service Request Form +3. Attend intake meeting; review Snapshot scoring criteria +4. Receive security maturity score (~3 weeks) +5. Begin monthly advisory calls to address gaps +6. Quarterly Snapshots to track progress + +**Cost:** Subscription-based; pricing through the GovRAMP PMO. + +--- + +### 2. GovRAMP Core + +**What it is:** A verified security status launched in May 2025, assessed directly by +the GovRAMP PMO. Validates implementation of **60 foundational NIST 800-53 Rev 5 +controls** selected based on the MITRE ATT&CK Framework and aligned with the Moderate +Impact Level baseline. + +**A 3PAO assessment is NOT required for Core.** + +**Purpose:** Bridges the gap between the Progressing Snapshot and full Ready/Authorized +status. Offers a faster, more accessible path to formal assurance without a full 3PAO +audit. + +**Key characteristics:** +- PMO reviews submitted documentation and validates all 60 required controls +- Products listed on the **Authorized Product List (APL)** +- Includes **quarterly Continuous Monitoring (ConMon)** +- Core status demonstrates progression toward Ready and Authorized +- Policies and procedures are required for Core + +**60 Core Controls:** Selected from NIST SP 800-53 Rev 5, aligned to the Moderate +baseline, prioritized using MITRE ATT&CK. See: +https://govramp.org/blog/core-controls/ and the official GovRAMP Core Controls document +at https://govramp.org/rev-5-templates-and-resources/ + +**Process:** +1. Become a GovRAMP member +2. (Optional) Complete the Progressing Snapshot Program first +3. Download the GovRAMP Core Control Evidence Examples and Collection Folders +4. Download and complete required templates (based on Moderate Impact package): SSP, + Incident Response Plan, Contingency Plan, scan documentation +5. Submit a Security Review Request to the GovRAMP PMO +6. PMO validates all 60 controls and awards Core Status +7. Product listed on the APL +8. Begin quarterly Continuous Monitoring + +**Cost (Annual PMO Assessment Fee — 2025/2026):** +- $9,000 — Providers with less than $1M in annual revenue +- $11,000 — Providers with $1M to $5M in annual revenue +- $17,000 — Providers with over $5M in annual revenue + +--- + +### 3. GovRAMP Ready + +**What it is:** A verified security status demonstrating a provider meets GovRAMP's +**minimum mandatory requirements**, as attested by a GovRAMP-approved 3PAO through a +Readiness Assessment Report (RAR). No government sponsor is required for Ready status. + +**Purpose:** Positions a provider to achieve full Authorized status. Indicates the +product is well-positioned to comply with full authorization requirements. + +**Key characteristics:** +- Requires a **3PAO-conducted Readiness Assessment Report (RAR)** +- No government sponsorship required +- Products listed on the Authorized Product List (APL) +- Obligation to submit **monthly and annual Continuous Monitoring** reports + +**Process:** +1. Become a GovRAMP member +2. (Optional) Complete a Security Snapshot as a gap analysis +3. Determine appropriate impact level (Low, Low+, or Moderate) using the Data + Classification Tool +4. Engage a GovRAMP-approved 3PAO to conduct a Readiness Assessment Report (RAR) +5. Complete at least **50%** of documentation; submit Security Review Request Form + with completed documentation and Ready review fee; product status updated to Pending +6. 3PAO attests to readiness; PMO verifies minimum mandatory requirements are met; + product status updated to Ready +7. Begin monthly and annual Continuous Monitoring + +**Cost (Ready Review Fee):** +- $500 — Providers with less than $1M annual revenue +- $2,500 — Providers with $1M–$5M annual revenue +- $3,750 — Providers with more than $5M annual revenue + +**Monthly Continuous Monitoring (Ready/Authorized):** +- $250/month — Providers with less than $1M annual revenue +- $500/month — Providers with $1M–$5M annual revenue +- $1,000/month — Providers with more than $5M annual revenue + +--- + +### 4. GovRAMP Authorized / Provisionally Authorized + +**What it is:** The highest verified security status in GovRAMP. Indicates the product +meets **all required security controls** by impact level. Requires a full 3PAO +Security Assessment Report (SAR) and either direct government sponsorship or approval +by the GovRAMP Approvals Committee. + +**Provisionally Authorized**: Granted where a government sponsor is pending or where +the Approvals Committee has approved the package pending minor conditions. + +**Key characteristics:** +- Requires **100% documentation completion** +- Requires a **3PAO-conducted Security Assessment Report (SAR)** +- Requires government sponsorship (sponsoring government official or GovRAMP Approvals + Committee as appointed sponsor) +- Products listed on the APL as Authorized +- Obligation to submit **monthly and annual Continuous Monitoring** reports + +**Process:** +1. Become a GovRAMP member +2. (Optional) Complete a Security Snapshot or achieve Ready status first +3. Determine appropriate impact level +4. Engage a GovRAMP-approved 3PAO to complete a full SAR +5. Complete 100% of documentation; submit Security Review Request Form with completed + documentation and Authorized review fee; product status updated to Pending +6. Obtain government sponsorship (direct sponsor or Approvals Committee) +7. PMO verifies all control requirements are met; product updated to Authorized +8. Begin monthly and annual Continuous Monitoring + +**Cost (Authorized Review Fee):** +- $1,500 — Providers with less than $1M annual revenue +- $5,000 — Providers with $1M–$5M annual revenue +- $7,500 — Providers with more than $5M annual revenue + +--- + +### 5. GovRAMP Fast Track + +**What it is:** An expedited pathway for providers that already hold FedRAMP +authorization or are actively pursuing FedRAMP authorization. Allows the provider to +leverage existing federal security documentation to obtain GovRAMP status without +starting from scratch. + +**Key characteristics:** +- Accepts documentation in **FedRAMP formatting** +- Requires 90 days of existing continuous monitoring data +- GovRAMP PMO reviews the security package and conducts a call with provider and 3PAO +- Available for Ready and Authorized status paths +- **Texas reciprocity**: TX-RAMP automatically recognizes GovRAMP-authorized products; + GovRAMP provides a weekly sync with TX-RAMP + +**Process:** +1. Become a GovRAMP member +2. Submit a Security Review Request Form to engage the GovRAMP PMO +3. Work with 3PAO to gather the federal-approved security package, 90 days of ConMon + data, and any required GovRAMP-specific templates +4. PMO reviews the package and conducts a review call +5. Upon validation, product achieves GovRAMP Ready or Authorized status +6. Begin GovRAMP Continuous Monitoring + +--- + +## 3. NIST 800-53 Rev 5 Control Framework for GovRAMP + +GovRAMP uses NIST SP 800-53 Rev 5 as its foundation. The same 20 control families apply +across all GovRAMP impact levels, with the applicable controls expanding as impact +level increases. + +### Control Families + +| ID | Family | Key Relevance to GovRAMP | +|----|--------|--------------------------| +| AC | Access Control | IAM, RBAC, least privilege, remote access, PIV/CAC | +| AT | Awareness & Training | Security and privacy training; role-based training | +| AU | Audit & Accountability | Log retention, SIEM, audit review | +| CA | Assessment, Authorization & Monitoring | ConMon, 3PAO, ATO, POAM | +| CM | Configuration Management | Baselines, change control, CMDB | +| CP | Contingency Planning | BCP/DR, tested annually; IRP and CP are required | +| IA | Identification & Authentication | MFA, FIPS 140-2/3 crypto | +| IR | Incident Response | IRP tested annually; incident reporting per GovRAMP Incident Communications Procedures | +| MA | Maintenance | Remote maintenance controls | +| MP | Media Protection | Data at rest, media sanitization | +| PE | Physical & Environmental | Datacenters; often inherited from FedRAMP-authorized IaaS | +| PL | Planning | SSP, rules of behavior | +| PM | Program Management | Enterprise security program | +| PS | Personnel Security | Screening, termination procedures | +| PT | PII Processing & Transparency | Privacy controls (Rev 5 addition) | +| RA | Risk Assessment | Vulnerability scanning; GovRAMP Vulnerability Scan Requirements Guide | +| SA | System & Services Acquisition | SDLC, supply chain security | +| SC | System & Communications Protection | Encryption in transit, network segmentation | +| SI | System & Information Integrity | Patching, malware, integrity monitoring | +| SR | Supply Chain Risk Management | SCRM (Rev 5 addition) | + +### Core Status — 60 Prioritized Controls + +For GovRAMP Core, 60 NIST 800-53 Rev 5 controls from the Moderate baseline are +assessed by the PMO. These controls are selected based on the MITRE ATT&CK Framework, +prioritizing controls that most directly address attack techniques seen against SLED +organizations. The full list is in the official GovRAMP Core Controls document +available at https://govramp.org/rev-5-templates-and-resources/. The control selection +covers domains including: + +- Access Control (AC) +- Audit & Accountability (AU) +- Configuration Management (CM) +- Identification & Authentication (IA) +- Incident Response (IR) +- Risk Assessment (RA) +- System & Communications Protection (SC) +- System & Information Integrity (SI) +- Contingency Planning (CP) +- Personnel Security (PS) + +Policies and procedures supporting these control families are required for Core status. + +### CJIS Overlay + +GovRAMP provides a **Moderate Impact with CJIS Overlay** impact level for providers +handling **Criminal Justice Information (CJI)**. This overlay adds CJIS-aligned +requirements on top of the standard Moderate Impact baseline. It applies to providers +serving law enforcement agencies and criminal justice organizations. + +The GovRAMP PMO maintains separate Service Provider Packages and 3PAO Packages for the +CJIS Overlay. Providers handling CJI must use the CJIS Overlay documentation. + +--- + +## 4. Required Documentation + +GovRAMP documentation aligns with FedRAMP's template structure. Templates are +available at https://govramp.org/rev-5-templates-and-resources/. The PMO accepts +documents in FedRAMP formatting. + +### Core Authorization Package Components + +``` +GovRAMP Authorization Package +├── System Security Plan (SSP) +│ └── Appendices (Incident Response Plan, Contingency Plan, etc.) +├── Security Assessment Report (SAR) [3PAO-prepared — Ready and Authorized only] +├── Plan of Action & Milestones (POA&M) +└── Supporting scans and evidence + ├── Vulnerability scan results (OS, DB, web application) + ├── Penetration test report + └── Authorization Boundary diagram +``` + +### System Security Plan (SSP) + +The SSP is the foundational document. It describes the system, its boundary, and how +each applicable control is implemented. Key sections include: + +- **System Categorization**: Impact level and FIPS 199 logic +- **System Description**: Architecture, technology stack, service model (SaaS/PaaS/IaaS) +- **Authorization Boundary**: What is in and out of scope; boundary diagram +- **Control Implementation Statements**: How each required control is satisfied, + distinguishing provider vs. customer responsibilities +- **Leveraged Authorizations**: FedRAMP-authorized IaaS/PaaS used and inherited controls +- **External Services**: Connections to services outside the boundary + +> For Core status: The SSP must cover at minimum the 60 Core controls. The GovRAMP +> Service Provider Package for Moderate Impact is the reference template. + +### Incident Response Plan (IRP) + +Required for all GovRAMP status levels including Core. Must be tested and documented. +Must include contact information and reporting timelines aligned with GovRAMP Incident +Communications Procedures. + +### Contingency Plan (CP) + +Required for all GovRAMP status levels including Core. Must be tested and documented. +Covers backup, recovery, and continuity of operations. + +### Scan Documentation + +- Vulnerability scans required; see the GovRAMP Vulnerability Scan Requirements Guide +- Penetration testing required (per the GovRAMP Penetration Test Guidance) +- Scans must cover OS, database, web application layers, and containers if used + +### Plan of Action & Milestones (POA&M) + +Tracks all open security findings. For each finding: + +| Field | Description | +|-------|-------------| +| Finding ID | Unique identifier | +| Control ID | NIST 800-53 Rev 5 control affected | +| Weakness Description | Clear description of the gap | +| Risk Rating | Critical / High / Moderate / Low | +| Remediation Plan | How the weakness will be fixed | +| Owner | Team or individual responsible | +| Scheduled Completion Date | Must meet GovRAMP remediation SLAs | +| Status | Open / Closed / Risk Adjusted / Vendor Dependency | + +**GovRAMP Remediation SLAs** (aligned with NIST and GovRAMP standards): +- Critical: 30 days +- High: 90 days +- Moderate: 180 days +- Low: 365 days + +--- + +## 5. Continuous Monitoring (ConMon) + +All products with a verified GovRAMP status must participate in Continuous Monitoring +to maintain their listing on the APL. The GovRAMP PMO monitors ongoing security +performance through the ConMon program. + +### ConMon by Status Level + +| Status | ConMon Frequency | +|--------|-----------------| +| Core | Quarterly | +| Ready | Monthly and Annual | +| Authorized | Monthly and Annual | + +### Monthly ConMon Activities (Ready / Authorized) + +- Vulnerability scan results submitted to the GovRAMP PMO +- Updated POA&M (open findings, remediation progress) +- Asset inventory updates +- Monthly report submission per the GovRAMP Continuous Monitoring Guide + +### Annual ConMon Activities (Ready / Authorized) + +- Full security assessment (3PAO or PMO-directed) +- Updated SSP and appendices +- Tested IRP and CP with documented test results +- Updated SAR and POA&M + +### Quarterly ConMon Activities (Core) + +- Progress reports submitted to the PMO +- Validation of continued Core control alignment +- Participation in PMO review of ongoing security performance + +### ConMon Escalation Process + +GovRAMP has a **Continuous Monitoring Escalation Process Guide** that details how +issues identified during ConMon are escalated, ensuring serious risks are addressed +promptly. Providers failing to meet ConMon obligations or showing declining security +posture are subject to the escalation process. + +--- + +## 6. Authorization Boundary Guidance + +Defining the correct authorization boundary is critical and one of the most common +sources of findings. GovRAMP provides an official **Authorization Boundary Guidance** +document. + +### Key Principles + +- **Everything that processes, stores, or transmits government data** in scope must be + within the boundary +- External services connected to in-scope systems must be GovRAMP-authorized (or + FedRAMP-authorized) OR documented with compensating controls +- The boundary must be depicted in a clear network/data flow diagram within the SSP +- Cloud platform infrastructure from a FedRAMP-authorized IaaS/PaaS provider + (AWS GovCloud, Azure Government, Google Cloud) can be documented as inherited + +### Cloud Platform Considerations + +**AWS GovCloud (US)** +- FedRAMP High authorized; PE and many SC controls fully inherited +- AWS Config, CloudTrail, GuardDuty, Security Hub useful for AU, RA, SI controls +- Use GovCloud region endpoints to remain in boundary + +**Azure Government** +- FedRAMP High authorized +- Azure Policy, Defender for Cloud maps to CM, RA, SI +- Azure Blueprints aligned to GovRAMP/FedRAMP Moderate and High baselines + +**Google Cloud (FedRAMP-authorized regions)** +- Assured Workloads for compliance +- Chronicle SIEM for AU controls + +--- + +## 7. GovRAMP Membership + +Before any product can be validated by the GovRAMP PMO, obtain a security status, or +be listed on the APL, the service provider **must be an active GovRAMP member**. + +### Membership Types + +| Type | Available To | +|------|-------------| +| Service Provider Member | Cloud service providers (SaaS, PaaS, IaaS) | +| Government Member | State, local, tribal, education, special district organizations | +| 3PAO Member | Third-party assessment organizations | +| Education/Nonprofit Member | Private education and nonprofit organizations | + +### Annual Membership Fees + +Annual memberships start at **$1,500** for service providers. Flexible options are +available based on organization size and type. + +### Benefits of Membership + +- Access to the complete Member Directory +- Public product profile on the Authorized Product List (enables procurement discovery) +- Engagement with the GovRAMP PMO +- Access to Framework Harmonization Working Groups +- Participation in task forces (AI Security, CJIS) +- Monthly Office Hours with the GovRAMP PMO (first Wednesday each month, 2:30–3:00 PM ET) + +--- + +## 8. For Government Organizations Adopting GovRAMP + +State and local governments can adopt GovRAMP as their third-party risk program for +cloud procurement. Benefits include: + +- Review the APL during procurement to identify pre-verified providers +- Move from being an assessor to an oversight role by accessing the ConMon portal +- Policymakers gain assurance that providers meet best-in-class standards throughout + the contract lifespan +- Participation in the GovRAMP governance structure (committees, working groups) + +### Adoption Process + +1. Determine your adoption roadmap with guidance from a GovRAMP Government Engagement + Director +2. Review the GovRAMP Adoption Resource Guide ("Getting Started with GovRAMP: A Guide + for Government") +3. Become a GovRAMP member +4. Incorporate GovRAMP requirements into your procurement RFPs +5. Leverage the APL for pre-vetted vendor selection +6. Access the ConMon portal for ongoing oversight + +GovRAMP's Procurement Cloud Security Resource Tool (developed by NASPO/GovRAMP +Procurement Task Force) helps procurement professionals prioritize cybersecurity +throughout the procurement process. + +--- + +## 9. Gap Assessment Approach + +### When the User Is a Service Provider + +1. **Clarify goal** — What status are they pursuing (Core, Ready, Authorized)? +2. **Identify impact level** — What type of government data? Use FIPS 199 logic or the + GovRAMP Data Classification Tool. +3. **Identify current state** — Do they already have FedRAMP, SOC 2, ISO 27001, or any + other third-party assessment? Consider Fast Track. +4. **Map controls** — Compare current documentation and controls against the applicable + GovRAMP baseline. +5. **Identify blockers** — Surface missing mandatory items: SSP, IRP, CP, scan results. +6. **Produce gap table**: + +| Control Family | Control ID | Requirement | Status | Gap | Priority | Owner | +|---------------|-----------|-------------|--------|-----|----------|-------| + +7. **Recommend pathway** — Core for faster entry, Ready or Authorized for full status, + Fast Track for FedRAMP-authorized providers. +8. **Estimate effort** — Reference the GovRAMP Ready/Authorized Guide for typical effort + expectations. + +### Key Readiness Questions to Ask + +- What cloud platform do you use? Is it FedRAMP-authorized (AWS GovCloud, Azure Government)? +- Do you already hold FedRAMP authorization? → Recommend Fast Track +- What types of government data will the system process, store, or transmit? +- Is your authorization boundary defined and documented? +- Do you have documented and tested IRP and CP? +- Do you have FIPS 140-2/3 validated encryption in place? +- Do you have a vulnerability scanning program (OS, DB, web app)? +- Do you have policies and procedures documented for the required control families? +- Do you have MFA enforced on all privileged accounts and remote access? +- Are you serving any Texas government entities? → TX-RAMP reciprocity may apply + +--- + +## 10. GovRAMP vs. FedRAMP — Key Differences + +| Factor | FedRAMP | GovRAMP | +|--------|---------|---------| +| Target customer | Federal government agencies | State, local, education, tribal (SLED) | +| Governing body | OMB / GSA / PMO (US Government) | GovRAMP nonprofit (501(c)(6)) | +| Control baseline | NIST 800-53 Rev 5 | NIST 800-53 Rev 5 (same) | +| Impact levels | Low, Moderate, High, LI-SaaS | Low, Low+, Moderate, High + CJIS Overlay | +| Government sponsor | Federal agency AO | State/local government or Approvals Committee | +| Reciprocity | FedRAMP → Fast Track to GovRAMP | GovRAMP → TX-RAMP automatic | +| 3PAO requirement | Required for all paths | Not required for Core; required for Ready/Authorized | +| Entry-level status | No equivalent to Core | GovRAMP Core (60 controls, PMO-assessed) | +| Program managed by | Joint Authorization Board (JAB) / PMO | GovRAMP PMO (RAMPQuest) | + +--- + +## 11. Common Findings and Pitfalls + +### Documentation Gaps +- SSP narratives that describe planned or aspirational controls rather than implemented controls +- Missing control implementation statements for one or more required controls +- Inconsistent boundary definition between SSP narrative and architecture diagrams +- IRP and CP not tested within the past 12 months +- Missing or incomplete POA&M entries for known gaps + +### Technical Gaps +- MFA not enforced on all privileged accounts and remote access paths +- Encryption using non-FIPS-validated modules (e.g., algorithms not approved under FIPS 140-2/3) +- Vulnerability scanning not covering all boundary components (containers, databases, web apps) +- Logging gaps — not all in-scope components sending logs to a centralized SIEM +- External services not documented or not FedRAMP/GovRAMP-authorized + +### Process Gaps +- No formal change management process for system changes within the boundary +- No documented personnel security procedures (screening, termination) +- Penetration testing not performed against the GovRAMP Penetration Test Guidance +- ConMon reports not submitted on schedule after authorization + +--- + +## Reference Files + +Load these when more depth is needed: + +- `references/readiness-checklist.md` — Full GovRAMP readiness checklist across all control domains +- `references/status-pathways.md` — Detailed comparison of all status pathways with decision guidance +- `references/ssp-guide.md` — SSP section-by-section guidance for GovRAMP +- `references/conmon-guide.md` — Continuous Monitoring templates, deliverables, and escalation guidance +- `references/control-mapping.md` — Core 60 controls mapping and full impact level control guidance diff --git a/plugins/govramp/skills/govramp/references/conmon-guide.md b/plugins/govramp/skills/govramp/references/conmon-guide.md new file mode 100644 index 0000000..e57f034 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/conmon-guide.md @@ -0,0 +1,240 @@ +# GovRAMP Continuous Monitoring (ConMon) Guide + +Continuous Monitoring (ConMon) is the ongoing obligation for all products with a +verified GovRAMP security status to demonstrate that their security posture is +maintained after initial authorization. GovRAMP requires ConMon activities to be +conducted and reported to the PMO per the official GovRAMP Continuous Monitoring Guide. + +Download the official guide at: +https://govramp.org/blog/document/stateramp-continuous-monitoring-guide/ + +For escalation procedures: +GovRAMP Continuous Monitoring Escalation Process Guide (available at https://govramp.org/rev-5-templates-and-resources/) + +--- + +## ConMon Obligations by Status + +| GovRAMP Status | ConMon Frequency | Key Deliverables | +|---------------|-----------------|-----------------| +| Core | Quarterly | Quarterly progress reports; ongoing PMO validation | +| Ready | Monthly + Annual | Monthly report package; annual assessment | +| Authorized | Monthly + Annual | Monthly report package; annual assessment | +| Provisionally Authorized | Monthly + Annual | Monthly report package; annual assessment | + +--- + +## Monthly ConMon Activities (Ready and Authorized) + +The following deliverables must be submitted monthly to the GovRAMP PMO: + +### 1. Vulnerability Scan Results + +Per the GovRAMP Vulnerability Scan Requirements Guide: + +- **Operating System (OS) scans**: All in-scope servers, VMs, and containers +- **Database scans**: All in-scope database components +- **Web application scans**: All web-facing applications within the boundary +- **Container scans** (if applicable): Container images and runtime environments +- Scans must be authenticated (credentialed) where supported +- Unauthenticated scan results alone are insufficient for compliance +- All critical and high findings must appear in the POA&M with remediation plans + +**Scan frequency requirement**: At minimum, scans must be conducted monthly for +Moderate and High impact levels. + +### 2. POA&M Update + +The Plan of Action and Milestones must be updated every month to reflect: + +- All new findings identified since last submission (from scans, audits, or self-discovery) +- Remediation status updates for each open finding +- Milestone date changes (with justification for any slippage) +- Newly closed items (evidence of remediation) +- Deviation Request status (false positives, risk adjustments, operational requirements) + +**POA&M Required Fields:** + +| Field | Description | +|-------|-------------| +| Finding ID | Unique identifier (e.g., SCAN-001, AUDIT-001) | +| Control ID(s) | NIST 800-53 Rev 5 control(s) affected | +| Weakness Name | Brief, descriptive name | +| Weakness Description | Detailed description of the gap | +| Point of Contact | Owner responsible for remediation | +| Resources Required | Tools, budget, or headcount needed | +| Remediation Plan | Step-by-step plan to address the finding | +| Original Detection Date | When was this first identified | +| Scheduled Completion Date | Target remediation date (must meet SLAs) | +| Milestone Changes | Log of any changes to target dates or scope | +| Status | Open / Closed / Risk Adjusted / Vendor Dependency | +| Risk Rating | Critical / High / Moderate / Low | +| False Positive | Yes / No (if marked Yes, must be substantiated) | + +### 3. Asset Inventory Update + +- Any new components added to the boundary must be reflected in the inventory +- Any decommissioned components must be removed +- Cloud resource additions (new accounts, new services) must be documented +- The inventory must accurately reflect the current state of the system + +### 4. Monthly Summary Report + +- A brief executive summary of the month's security activities +- Highlights: new findings, closed findings, ongoing remediation +- Scan coverage confirmation (every in-scope component was scanned) +- Any incidents or security events during the period + +--- + +## Annual ConMon Activities (Ready and Authorized) + +### Annual Security Assessment + +GovRAMP requires an annual review of security controls: + +- Conducted by a GovRAMP-approved 3PAO (for Authorized products) or PMO-directed process +- Results submitted as an updated Security Assessment Report (SAR) or equivalent +- Annual Assessment Controls Selection Worksheet used to determine which controls to test +- All findings from the annual assessment must be added to the POA&M + +### Documentation Updates + +- **Updated SSP**: Reflect any system changes, boundary modifications, or new controls +- **Updated IRP**: Must be tested (tabletop or functional exercise) with test results documented +- **Updated CP**: Must be tested with test results documented +- **Updated POA&M**: Incorporating annual assessment findings + +### Penetration Test + +- Required annually (at minimum) per the GovRAMP Penetration Test Guidance +- Must cover all in-scope systems: external, internal, web application, and containers if used +- Penetration test methodology must meet GovRAMP requirements +- Findings from the penetration test must be tracked in the POA&M + +--- + +## Quarterly ConMon Activities (Core) + +For products with Core status, ConMon is conducted quarterly: + +- Quarterly progress reports submitted to the GovRAMP PMO +- PMO validates ongoing alignment with all 60 Core controls +- PMO and government stakeholders review security performance trends +- Any changes to the system that impact Core control implementation must be reported + +--- + +## GovRAMP Remediation SLAs + +All POA&M items must be remediated within the following timeframes, measured from the +**original detection date**: + +| Risk Rating | Remediation Deadline | +|-------------|---------------------| +| Critical | 30 calendar days | +| High | 90 calendar days | +| Moderate | 180 calendar days | +| Low | 365 calendar days | + +Failure to meet remediation SLAs is one of the most common ConMon findings that +triggers the escalation process. + +--- + +## Deviation Requests + +When a finding cannot be remediated within SLA for legitimate operational reasons, +providers may submit a Deviation Request to the GovRAMP PMO: + +### Types of Deviations + +**1. False Positive** +- Provider demonstrates the finding does not represent a real vulnerability +- Must include technical evidence: screenshot of the scan result, explanation of + why the finding is incorrect, tool-specific analysis +- Requires PMO approval to remove from open findings + +**2. Risk Adjustment** +- Finding is real but provider believes the risk level is overstated +- Provider must provide justification and compensating controls +- Original risk level is preserved in the POA&M; adjusted level is noted +- Requires PMO approval + +**3. Operational Requirement** +- Finding cannot be remediated without significant operational impact (e.g., patching a + legacy component would break critical government customer functionality) +- Provider must document the operational reason and compensating controls +- Requires PMO approval and may require government sponsor acknowledgment + +--- + +## ConMon Escalation Process + +The GovRAMP Continuous Monitoring Escalation Process Guide defines how issues are +escalated when a provider fails to meet ConMon obligations: + +### Escalation Triggers + +- Failure to submit monthly ConMon package on time +- POA&M items exceeding remediation SLAs without an approved deviation +- Critical vulnerabilities not remediated within 30 days +- Discovery of a significant security incident not reported per GovRAMP Incident + Communications Procedures +- Failure to demonstrate progress in the Progressing Snapshot Program (post-Jan 2026) + +### Escalation Steps + +1. **Warning Notice**: PMO notifies provider of the specific compliance gap +2. **Correction Period**: Provider has a defined period to remedy the issue +3. **Status Review**: PMO and relevant committees review the provider's status +4. **Status Downgrade or Suspension**: If not resolved, the product's status may be + downgraded or suspended from the APL +5. **Appeals Committee**: Provider may appeal to the GovRAMP Appeals Committee + +--- + +## Incident Reporting + +Per the GovRAMP Incident Communications Procedures: + +- Security incidents must be reported to the GovRAMP PMO in a timely manner +- The IRP must contain GovRAMP PMO contact information +- Providers must communicate with relevant government customers and stakeholders +- Reporting timelines and communication templates are defined in the GovRAMP Incident + Communications Procedures document (available at https://govramp.org/rev-5-templates-and-resources/) + +--- + +## ConMon Portal Access + +GovRAMP provides government members with access to a secure ConMon portal for +oversight of authorized products. Government officials can: + +- Review current monthly ConMon submissions for authorized providers +- Access historical ConMon records +- Monitor remediation progress +- Receive alerts on significant security events + +This allows government organizations to move from a manual assessment role to an +oversight role, reducing the burden of recurring independent reviews for every provider. + +--- + +## ConMon Tips for Service Providers + +1. **Automate scans** — Use automated vulnerability scanning tools to ensure monthly scans + are consistent, complete, and reproducible +2. **Scan all components** — The most common ConMon finding is scan coverage gaps; ensure + every asset in the system inventory is scanned +3. **Keep the POA&M current weekly** — Waiting until month end creates errors and delays +4. **Track SLAs proactively** — Build alerts in your ticketing system 30 days before any + POA&M item's scheduled completion date +5. **Document everything** — If a vulnerability cannot be reproduced or is a false positive, + document the evidence immediately before submitting a deviation request +6. **Communicate proactively** — If a critical finding will miss its SLA, notify the PMO + before the deadline, not after +7. **Patch third-party dependencies** — Vendor-supplied patches for critical vulnerabilities + must be applied within 30 days; track vendor patch availability in the POA&M +8. **Test the IRP and CP annually** — Missing test documentation is one of the most + common annual finding categories diff --git a/plugins/govramp/skills/govramp/references/control-mapping.md b/plugins/govramp/skills/govramp/references/control-mapping.md new file mode 100644 index 0000000..14743d4 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/control-mapping.md @@ -0,0 +1,288 @@ +# GovRAMP Control Mapping Reference + +This reference covers the NIST SP 800-53 Rev 5 controls relevant to GovRAMP +authorization, with notes on their application at each GovRAMP impact level and +specific implementation guidance for the SLED (state, local, education, tribal) +cloud security context. + +GovRAMP applies NIST SP 800-53 Rev 5 control baselines. The Core status pathway +uses 60 prioritized controls from the Moderate baseline, selected based on the MITRE +ATT&CK Framework. Full control lists for each impact level (Low, Low+, Moderate, +Moderate + CJIS, High) are provided in the official GovRAMP Service Provider Packages. + +Templates available at: https://govramp.org/rev-5-templates-and-resources/ + +--- + +## Control Families Overview + +| ID | Family | Scope | Notes for GovRAMP | +|----|--------|-------|------------------| +| AC | Access Control | All levels | MFA, RBAC, least privilege are Core controls | +| AT | Awareness & Training | All levels | Security awareness + role-based training required | +| AU | Audit & Accountability | M, H | SIEM, log retention critical; Core includes logging controls | +| CA | Assessment, Auth & Monitoring | All levels | Drives 3PAO assessments and ConMon structure | +| CM | Configuration Management | M, H | Baselines, CMDB, change control; Core includes CM controls | +| CP | Contingency Planning | All levels | IRP and CP required for Core, Ready, Authorized | +| IA | Identification & Authentication | All levels | FIPS 140-2/3 required; MFA is a Core control | +| IR | Incident Response | All levels | IRP required and tested; reporting per GovRAMP procedures | +| MA | Maintenance | M, H | Remote maintenance controls | +| MP | Media Protection | M, H | Data at rest encryption; media sanitization | +| PE | Physical & Environmental | M, H | Often inherited from FedRAMP-authorized IaaS | +| PL | Planning | All levels | SSP, Rules of Behavior | +| PM | Program Management | M, H | Enterprise security program oversight | +| PS | Personnel Security | All levels | Background screening, termination; Core covers PS controls | +| PT | PII Processing & Transparency | M, H | Privacy controls (Rev 5 addition); applies to PII systems | +| RA | Risk Assessment | All levels | Vulnerability management; Core covers RA controls | +| SA | System & Services Acquisition | M, H | SDLC security, third-party supply chain | +| SC | System & Comms Protection | All levels | Encryption in transit; network segmentation; Core includes SC | +| SI | System & Information Integrity | All levels | Patching, malware, integrity monitoring; Core includes SI | +| SR | Supply Chain Risk Management | M, H | SCRM (Rev 5 addition) | + +--- + +## GovRAMP Core — 60 Control Areas + +The following control areas are covered by the GovRAMP Core 60-control set, aligned +to the NIST SP 800-53 Rev 5 Moderate baseline and prioritized using the MITRE ATT&CK +Framework. The complete, definitive list is in the official GovRAMP Core Controls +document: https://govramp.org/rev-5-templates-and-resources/ + +### Access Control (AC) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| AC-1 | Policy and Procedures | Required | Document AC policy; review annually | +| AC-2 | Account Management | Required | Provisioning, de-provisioning, reviews; shared account controls | +| AC-3 | Access Enforcement | Required | RBAC or ABAC implementation; enforce least privilege | +| AC-6 | Least Privilege | Required | Restrict privilege to minimum required; review quarterly | +| AC-7 | Unsuccessful Logon Attempts | Required | Account lockout after N failed attempts; document threshold | +| AC-11 | Device Lock | Applies | Session lock after inactivity timeout | +| AC-17 | Remote Access | Required | Document remote access methods; MFA enforced on all paths | +| AC-18 | Wireless Access | Applies | Wireless usage policy; authentication requirements | + +### Awareness and Training (AT) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| AT-1 | Policy and Procedures | Required | Security training policy | +| AT-2 | Literacy Training and Awareness | Required | Annual security awareness for all users | +| AT-3 | Role-Based Training | Required | Specialized training for privileged users and security staff | + +### Audit and Accountability (AU) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| AU-1 | Policy and Procedures | Required | Audit policy and procedures | +| AU-2 | Event Logging | Required | Define auditable events; configure logging system | +| AU-3 | Content of Audit Records | Required | Logs must include: who, what, when, where, outcome | +| AU-6 | Audit Record Review | Required | Define review frequency; document review process | +| AU-9 | Protection of Audit Information | Required | Prevent deletion or modification of logs | +| AU-11 | Audit Record Retention | Required | Minimum 90 days accessible; 1 year total retention | +| AU-12 | Audit Record Generation | Required | All in-scope components generating logs | + +### Configuration Management (CM) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| CM-1 | Policy and Procedures | Required | CM policy | +| CM-2 | Baseline Configuration | Required | Documented baseline configs per component type | +| CM-6 | Configuration Settings | Required | Applied security settings; deviation tracking | +| CM-7 | Least Functionality | Required | Disable unused ports, protocols, services | +| CM-8 | System Component Inventory | Required | Current, accurate inventory of all boundary components | +| CM-10 | Software Usage Restrictions | Applies | Licensed software; prohibition of unauthorized software | + +### Contingency Planning (CP) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| CP-1 | Policy and Procedures | Required | CP policy | +| CP-2 | Contingency Plan | Required | Documented CP with RTO/RPO | +| CP-3 | Contingency Training | Required | Training for staff with CP roles | +| CP-4 | Contingency Plan Testing | Required | Test within past 12 months; document results | +| CP-9 | System Backup | Required | Backup procedures; restoration tested | + +### Identification and Authentication (IA) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| IA-1 | Policy and Procedures | Required | IA policy | +| IA-2 | Identification and Authentication | Required | MFA for all user accounts; privileged and non-privileged | +| IA-3 | Device Identification | Applies | Authenticate devices where feasible | +| IA-5 | Authenticator Management | Required | Password/token management; FIPS 140-2/3 | +| IA-6 | Authenticator Feedback | Applies | Obscure authentication feedback | +| IA-8 | Non-Org User Auth | Required | Government user authentication requirements | + +### Incident Response (IR) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| IR-1 | Policy and Procedures | Required | IRP policy | +| IR-2 | Incident Response Training | Required | Training for all incident responders | +| IR-3 | Incident Response Testing | Required | Test IRP within past 12 months; document results | +| IR-4 | Incident Handling | Required | Containment, eradication, recovery procedures | +| IR-5 | Incident Monitoring | Required | Track and document incidents | +| IR-6 | Incident Reporting | Required | Report to GovRAMP PMO per Incident Communications Procedures | +| IR-8 | Incident Response Plan | Required | Documented IRP with GovRAMP PMO contacts | + +### Personnel Security (PS) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| PS-1 | Policy and Procedures | Required | PS policy | +| PS-3 | Personnel Screening | Required | Background checks before granting access | +| PS-4 | Personnel Termination | Required | Access revocation upon termination | +| PS-5 | Personnel Transfer | Required | Access review on role change | + +### Risk Assessment (RA) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| RA-1 | Policy and Procedures | Required | Risk management policy | +| RA-3 | Risk Assessment | Required | Periodic risk assessment; document results | +| RA-5 | Vulnerability Monitoring and Scanning | Required | Automated scans; coverage of all components | +| RA-7 | Risk Response | Required | Remediation planning for identified risks | + +### System and Communications Protection (SC) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| SC-1 | Policy and Procedures | Required | SC policy | +| SC-5 | Denial of Service Protection | Applies | DDoS mitigation measures | +| SC-7 | Boundary Protection | Required | Firewalls; network segmentation | +| SC-8 | Transmission Confidentiality | Required | Encryption in transit; TLS 1.2 minimum | +| SC-12 | Cryptographic Key Establishment | Required | Key management procedures | +| SC-13 | Cryptographic Protection | Required | FIPS 140-2/3 validated modules only | +| SC-28 | Protection at Rest | Required | Encryption at rest for all government data | + +### System and Information Integrity (SI) Core Selections + +| Control | Name | Priority | Implementation Focus | +|---------|------|----------|---------------------| +| SI-1 | Policy and Procedures | Required | SI policy | +| SI-2 | Flaw Remediation | Required | Patch management; patch within SLAs | +| SI-3 | Malicious Code Protection | Required | Anti-malware on all applicable components | +| SI-4 | System Monitoring | Required | Intrusion detection; alert review | +| SI-5 | Security Alerts | Required | Subscribe to threat intelligence; act on advisories | +| SI-7 | Software & Information Integrity | Applies | File integrity monitoring | +| SI-10 | Information Input Validation | Applies | Input validation to prevent injection | + +--- + +## Impact Level Differences: Key Control Additions + +### Low Impact (Baseline) +Controls covering basic administrative and procedural safeguards: +- AC family: AC-1, AC-2, AC-3, AC-8, AC-14, AC-17, AC-20 +- AT family: AT-1, AT-2, AT-3 +- AU family: reduced set (AU-1, AU-2, AU-3, AU-6, AU-11, AU-12) +- IA: IA-1, IA-2 (including IA-2(1) for MFA on privileged accounts), IA-4, IA-5 +- IR: IR-1, IR-2, IR-4, IR-5, IR-6, IR-7, IR-8 +- CP: CP-1, CP-2, CP-4 (tabletop only) + +### Moderate Impact (Adds to Low) +Extends Low with more comprehensive controls: +- AC-2 enhancements (automated provisioning review) +- AC-4 Information Flow Enforcement (network segmentation) +- AC-6(1), AC-6(5), AC-6(9), AC-6(10) (Least Privilege enhancements) +- AU-3(1), AU-6(1) (enhanced log content and review) +- CA-2, CA-3, CA-7, CA-9 (assessment and ConMon controls) +- CM-2(2), CM-6(1), CM-7(1), CM-8(1) (enhanced CM) +- CP-6, CP-7, CP-9(1) (alternate sites, backup enhancements) +- IA-2(1), IA-2(2), IA-2(8), IA-2(12) (MFA enhancements) +- IR-3(2) (incident response with support from external providers) +- PT family controls (PII processing and transparency) +- RA-5(1), RA-5(2), RA-5(5) (enhanced scanning) +- SA-3, SA-4, SA-8, SA-9, SA-11 (SDLC, third-party services) +- SC-7 enhancements, SC-8(1), SC-23, SC-28, SC-39 +- SI-2(2), SI-3(1), SI-4(1), SI-4(2), SI-7(1) (enhanced SI) +- SR family (supply chain risk management, new in Rev 5) + +### High Impact (Adds to Moderate) +Most comprehensive set, including: +- Enhanced AC controls for privileged access (AC-2(9), AC-6(3)) +- PIV/CAC authentication requirements (IA-2(12) is critical) +- Full AU suite including real-time alerting +- Extensive CA assessment requirements +- Enhanced CP with multiple alternate sites and full BCP/DR testing +- Additional PE, MA, MP controls +- SI-7 full integrity monitoring suite +- Enhanced SR controls + +### CJIS Overlay (Moderate + CJIS) +Additional requirements overlaid on the Moderate baseline for CJI environments: +- FBI CJIS Security Policy alignment +- Personnel screening to CJIS Security Policy standards +- Encryption requirements specific to CJI handling +- Advanced Authentication (AA) per CJIS requirements +- Data isolation requirements +- Additional audit event capture for CJI data access +- Specific media protection requirements for CJI + +Providers must use the GovRAMP Service Provider Package for Moderate Impact with CJIS +Overlay and the 3PAO Package for Moderate Impact with CJIS Overlay. + +--- + +## Control Implementation Quick Reference + +### MFA Requirements + +| Scenario | Minimum MFA Requirement | +|----------|------------------------| +| Privileged accounts (admin, root) | Required at all impact levels | +| Non-privileged accounts — remote access | Required at Moderate and High | +| Government user accounts | Required at Moderate and High | +| All accounts | Required at High | + +MFA must use FIPS 140-2/3 validated cryptographic mechanisms. + +### Encryption Requirements + +| Data State | Minimum Requirement | +|------------|---------------------| +| Data in transit | TLS 1.2 minimum; TLS 1.3 preferred; FIPS 140-2/3 validated | +| Data at rest | AES-256 (FIPS-approved cipher); FIPS 140-2/3 validated key management | +| Prohibited algorithms | MD5, SHA-1 (for signing), DES, 3DES, RC4, SSLv2, SSLv3, TLS 1.0, TLS 1.1 | + +### Vulnerability Scan Scope Requirements + +| Component Type | Low | Moderate | High | +|----------------|-----|----------|------| +| Operating systems | Monthly | Monthly | More frequent | +| Databases | Not required | Monthly | More frequent | +| Web applications | Not required | Monthly | More frequent | +| Containers and images | Not required | Monthly if used | More frequent | +| Credentialed scans | Recommended | Required | Required | +| Penetration testing | Not required | Annual minimum | Annual minimum | + +### Patch / Flaw Remediation SLAs (GovRAMP) + +| Risk Rating | Remediation Deadline | +|-------------|---------------------| +| Critical | 30 calendar days | +| High | 90 calendar days | +| Moderate | 180 calendar days | +| Low | 365 calendar days | + +--- + +## Cross-Framework Alignment + +GovRAMP's NIST 800-53 Rev 5 foundation enables straightforward alignment with other +frameworks commonly used by SLED organizations: + +| Framework | Alignment Note | +|-----------|----------------| +| FedRAMP Rev 5 | Direct alignment; Fast Track leverages FedRAMP documentation | +| NIST CSF 2.0 | NIST 800-53 Rev 5 is the detailed implementation layer for CSF functions | +| CJIS Security Policy | CJIS Overlay in GovRAMP maps CJI-specific requirements onto the control baseline | +| TX-RAMP | Automatic reciprocity — GovRAMP Authorized products are recognized by TX-RAMP | +| HIPAA/HITECH | Moderate baseline covers the technical security controls required for PHI in government systems | +| SOC 2 | SOC 2 controls partially map to NIST 800-53; existing SOC 2 reports referenced in PMO assessment | +| ISO 27001 | ISO 27001 controls map to NIST 800-53; can be leveraged as evidence in PMO review | + +> Note: While GovRAMP accepts evidence from other frameworks (SOC 2, ISO 27001) as +> supporting documentation, GovRAMP status requires demonstration of the specific NIST +> 800-53 Rev 5 controls in the applicable baseline. Existing certifications accelerate +> readiness but do not substitute for GovRAMP authorization requirements. diff --git a/plugins/govramp/skills/govramp/references/readiness-checklist.md b/plugins/govramp/skills/govramp/references/readiness-checklist.md new file mode 100644 index 0000000..4695d76 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/readiness-checklist.md @@ -0,0 +1,233 @@ +# GovRAMP Readiness Checklist + +Use this checklist when performing a gap assessment for any GovRAMP status level. +For each item, mark: Met | Partial | Not Met | N/A + +Impact levels: Low (L) | Moderate (M) | High (H) +Where multiple levels are shown, the control applies at that level and above. + +--- + +## 1. Membership and Program Enrollment + +- [ ] Service provider is an active GovRAMP member +- [ ] Membership tier is appropriate for the organization's size and revenue +- [ ] Security Review Request Form has been identified and is accessible + +--- + +## 2. Boundary and System Documentation + +- [ ] Authorization boundary is formally defined in writing +- [ ] Network architecture diagram is current and depicts the full boundary +- [ ] Data flow diagrams show all data entering, leaving, and moving within the boundary +- [ ] System inventory (hardware, software, virtual, container assets) is complete +- [ ] All external connections and third-party services are documented +- [ ] External services outside boundary are FedRAMP-authorized, GovRAMP-authorized, or + have documented compensating controls +- [ ] System categorization (FIPS 199 logic) is complete with impact level determination +- [ ] Data Classification Tool assessment completed (if impact level is uncertain) +- [ ] Service model is defined (SaaS / PaaS / IaaS) +- [ ] Leveraged cloud platform authorization documented (e.g., AWS GovCloud, Azure Government) + +--- + +## 3. Policies and Procedures + +- [ ] Information Security Policy — approved and in effect (L, M, H) +- [ ] Acceptable Use Policy / Rules of Behavior — documented and user-acknowledged (L, M, H) +- [ ] Access Control Policy (L, M, H) +- [ ] Configuration Management Policy and Plan (L, M, H) +- [ ] Incident Response Plan (IRP) — documented, tested within last 12 months (L, M, H) +- [ ] Contingency Plan (CP) — documented, tested within last 12 months (L, M, H) +- [ ] Media Protection Policy (M, H) +- [ ] Personnel Security Policy (L, M, H) +- [ ] Physical Security Policy (or fully inherited from IaaS provider) (L, M, H) +- [ ] Privacy policy and PII handling procedures documented (M, H) +- [ ] Supply Chain Risk Management policy (M, H) +- [ ] Change Management Policy (M, H) +- [ ] Vulnerability Management Policy (L, M, H) + +--- + +## 4. Access Control and Identity + +- [ ] Multi-factor authentication (MFA) enforced on all privileged accounts (L, M, H) +- [ ] MFA enforced on all remote access paths (L, M, H) +- [ ] Role-based access control (RBAC) implemented and documented (M, H) +- [ ] Least privilege principle applied and documented (L, M, H) +- [ ] Privileged account access reviews performed quarterly or more frequently (M, H) +- [ ] User access reviews performed at least annually (L, M, H) +- [ ] Account provisioning and de-provisioning process documented and in use (L, M, H) +- [ ] Shared/service accounts documented and controlled (M, H) +- [ ] Emergency access accounts documented and controlled (M, H) +- [ ] FIPS 140-2 or 140-3 validated authentication mechanisms in use (M, H) + +--- + +## 5. Encryption + +- [ ] All government data encrypted at rest using FIPS 140-2/3 validated modules (M, H) +- [ ] All government data encrypted in transit using TLS 1.2 minimum (1.3 preferred) (L, M, H) +- [ ] Key management procedures documented (M, H) +- [ ] Non-FIPS algorithms (MD5, SHA-1, DES, RC4) eliminated from the boundary (M, H) +- [ ] Certificate management process documented (expiration tracking) (M, H) + +--- + +## 6. Vulnerability Management + +Per the GovRAMP Vulnerability Scan Requirements Guide: + +- [ ] Automated vulnerability scanning program in place (L, M, H) +- [ ] Scans cover all OS-level components within the boundary (L, M, H) +- [ ] Scans cover all database components within the boundary (M, H) +- [ ] Scans cover all web application components within the boundary (M, H) +- [ ] Scans cover containers (if used) (M, H) +- [ ] Scan frequency meets GovRAMP requirements (minimum monthly for Moderate/High) (M, H) +- [ ] Penetration testing performed per GovRAMP Penetration Test Guidance (M, H) +- [ ] Penetration test conducted within the past 12 months (at minimum) (M, H) +- [ ] Vulnerability scan results are tracked and remediated per SLAs (L, M, H) +- [ ] All critical vulnerabilities tracked in POA&M with remediation plans (L, M, H) + +--- + +## 7. Logging and Monitoring + +- [ ] Centralized logging/SIEM is in place (M, H) +- [ ] All in-scope components are sending logs to centralized SIEM (M, H) +- [ ] Log retention period meets requirements (minimum 90 days online; 1 year retained) (M, H) +- [ ] Security alerts and anomalies are reviewed and actioned (M, H) +- [ ] Privileged account activity is logged (L, M, H) +- [ ] Audit logs are protected from modification or deletion (M, H) +- [ ] Network traffic monitoring in place (M, H) + +--- + +## 8. Incident Response + +- [ ] Incident Response Plan (IRP) is documented and current (L, M, H) +- [ ] IRP has been tested within the past 12 months (tabletop or functional exercise) (L, M, H) +- [ ] IRP test results are documented (L, M, H) +- [ ] Incident reporting timelines are defined and aligned with GovRAMP Incident + Communications Procedures (L, M, H) +- [ ] Contact information for GovRAMP PMO is in the IRP (L, M, H) +- [ ] Security incident categories are defined (L, M, H) +- [ ] Forensic evidence preservation procedures are documented (M, H) +- [ ] Lessons learned process exists post-incident (M, H) + +--- + +## 9. Contingency Planning + +- [ ] Contingency Plan (CP) is documented and current (L, M, H) +- [ ] CP defines Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) (L, M, H) +- [ ] CP has been tested within the past 12 months (L, M, H) +- [ ] CP test results are documented (L, M, H) +- [ ] Data backup and restoration procedures are documented and tested (L, M, H) +- [ ] Backup restoration tested successfully within the past 12 months (M, H) +- [ ] Alternate processing/hosting site or failover capability is documented (M, H) + +--- + +## 10. Configuration Management + +- [ ] Configuration baselines defined for all in-scope components (M, H) +- [ ] Configuration Management Plan documented (M, H) +- [ ] Change management process in place; changes reviewed and approved (M, H) +- [ ] System component inventory (CMDB) is current and accurate (M, H) +- [ ] Unauthorized change detection (file integrity monitoring or equivalent) in place (M, H) +- [ ] CIS Benchmarks or DISA STIGs applied where applicable (M, H) + +--- + +## 11. Personnel Security + +- [ ] Background screening process documented for staff with system access (L, M, H) +- [ ] Background checks conducted before granting access (M, H) +- [ ] Termination procedures documented (access revocation timeline) (L, M, H) +- [ ] Contractor and third-party access controls documented (M, H) +- [ ] Security awareness training program in place (L, M, H) +- [ ] Training completion is tracked and documented (L, M, H) +- [ ] Role-based security training for privileged users (M, H) + +--- + +## 12. Physical and Environmental Security + +- [ ] Physical security controls documented (or inherited from FedRAMP-authorized IaaS) (L, M, H) +- [ ] Access to servers and data center is restricted and logged (M, H) +- [ ] Environmental controls (temperature, humidity, fire suppression) documented or + inherited (M, H) + +--- + +## 13. System and Communications Protection + +- [ ] Network segmentation in place between in-scope and out-of-scope systems (M, H) +- [ ] Firewall rules documented and reviewed regularly (M, H) +- [ ] Web application firewall (WAF) or equivalent in place (M, H) +- [ ] Ports, protocols, and services (PPS) table is documented in the SSP (L, M, H) +- [ ] Boundary protection devices (firewalls, IDS/IPS) are in place and monitored (M, H) + +--- + +## 14. Privacy (NIST 800-53 Rev 5 PT Family) + +- [ ] Privacy policy published and available to government customers and end users (M, H) +- [ ] PII inventory or data map exists (M, H) +- [ ] Privacy impact assessment process in place for new system changes (M, H) +- [ ] Consent mechanisms documented for PII collection (where applicable) (M, H) + +--- + +## 15. CJIS Overlay (if applicable) + +Only required for providers handling Criminal Justice Information (CJI): + +- [ ] Provider has identified CJI data types in scope +- [ ] CJIS Security Policy requirements mapped to GovRAMP controls +- [ ] Using the GovRAMP Service Provider Package for Moderate Impact with CJIS Overlay +- [ ] Using the GovRAMP 3PAO Package for Moderate Impact with CJIS Overlay +- [ ] CJI handling, access, and storage controls documented separately + +--- + +## 16. Authorization Documentation Completeness + +- [ ] System Security Plan (SSP) is drafted using GovRAMP templates +- [ ] All required control implementation statements present in SSP +- [ ] Authorization boundary diagram embedded in SSP +- [ ] Data flow diagrams embedded in SSP +- [ ] PPS table completed in SSP +- [ ] External connections table completed in SSP +- [ ] Incident Response Plan included as SSP appendix or standalone +- [ ] Contingency Plan included as SSP appendix or standalone +- [ ] Plan of Action & Milestones (POA&M) is drafted +- [ ] All known gaps entered in POA&M with risk ratings and remediation plans +- [ ] Vulnerability scan results available for submission +- [ ] Penetration test report available (Ready and Authorized) + +--- + +## Readiness Summary (Completed Checklist Output) + +After completing the checklist, summarize: + +| Category | Met Count | Not Met Count | Blockers for Status? | +|----------|-----------|---------------|----------------------| +| Boundary / Documentation | | | | +| Policies and Procedures | | | | +| Access Control | | | | +| Encryption | | | | +| Vulnerability Management | | | | +| Logging / Monitoring | | | | +| Incident Response | | | | +| Contingency Planning | | | | +| Configuration Management | | | | +| Personnel Security | | | | +| Authorization Documentation | | | | + +**Top 5–10 Priority Gaps:** [List highest-risk items blocking the target status] + +**Recommended Next Step:** [Core / Ready / Authorized / Fast Track / Progressing Snapshot] diff --git a/plugins/govramp/skills/govramp/references/ssp-guide.md b/plugins/govramp/skills/govramp/references/ssp-guide.md new file mode 100644 index 0000000..17e6e2b --- /dev/null +++ b/plugins/govramp/skills/govramp/references/ssp-guide.md @@ -0,0 +1,248 @@ +# GovRAMP System Security Plan (SSP) Writing Guide + +The System Security Plan (SSP) is the foundational document for any GovRAMP +authorization. It describes what the system is, what data it handles, how the +authorization boundary is defined, and how each applicable NIST 800-53 Rev 5 control +is implemented. + +GovRAMP templates align with FedRAMP document structures and are accepted in FedRAMP +formatting. Always use official GovRAMP templates available at: +https://govramp.org/rev-5-templates-and-resources/ + +Service Provider Packages are available for: +- Low Impact +- Moderate Impact (most common) +- Moderate Impact with CJIS Overlay +- High Impact + +--- + +## SSP Section-by-Section Guide + +### Section 1: System Name and Identifier + +- Formal product/service name +- Unique product identifier +- Service model: SaaS / PaaS / IaaS +- Deployment model: Public / Private / Community / Hybrid cloud +- GovRAMP membership number (if available at time of writing) + +--- + +### Section 2: System Categorization and Impact Level + +- Complete FIPS 199 categorization for each information type handled: + - Confidentiality: Low / Moderate / High + - Integrity: Low / Moderate / High + - Availability: Low / Moderate / High +- Overall impact level = high-water mark of the three values +- Justify each categorization with the types of government information processed +- Cross-reference the GovRAMP Data Classification Tool output +- Identify whether CJIS Overlay applies + +**Common SSP mistakes:** +- Assigning "Low" to all categories without justification when moderate-sensitivity + government data is involved +- Not documenting information types — vague statements like "we process government data" + are insufficient + +--- + +### Section 3: System Ownership and Contacts + +- System Owner name, title, and contact information +- GovRAMP Program Manager contact +- Authorizing Official contact (government sponsor, once identified) +- Primary 3PAO contact (for Ready/Authorized paths) + +--- + +### Section 4: Assignment of Security Responsibility + +- Identify the person (title and contact) responsible for the overall security of the system +- Document the security team structure if applicable + +--- + +### Section 5: System Mission and Purpose + +- What does the system do? +- What government programs, agencies, or organizations does it serve? +- What types of government data does it handle? +- Who are the typical end users? + +--- + +### Section 6: General System Description + +- Narrative description of the technology stack +- Key system components (web servers, databases, APIs, integrations) +- Cloud platform and region (if cloud-hosted) +- Whether the system uses a FedRAMP-authorized IaaS/PaaS (AWS GovCloud, Azure Government, + Google Cloud FedRAMP regions) — critical for inherited control documentation + +--- + +### Section 7: Authorization Boundary (Highest Scrutiny) + +This is one of the most scrutinized sections in any GovRAMP review. + +**What to include:** +- Clear written narrative describing exactly what is inside and outside the boundary +- Which components process, store, or transmit government data (all must be inside) +- Which external services are used and whether they are in or out of scope +- Network architecture diagram embedded (not just referenced as an attachment) +- Data flow diagrams showing all data entering, leaving, and moving within the boundary +- Ports, Protocols, and Services (PPS) table +- External connections table (documenting every connection to services outside the boundary) + +**Inherited Controls:** +If the provider uses a FedRAMP-authorized IaaS/PaaS, document which controls are: +- Fully inherited: The IaaS/PaaS fully satisfies the control; provider has no additional obligation +- Partially inherited: The IaaS/PaaS satisfies part of the control; provider must address the remainder +- Not inherited: Provider fully implements the control + +**Common boundary mistakes:** +- Vague boundary language such as "our cloud environment" without specifying which + services, regions, and components are in scope +- Not documenting admin/management traffic flows (VPN, jump boxes, monitoring agents) +- Failing to document external SaaS tools used by operations staff that touch in-scope data +- Not updating the boundary when systems change + +--- + +### Section 8: Control Implementation Statements + +This is the largest and most critical section of the SSP. For each applicable NIST +800-53 Rev 5 control: + +**Required sub-elements per control:** + +1. **Implementation Status**: Implemented / Partially Implemented / Planned / Alternative Implementation +2. **Control Origination**: Provider (CSP), Customer/Government, Shared, or Inherited from leveraged service +3. **Implementation Description**: Prose narrative describing exactly how the control is satisfied + +**Writing principles:** + +- **Describe only what is implemented** — Do not describe planned or aspirational controls + as if they are in place. Unimplemented controls must go in the POA&M. +- **Be specific** — Reference exact tool names, policy document names, configuration + settings, section numbers. Vague language causes findings. +- **Address every verb** — Each control requirement uses specific action verbs (establish, + implement, enforce, document, review, test, monitor). Address each one explicitly. +- **Shared responsibility** — For any control where both the provider and the government + customer share responsibility, create a clear "Customer Responsibility" section. +- **Internal consistency** — Control statements must be consistent with the architecture + diagrams, data flow diagrams, and system inventory. Inconsistencies cause findings. + +**Example structure for a control narrative:** + +``` +AC-2 — Account Management + +Implementation Status: Implemented +Control Origination: Service Provider (with Customer Responsibility noted) + +The [System Name] manages user accounts using [identity management tool/system]. +Account provisioning requires approval from [role/team] via [ticketing system]. +Accounts are reviewed quarterly by [role] against the current inventory of +authorized users. Accounts are disabled within [X hours] of termination notification +received from [HR/manager via process]. + +Customer Responsibility: Government customers are responsible for notifying +[System Name] administrators within [timeframe] when a user transfers, changes +role, or is terminated. +``` + +--- + +### Section 9: Leveraged Authorizations + +If the system uses a FedRAMP-authorized or GovRAMP-authorized platform: + +- List each leveraged service name, authorization type (FedRAMP/GovRAMP), and impact level +- Use the Cloud Integration Standard (CIS) / Customer Responsibility Matrix (CRM) workbook + to document which controls are inherited vs. provider-implemented vs. customer responsibility +- The GovRAMP PMO accepts documents in FedRAMP formatting for this workbook + +--- + +### Section 10: Interconnections + +- List all external connections (to government systems, other vendors, etc.) +- For each interconnection: system name, owner, connection type, data type, security controls +- Interconnection Security Agreements (ISAs) or Memoranda of Understanding (MOUs) should + reference each interconnection + +--- + +## SSP Appendices Required for GovRAMP + +| Appendix | Content | +|----------|---------| +| Incident Response Plan (IRP) | Documented and tested within past 12 months | +| Contingency Plan (CP) | Documented and tested within past 12 months | +| Rules of Behavior | User acknowledgment of acceptable use | +| Privacy Impact Assessment (PIA) | Required for Moderate and High where PII is processed | +| Vulnerability Scan Results | Most recent scan results for all applicable layers | +| POA&M | All open findings with risk ratings and remediation plans | +| Authorization Boundary Diagram | Standalone diagram if not embedded in Section 7 | + +--- + +## SSP Writing Tips by Control Family + +### Access Control (AC) +- Be specific about how MFA is enforced — name the tool (e.g., Duo, Okta, Azure AD MFA) +- Document RBAC roles explicitly; generic statements like "we use role-based access" + are insufficient +- Address privileged account controls separately from standard user controls + +### Audit and Accountability (AU) +- Name the SIEM or logging platform +- Specify log retention: minimum 90 days accessible online, total 1 year retained +- Document who reviews logs and at what frequency +- Identify which audit events are captured (NIST 800-53 AU-2 event types) + +### Configuration Management (CM) +- Reference the specific baseline standard used (CIS Benchmark, DISA STIG) +- Name the configuration management tool (Ansible, Puppet, AWS Config, etc.) +- Describe the change management process and approval workflow + +### Identification and Authentication (IA) +- State that FIPS 140-2 or 140-3 validated cryptographic modules are used +- Reference the specific module (e.g., OpenSSL FIPS module) if known +- Describe password/authentication policy specifics (MFA types, session timeout) + +### Incident Response (IR) +- Reference the IRP appendix but also summarize roles, reporting timelines, and + GovRAMP reporting obligations in the control narrative +- Include the GovRAMP Incident Communications Procedures contact information + +### Risk Assessment (RA) +- Name the vulnerability scanning tools used and their scope (OS, DB, web app, container) +- Reference the scan frequency and confirm alignment with GovRAMP Vulnerability Scan + Requirements Guide +- Address penetration testing cadence and methodology + +### System and Communications Protection (SC) +- Document encryption in transit: TLS version and which connections are encrypted +- Document encryption at rest: algorithm, key length, FIPS module reference +- Describe network segmentation between in-scope and out-of-scope components + +--- + +## Common SSP Review Findings + +The following are frequently cited GovRAMP review findings that delay authorization: + +1. Control statements that say "we plan to implement" rather than "we have implemented" +2. Missing PPS table or incomplete external connections documentation +3. Architecture diagram that does not match the written boundary description +4. Inherited controls listed without referencing the specific leveraged authorization +5. Missing customer responsibility sections for shared controls +6. IRP and CP that have not been tested or lack test documentation +7. Incomplete POA&M — known gaps existed but were not documented +8. No documentation of vulnerability scans or scans that do not cover all boundary components +9. Encryption described vaguely — no module name, no algorithm specification +10. Logging not covering all in-scope components diff --git a/plugins/govramp/skills/govramp/references/status-pathways.md b/plugins/govramp/skills/govramp/references/status-pathways.md new file mode 100644 index 0000000..9a97015 --- /dev/null +++ b/plugins/govramp/skills/govramp/references/status-pathways.md @@ -0,0 +1,223 @@ +# GovRAMP Status Pathways — Decision Guide + +Use this reference when helping a provider or government entity determine the most +appropriate GovRAMP status pathway based on their situation, goals, resources, and +existing authorizations. + +--- + +## Status Pathway Overview + +| Status | 3PAO Required | Gov Sponsor | ConMon Frequency | Key Requirement | Listed on APL | +|--------|--------------|-------------|-----------------|-----------------|---------------| +| Progressing Snapshot | No | No | N/A (not verified) | Membership; quarterly engagement | No (Progressing List) | +| Core | No (PMO review) | No | Quarterly | 60 controls evidenced; templates | Yes | +| Ready | Yes (RAR) | No | Monthly + Annual | Min. mandatory req's; 50% docs | Yes | +| Authorized | Yes (SAR) | Yes | Monthly + Annual | All controls; 100% docs | Yes | +| Provisionally Authorized | Yes (SAR) | Pending/Committee | Monthly + Annual | All controls; sponsor in process | Yes | + +--- + +## Decision Tree: Which Pathway Is Right? + +### Step 1: Do you already hold FedRAMP authorization? + +**YES** → **Fast Track** is available. You can submit existing federal security documentation +(FedRAMP SSP, SAR, 90 days of ConMon data) to the GovRAMP PMO. GovRAMP accepts +documents in FedRAMP formatting. Fast Track applies to Ready or Authorized status. +Proceed to Step 5 for Fast Track specifics. + +**NO** → Proceed to Step 2. + +--- + +### Step 2: What is your primary goal? + +**A. Build initial credibility and visibility with less upfront investment** +→ Consider **Progressing Snapshot** first, then progress to Core or Ready. + +**B. Achieve a formal verified status without a full 3PAO audit** +→ Target **GovRAMP Core** (launched May 2025; 60 controls; PMO-reviewed). + +**C. Achieve full verified status demonstrating minimum mandatory requirements** +→ Target **GovRAMP Ready** (3PAO Readiness Assessment Report required). + +**D. Achieve the highest level of assurance to compete for major government contracts** +→ Target **GovRAMP Authorized / Provisionally Authorized** (3PAO SAR + government sponsor). + +--- + +### Step 3: What impact level do you need? + +Use the GovRAMP Data Classification Tool to determine your level: +https://govramp.org/blog/document/data-classification-tool/ + +| Government Data Type | Likely Impact Level | +|---------------------|---------------------| +| Public records, administrative tools, non-PII systems | Low | +| General PII, non-law-enforcement public records | Low+ or Moderate | +| Healthcare data (PHI), financial data, voter records | Moderate | +| Criminal Justice Information (CJI) | Moderate + CJIS Overlay | +| Emergency services, critical infrastructure, classified-adjacent data | High | + +Core status is aligned to the **Moderate** baseline regardless of the provider's +ultimate target level. It provides a foundation before pursuing full Moderate or High +authorization. + +--- + +### Step 4: What is your readiness? + +| Readiness State | Recommended Path | +|----------------|-----------------| +| Early stage; significant gaps; first time building a security program | Progressing Snapshot → Core | +| Documentation partially complete; controls partially implemented | Core (if no 3PAO budget) or Ready (if 3PAO budget available) | +| Documentation near-complete; controls mostly implemented | Ready → Authorized | +| Documentation fully complete; controls fully implemented | Authorized directly | +| FedRAMP-authorized or in active pursuit | Fast Track | + +--- + +### Step 5: Fast Track Decision + +**Prerequisites:** +- Active GovRAMP membership +- Existing FedRAMP authorization OR active FedRAMP pursuit with documentation available +- 90 days of continuous monitoring data +- Completed federal-approved security package + +**Fast Track Process:** +1. Submit a Security Review Request Form to the GovRAMP PMO +2. Work with 3PAO to gather and authenticate: federal security package, 90 days of + ConMon data, any required GovRAMP-specific template adjustments +3. PMO reviews package and conducts a review call with provider and 3PAO +4. Provider achieves Ready or Authorized status (PMO determination) +5. Begin GovRAMP Continuous Monitoring + +**Texas Note:** TX-RAMP recognizes GovRAMP with automatic reciprocity. GovRAMP provides +a weekly sync — GovRAMP-authorized products automatically appear on the TX-RAMP list. + +--- + +## Pathway Comparison — Effort and Cost + +### GovRAMP Core + +| Dimension | Detail | +|-----------|--------| +| Controls assessed | 60 (NIST 800-53 Rev 5 Moderate-aligned, MITRE ATT&CK prioritized) | +| Assessment method | PMO review of submitted documentation and evidence | +| 3PAO required | No | +| Policies required | Yes (for all 60 control areas) | +| Templates required | SSP, IRP, CP, Scan documentation (Moderate Impact package) | +| ConMon | Quarterly | +| Typical timeline | Shorter than Ready/Authorized (no 3PAO engagement) | +| Costs | Membership ($1,500+) + PMO Fee ($9,000–$17,000 depending on revenue) | +| APL listing | Yes | + +### GovRAMP Ready + +| Dimension | Detail | +|-----------|--------| +| Controls assessed | Minimum mandatory requirements for target impact level | +| Assessment method | 3PAO Readiness Assessment Report (RAR) | +| 3PAO required | Yes | +| Documentation required | 50% complete at submission; 100% by Authorized | +| ConMon | Monthly + Annual | +| Typical timeline | Longer than Core (requires 3PAO engagement) | +| Costs | Membership + 3PAO fees (market rate) + Ready review fee ($500–$3,750) | +| APL listing | Yes | + +### GovRAMP Authorized + +| Dimension | Detail | +|-----------|--------| +| Controls assessed | All required controls at target impact level (Low, Moderate, High) | +| Assessment method | Full 3PAO Security Assessment Report (SAR) | +| 3PAO required | Yes | +| Government sponsor | Required (direct government sponsor or GovRAMP Approvals Committee) | +| Documentation required | 100% complete | +| ConMon | Monthly + Annual | +| Typical timeline | Longest of all paths | +| Costs | Membership + 3PAO fees + Authorized review fee ($1,500–$7,500) + ConMon monthly fee | +| APL listing | Yes (as Authorized) | + +--- + +## Government Sponsorship + +### What Is a Government Sponsor? + +For GovRAMP Authorized status, an authorizing government official (at a state, local, +education, tribal, or special district organization) must review and approve the +provider's security package. + +### Two Sponsorship Options + +**Option 1: Direct Government Sponsor** +A specific government agency agrees to sponsor the provider. The sponsoring agency +reviews the security package and signs off on the authorization. + +Requirements for the sponsoring government (from the GovRAMP Provider Sponsor +Requirements document): +- Must be an active GovRAMP member (or become one) +- Must designate a responsible government official +- Must review and accept the provider's security package + +**Option 2: GovRAMP Approvals Committee** +If a provider cannot secure a direct government sponsor, the GovRAMP Approvals +Committee (composed of active state and local government representatives) can serve +as the appointed sponsor and confirm the package meets all requirements. This results +in **GovRAMP Provisionally Authorized** status until a formal government sponsor +assumes responsibility. + +--- + +## Progressing Snapshot: When to Use It + +The Progressing Snapshot is **not a verified status**. Products are listed on the +Progressing Product List, not the Authorized Product List. Use this pathway when: + +- The provider is in early stages of building a security program +- The organization wants PMO guidance before committing to 3PAO assessment costs +- The organization wants to appear on the GovRAMP product list in a non-verified + capacity while working toward Core, Ready, or Authorized +- The provider is exploring what level of effort full authorization will require + +**January 1, 2026 Change:** Products on the Progressing List must demonstrate active +advancement toward a verified status. Products failing to show progress are subject to +escalation and potential removal from the Progressing List. + +--- + +## Appeals and Exceptions + +The GovRAMP **Appeals Committee** handles: +- Conflict-of-interest claims +- Disagreements over status determinations +- Requests for exceptions + +The Appeals Committee is composed of at least five members appointed by the Board, +including at least one Board member. The Executive Committee may appoint subject matter +experts to assist with specific claims. + +--- + +## Glossary of Key Terms + +| Term | Definition | +|------|-----------| +| APL | Authorized Product List — GovRAMP's public listing of products with verified security status | +| 3PAO | Third-Party Assessment Organization — an independent assessor accredited to conduct GovRAMP assessments | +| SLED | State, Local, Education, and tribal governments — GovRAMP's primary target customer base | +| PMO | Program Management Office — GovRAMP's PMO is serviced by RAMPQuest, powered by Knowledge Services | +| ConMon | Continuous Monitoring — ongoing security reporting obligations for authorized products | +| RAR | Readiness Assessment Report — 3PAO deliverable for the Ready status path | +| SAR | Security Assessment Report — 3PAO deliverable for the Authorized status path | +| SSP | System Security Plan — the foundational security documentation for a service provider | +| POA&M | Plan of Action and Milestones — tracks open findings and remediation plans | +| IRP | Incident Response Plan — required at all authorization levels including Core | +| CP | Contingency Plan — required at all authorization levels including Core | +| CJI | Criminal Justice Information — data type requiring the CJIS Overlay at Moderate impact level | +| Fast Track | Expedited GovRAMP authorization pathway for FedRAMP-authorized providers | +| TX-RAMP | Texas Risk and Authorization Management Program — recognizes GovRAMP with reciprocity | diff --git a/plugins/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/iso27018/.claude-plugin/plugin.json b/plugins/iso27018/.claude-plugin/plugin.json new file mode 100644 index 0000000..a993544 --- /dev/null +++ b/plugins/iso27018/.claude-plugin/plugin.json @@ -0,0 +1,23 @@ +{ + "name": "iso27018", + "description": "Expert ISO/IEC 27018 compliance assistant for protecting personally identifiable information (PII) in public cloud environments. Covers Annex A extended controls, PII processor obligations, gap analysis, data subject rights, sub-processor management, government request handling, and alignment with GDPR and ISO 27701.", + "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": [ + "iso27018", + "pii", + "cloud-privacy", + "data-protection", + "gdpr", + "public-cloud", + "pii-processor", + "compliance", + "grc" + ] +} diff --git a/plugins/iso27018/skills/iso27018/SKILL.md b/plugins/iso27018/skills/iso27018/SKILL.md new file mode 100644 index 0000000..9f27920 --- /dev/null +++ b/plugins/iso27018/skills/iso27018/SKILL.md @@ -0,0 +1,313 @@ +--- +name: iso27018 +description: > + Expert ISO/IEC 27018 compliance assistant for protecting personally identifiable information (PII) + in public cloud environments. Use this skill whenever a user asks about ISO 27018, ISO/IEC 27018, + cloud PII protection, PII processors in the public cloud, Annex A extended controls for cloud + privacy, obligations of cloud service providers regarding personal data, sub-processor + management, government disclosure requests, data subject rights in cloud contexts, or any + question involving a cloud provider's duty to protect customer PII. Also trigger for requests to + draft data processing agreements, sub-processor clauses, PII protection policies, gap analysis + against ISO 27018, privacy notices for cloud services, or mapping ISO 27018 to GDPR or + ISO 27701. Trigger even if the user does not say "skill" — any ISO 27018, cloud PII, or PII + processor question should use this skill. +--- + +# ISO/IEC 27018 Compliance Skill + +You are an expert ISO/IEC 27018 Lead Auditor and cloud privacy specialist assisting **compliance, legal, and security teams** at organisations acting as public cloud PII processors. You have deep knowledge of ISO/IEC 27018:2025 (third edition, aligned with ISO 27002:2022), ISO/IEC 27018:2019 (second edition, aligned with ISO 27002:2013), the ISO 29100 privacy principles, and the relationship between ISO 27018, GDPR, ISO 27701, and ISO 27001. + +--- + +## Standard Overview + +| Attribute | Detail | +|-----------|--------| +| Full title (2025) | ISO/IEC 27018:2025 — Information security, cybersecurity and privacy protection — Guidelines for protection of personally identifiable information (PII) in public clouds acting as PII processors | +| Full title (2019) | ISO/IEC 27018:2019 — Information technology — Security techniques — Code of practice for protection of PII in public clouds acting as PII processors | +| Current edition | Third edition — ISO/IEC 27018:2025 (published August 2025, aligned with ISO 27002:2022) | +| Previous edition | Second edition — ISO/IEC 27018:2019 (withdrawn; aligned with ISO 27002:2013) | +| First edition | ISO/IEC 27018:2014 | +| Prepared by | ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection) | +| Normative references (2025) | ISO/IEC 27000, ISO/IEC 27002:2022, ISO/IEC 22123-1 | +| Normative references (2019) | ISO/IEC 17788, ISO/IEC 27000, ISO/IEC 27002:2013 | +| Informative references | ISO/IEC 27001, ISO/IEC 27005, ISO/IEC 27017, ISO/IEC 27701, ISO/IEC 29100, ISO/IEC 29134 | + +--- + +## Version History + +| Edition | Year | Base Standard | Key Change | +|---------|------|---------------|------------| +| First | 2014 | ISO 27002:2013 | Original publication — PII controls for public cloud | +| Second | 2019 | ISO 27002:2013 | Minor revision — corrected editorial mistake in Annex A | +| Third | 2025 | ISO 27002:2022 | Technical revision — realigned all controls with ISO 27002:2022 structure; added Annex B | + +> Default to **2025** (third edition) unless the user specifies otherwise. Where version matters, always confirm. + +--- + +## Who It Applies To + +ISO/IEC 27018 applies to **public cloud service providers (CSPs) acting as PII processors** — organisations that process personally identifiable information (PII) on behalf of, and under the instructions of, a **cloud service customer**. + +**Roles defined by ISO 27018:** + +| Role | Definition | ISO 27018 Applicability | +|------|-----------|------------------------| +| **PII principal** | Natural person to whom PII relates (equivalent to "data subject" under GDPR) | Rights holder | +| **PII controller** | Determines purposes and means of PII processing | Often the cloud service customer | +| **PII processor** | Processes PII on behalf of, and per instructions of, a PII controller | **Primary addressee of ISO 27018** | +| **Public cloud service provider** | Party making cloud services available under the public cloud model | Typically the PII processor under this standard | +| **Cloud service customer** | Organisation/individual with a contractual relationship with the CSP | May be a PII controller | + +**Service types in scope:** IaaS, PaaS, SaaS — any public cloud service model where PII is processed. + +**Note:** Where the CSP processes its own customer account data, it may act as a PII controller for that activity. ISO 27018 does not cover that role; see ISO 27701 for PII controller obligations. + +--- + +## How to Respond + +Always confirm which version of ISO 27018 the user is working with before responding. Default to **2025** if unspecified. + +Match output format to the task: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Control Area \| Topic \| Status \| Evidence Needed \| Gap Notes | +| Policy/document generation | Full structured document with purpose, scope, roles, procedures, review cycle | +| Control implementation guidance | Structure: Purpose → Obligation → What to implement → Evidence for audit → Common pitfalls | +| Contract clause drafting | Ready-to-use clause text with annotation | +| Compliance mapping | Side-by-side mapping table (ISO 27018 control ↔ GDPR article / ISO 27701 control) | +| General question | Clear, concise prose with citations | + +--- + +## Standard Structure + +### ISO 27018:2025 (Third Edition — aligned with ISO 27002:2022) + +The 2025 edition follows the same four-theme structure as ISO 27002:2022: + +| Clause | Theme | Scope | +|--------|-------|-------| +| 5 | Organisational controls | Policies, roles, supplier relationships, incident management, compliance | +| 6 | People controls | Screening, terms of employment, awareness, training, off-boarding | +| 7 | Physical controls | Physical perimeters, entry, equipment, media | +| 8 | Technological controls | Access, cryptography, logging, vulnerability management, data protection | +| Annex A (normative) | Extended PII controls | Additional controls for cloud PII protection, organized per ISO 29100 privacy principles | +| Annex B (new in 2025) | Additional guidance | Supplementary implementation guidance added in third edition | + +### ISO 27018:2019 (Second Edition — aligned with ISO 27002:2013) + +The 2019 edition follows the ISO 27002:2013 domain structure: + +| Clauses | Domains | +|---------|---------| +| 5–6 | Policies, Organisation | +| 7–8 | Human resources, Asset management | +| 9–10 | Access control, Cryptography | +| 11–12 | Physical security, Operations security | +| 13–14 | Communications, System acquisition | +| 15–16 | Supplier relationships, Incident management | +| 17–18 | Business continuity, Compliance | +| Annex A (normative) | Extended PII controls for cloud | + +--- + +## ISO 27018 Annex A — Extended Control Set for Cloud PII Protection + +Annex A is **normative** and contains controls that extend beyond ISO 27002, organized around the **11 privacy principles of ISO/IEC 29100**. These controls are unique to ISO 27018 and address PII-specific risks in the public cloud context. + +Load `references/annex-a-controls.md` for the complete Annex A control details. + +### Privacy Principle Summary + +| ISO 29100 Principle | Core Obligation Under ISO 27018 Annex A | +|--------------------|-----------------------------------------| +| **1. Consent and choice** | CSP shall not process PII for purposes other than those specified by the cloud service customer | +| **2. Purpose legitimacy and specification** | No use of PII for commercial, marketing, or advertising purposes without customer's explicit consent | +| **3. Collection limitation** | Notify customers before making material changes to PII collection/processing activities | +| **4. Data minimization** | Temporary files containing PII must be identified and securely deleted; access to PII limited to what is necessary | +| **5. Use, retention and disclosure limitation** | Return, transfer or dispose of PII at end of contract; notify customers of legally required disclosure requests | +| **6. Accuracy and quality** | Provide mechanisms enabling customers to correct, update or delete PII | +| **7. Openness, transparency and notice** | Disclose which sub-processors are used; disclose the countries/regions in which PII is processed | +| **8. Individual participation and access** | Assist customers in fulfilling PII principals' rights (access, correction, erasure, portability) | +| **9. Accountability** | Designate a dedicated PII contact; maintain records of all disclosures to third parties | +| **10. Information security** | Implement documented PII security policies; make evidence of compliance available to customers | +| **11. Privacy compliance** | Disclose applicable data protection authorities; enable customer audit rights | + +--- + +## Key Obligations for Public Cloud PII Processors + +The following obligations are fundamental to ISO 27018 compliance. Consult `references/annex-a-controls.md` for full control details. + +### 1. No Use of PII for Own Purposes +The CSP shall not process PII entrusted to it by cloud service customers for its own commercial, marketing, or advertising purposes without the customer's explicit, separate consent. This includes: +- Behavioural advertising based on customer data +- Profiling PII principals for the CSP's own products +- Sharing PII with third parties for their commercial purposes + +### 2. Sub-processor Obligations +- The CSP shall not engage sub-processors without the knowledge and approval of the cloud service customer +- All sub-processors must be contractually bound to the same PII protection obligations as the CSP +- The CSP shall maintain and disclose a current list of sub-processors to cloud service customers +- The CSP remains liable for sub-processor compliance + +### 3. Government and Law Enforcement Requests +- If legally required to disclose PII, the CSP shall notify the affected cloud service customer promptly (unless legally prohibited from doing so) +- The CSP shall maintain a record of all legally required disclosures of PII to third parties +- Where possible, the CSP shall publish transparency reports or publicly available summaries of disclosure requests + +### 4. Return, Transfer and Disposal of PII +- At the end of the service contract, the CSP shall return all PII to the customer and/or delete it securely +- The CSP shall confirm in writing that PII has been returned/deleted +- Any copies held for legal, regulatory, or audit purposes must be identified and treated accordingly + +### 5. Data Residency Transparency +- The CSP shall be transparent about the countries and regions in which PII is processed and stored +- Changes to data residency must be disclosed to customers in advance + +### 6. Employee Access Controls +- Access to PII shall be limited to employees with a legitimate business need +- All employees with access to PII shall be under appropriate confidentiality obligations +- CSP shall maintain access logs for PII systems +- CSP shall implement PII-specific staff training + +### 7. Audit and Compliance Evidence +- The CSP shall provide cloud service customers with practical means to verify compliance with PII obligations +- Acceptable evidence includes independent audit reports (e.g. ISO 27001 certification, SOC 2 reports), self-assessment results, or direct audit access +- Certifications and audit reports shall be made available on request + +--- + +## Core Workflows + +### 1. Gap Analysis +When asked to perform or help with a gap analysis against ISO 27018: + +1. Confirm which version (2019 or 2025) is being assessed +2. Identify whether the organisation is a PII processor, a PII controller, or both +3. For each Annex A control area and each modified ISO 27002 control, assess: + - **Design:** Is a policy/control designed and documented? + - **Implementation:** Is it actually in place? + - **Evidence:** Can it be demonstrated to a customer or auditor? + +Use this RAG status: +- **Implemented** — control is in place, documented, and evidenced +- **Partial** — control exists but has gaps (undocumented, inconsistently applied, evidence missing) +- **Not Implemented** — no control exists or control is clearly insufficient +- **N/A** — not applicable with documented justification + +**Gap analysis table format:** +| Control Area | Specific Obligation | Status | Evidence Needed | Gap / Notes | +|---|---|---|---|---| + +### 2. Policy and Document Generation +When generating ISO 27018-related documents, load `references/templates.md` for template structures. + +Common documents: +- **PII Protection Policy** — governing CSP's use of customer PII +- **Data Processing Agreement (DPA) addendum** — ISO 27018 obligation clauses for customer contracts +- **Sub-processor Agreement** — contract terms binding sub-processors to ISO 27018 obligations +- **Government Request Handling Procedure** — process for receiving, assessing, and responding to legal disclosure requests +- **PII Return and Deletion Procedure** — end-of-contract PII handling +- **Staff PII Awareness Training Acknowledgment** +- **Sub-processor Register** — maintained list of approved sub-processors + +Always include in generated documents: +- Document control block: Version | Author | Approved By | Date | Next Review +- Scope and applicability statement +- Roles and responsibilities +- References to relevant ISO 27018 control areas +- Statement that the document is for informational/framework purposes (recommend legal review for formal use) + +### 3. Control Implementation Guidance +For any ISO 27018 control or Annex A obligation, structure the response as: + +**Control: [Control Area / Topic]** +- **Obligation:** What ISO 27018 requires +- **Why it exists:** The privacy risk or regulatory driver +- **What to implement:** Concrete, actionable steps for a cloud service provider +- **Evidence for audit/customer review:** What a customer or third-party auditor will look for +- **Common pitfalls:** What cloud providers typically miss + +### 4. Compliance Mapping +When mapping ISO 27018 to other frameworks, load `references/compliance-mapping.md`. + +Key relationships: +- **ISO 27018 ↔ GDPR** — ISO 27018 directly supports GDPR compliance for cloud data processors; many annex A controls align directly with GDPR Articles 28, 32, 33, 44–49 +- **ISO 27018 ↔ ISO 27701** — ISO 27027701 is the PIMS extension to ISO 27001/27002 and addresses both PII controllers and processors in greater depth; ISO 27018 can be used alongside ISO 27701 +- **ISO 27018 ↔ ISO 27017** — ISO 27017 covers general cloud security controls (for both CSPs and cloud customers); ISO 27018 is PII-specific +- **ISO 27018 ↔ ISO 27001** — ISO 27018 does not require ISO 27001 certification but is typically implemented within an ISO 27001 ISMS; the ISMS provides the management framework + +--- + +## Mandatory Documentation Checklist + +Produce this as a checklist when asked about ISO 27018 readiness: + +**Policies and Procedures:** +- [ ] PII Protection Policy (governing CSP use of customer PII) +- [ ] Acceptable Use Policy for PII (internal — staff obligations) +- [ ] Sub-processor Management Policy (selection, approval, monitoring) +- [ ] Government and Law Enforcement Request Handling Procedure +- [ ] PII Return, Transfer and Disposal Procedure (end-of-contract) +- [ ] Data Breach / PII Incident Notification Procedure +- [ ] Data Residency and Transfer Policy + +**Registers and Records:** +- [ ] Sub-processor Register (current list with contact, purpose, contractual status) +- [ ] Record of Legally Required PII Disclosures (per Annex A) +- [ ] Access Log for PII systems (who accessed what and when) +- [ ] PII Incident/Breach Log + +**Contracts:** +- [ ] Standard DPA / data processing terms (ISO 27018 obligations to customers) +- [ ] Sub-processor Agreement template (binding sub-processors to same obligations) +- [ ] Confidentiality agreements for staff with PII access + +**Evidence Artefacts:** +- [ ] Staff PII awareness training records +- [ ] Sub-processor due diligence records (assessments, audit rights exercised) +- [ ] Compliance evidence portfolio (certifications, third-party audit reports) +- [ ] Transparency report or disclosure request summary (where publicly available) + +--- + +## Relationship to Other Standards + +Load `references/compliance-mapping.md` for full mapping tables. + +| Standard | Relationship | +|----------|-------------| +| **ISO 27001:2022** | Provides the ISMS management framework within which ISO 27018 controls are implemented. Not required for ISO 27018 but strongly recommended. | +| **ISO 27002:2022** | ISO 27018:2025 extends ISO 27002:2022 controls with PII-specific implementation guidance. ISO 27018 does not repeat ISO 27002 controls — it augments them. | +| **ISO 27017** | Companion standard for general cloud security controls; ISO 27018 is the PII-specific extension. Many organisations implement both. | +| **ISO 27701:2019** | PIMS extension to ISO 27001/27002 — addresses privacy management for both controllers and processors; more comprehensive privacy governance than ISO 27018 alone but designed for different purpose. | +| **ISO 29100:2011** | Privacy framework providing the 11 privacy principles that underpin ISO 27018 Annex A. Not itself certifiable. | +| **ISO 29134** | Guidelines for Privacy Impact Assessment (PIA) — useful for evaluating cloud PII processing activities. | +| **GDPR (EU)** | ISO 27018 compliance supports GDPR Article 28 obligations (processor contracts) and Article 32 (appropriate technical/organisational measures). Not a substitute for full GDPR compliance. | + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +| File | When to load | +|------|-------------| +| `references/annex-a-controls.md` | Annex A control questions, gap analysis, control implementation guidance | +| `references/pii-protection-guidance.md` | Implementation questions, technical safeguards, staff training, sub-processor management | +| `references/templates.md` | Generating policies, DPA clauses, procedures, checklists, training acknowledgments | +| `references/compliance-mapping.md` | Mapping ISO 27018 to GDPR, ISO 27701, ISO 27017, ISO 27001 | + +Load **all relevant files** for broad requests (e.g., "help us achieve full ISO 27018 compliance"). + +--- + +## Important Disclaimer + +> This skill provides guidance based on publicly available information about ISO/IEC 27018 and related standards. It is for informational purposes only and does not constitute legal advice. For formal compliance determinations, procurement of the full standard text, or legal assessments of data protection obligations, consult qualified legal and compliance professionals and obtain the official ISO/IEC 27018 standard from ISO or your national standards body. diff --git a/plugins/iso27018/skills/iso27018/references/annex-a-controls.md b/plugins/iso27018/skills/iso27018/references/annex-a-controls.md new file mode 100644 index 0000000..c66b617 --- /dev/null +++ b/plugins/iso27018/skills/iso27018/references/annex-a-controls.md @@ -0,0 +1,347 @@ +# ISO/IEC 27018 — Annex A Extended Control Set for PII Protection in Public Cloud + +## Overview + +Annex A of ISO/IEC 27018 is **normative** and contains an extended set of controls that go beyond those in ISO/IEC 27002. These controls address PII protection requirements specific to public cloud service providers acting as PII processors that are not addressed by the base ISO 27002 control set. + +The controls are organized in line with the **11 privacy principles of ISO/IEC 29100**: + +1. Consent and choice +2. Purpose legitimacy and specification +3. Collection limitation +4. Data minimization +5. Use, retention and disclosure limitation +6. Accuracy and quality +7. Openness, transparency and notice +8. Individual participation and access +9. Accountability +10. Information security +11. Privacy compliance + +--- + +## Version Note + +- **ISO 27018:2019 (2nd edition):** Annex A aligned with ISO 27002:2013 domain structure +- **ISO 27018:2025 (3rd edition):** Annex A retained and updated; Annex B added; controls aligned with ISO 27002:2022 + +The underlying obligations in Annex A are substantially consistent across both editions. The 2025 edition refines language and aligns with ISO 27002:2022 control taxonomy. + +--- + +## Annex A Controls — By Privacy Principle + +### Principle 1: Consent and Choice + +**Obligation: No processing of PII beyond purposes specified by the cloud service customer** + +The CSP shall not process PII entrusted to it by a cloud service customer for any purpose other than what the customer has instructed. The CSP acts exclusively as a processor — it has no independent right to determine the purpose of processing. + +**What this means in practice:** +- The CSP's service agreement must clearly define the purposes for which PII may be processed +- The CSP must not use customer PII to develop its own products, train its own AI models, or for any purpose not authorised by the customer +- Where the CSP processes customer account data (e.g. billing information), it may act as a PII controller for that subset — ISO 27018 does not govern that activity +- Any proposed change to processing purpose requires customer consent before implementation + +**Evidence for audit:** +- Service agreement clauses defining scope and purpose of PII processing +- Internal policies prohibiting unauthorised secondary use of customer PII +- Staff training records confirming employees understand purpose limitation + +--- + +### Principle 2: Purpose Legitimacy and Specification + +**Obligation: No use of PII for commercial, marketing, or advertising purposes** + +The CSP shall not use PII processed on behalf of a cloud service customer for its own commercial purposes — including targeted advertising, cross-selling, profiling, or sharing with third parties for their marketing. + +**Specific controls:** + +**2a. Prohibition on marketing use of PII** +- Contracts with cloud service customers must explicitly prohibit the CSP from using customer PII for direct marketing, behavioural advertising, or profiling for commercial gain +- This prohibition applies whether the PII is processed in aggregate, pseudonymised, or individually +- The prohibition must also bind CSP's affiliates and sub-processors + +**2b. Restriction on sub-processor use** +- Sub-processors may only process PII for the purposes specified by the cloud service customer +- Sub-processor agreements must include equivalent purpose limitation restrictions + +**Evidence for audit:** +- Customer contract terms prohibiting commercial use of PII +- Sub-processor agreement clauses with equivalent protections +- Advertising and analytics policy documentation confirming customer PII is excluded + +--- + +### Principle 3: Collection Limitation + +**Obligation: Transparency and notification regarding PII processing activities** + +The CSP shall not make material changes to how it processes customer PII without providing adequate advance notice to the cloud service customer. This allows customers to fulfil their own notification obligations to PII principals. + +**Specific controls:** + +**3a. Notification before material changes** +- Before making changes that affect the nature or scope of PII processing, the CSP must notify the customer with sufficient lead time to allow assessment and action +- Material changes include: additions or changes to sub-processors, changes to data residency, changes to retention periods, changes to access controls + +**3b. Completing information about activities by sub-processors** +- The CSP must provide the customer with sufficient information about sub-processors to enable the customer to complete their own processing records (e.g. Article 30 GDPR records) +- This includes sub-processor name, country of processing, purpose, and applicable safeguards + +**Evidence for audit:** +- Change notification policy and documented notification sent to customers +- Sub-processor information provided to customers (register or contractual schedule) +- Records of advance notifications made + +--- + +### Principle 4: Data Minimization + +**Obligation: Temporary files and minimal access to PII** + +**4a. Temporary files containing PII** +When the CSP creates temporary files, intermediate copies, or cache data that contains PII as part of delivering its services, it shall: +- Identify and document the creation of such temporary PII +- Define and enforce a retention period for temporary files (minimum: deleted promptly after operational need expires) +- Apply the same access and security controls to temporary files as to primary PII stores +- Include temporary file management in data disposal procedures + +Examples of temporary PII sources: processing queues, backup staging areas, log files, debugging artefacts, CDN caches. + +**4b. Access minimization — employee access to PII** +- Employee access to PII shall be restricted to the minimum necessary to fulfil the service (principle of least privilege) +- Privileged access to PII storage must be individually justified and time-limited where possible +- Access rights must be reviewed regularly (at minimum annually) and revoked promptly upon role change or departure +- Administrator access to systems storing PII must be subject to multi-factor authentication + +**Evidence for audit:** +- Documented temporary file handling procedure +- Access control policy with least-privilege provisions for PII +- Access review records (periodic reviews showing revocations) +- Privileged access management records + +--- + +### Principle 5: Use, Retention and Disclosure Limitation + +**Obligation: Return, transfer, disposal of PII and disclosure notification** + +**5a. Return, transfer and disposal of PII** +At the end of the service contract (including termination for any reason), the CSP shall: +- Return all PII to the cloud service customer, transfer it to an alternative provider at the customer's direction, or securely delete/destroy it +- Provide written confirmation that all PII (including all copies, backups, and any data held by sub-processors) has been returned or deleted +- The timeframe for return/disposal shall be agreed in the service contract (a common standard is 30–90 days) +- Retain a minimal audit record (not PII content) documenting that disposal occurred + +**5b. PII disclosure to third parties — notification obligations** +When the CSP is legally required (e.g. court order, government authority request) to disclose PII to a third party, the CSP shall: +- Notify the affected cloud service customer promptly, unless legally prohibited from doing so (e.g. official secrecy order, national security direction) +- Document all legally required disclosures in a disclosure register +- Challenge legally defective or overbroad requests where legally permitted to do so +- Not voluntarily disclose PII to any government, law enforcement, or third party except as required by law or instructed by the cloud service customer + +**5c. Record of disclosures** +The CSP shall maintain a disclosure register recording: +- Date and nature of the request +- Requesting authority/organisation +- Legal basis cited +- What PII was disclosed +- Whether customer was notified (and if not, why) +- Any legal challenge made + +**Evidence for audit:** +- Service contract clauses governing PII return/deletion +- Written confirmation letters issued to customers upon contract termination +- Disclosure register (may be provided in redacted form to customers on request) +- Internal procedure for handling government/law enforcement requests + +--- + +### Principle 6: Accuracy and Quality + +**Obligation: Supporting PII accuracy and enabling corrections** + +The CSP shall implement mechanisms that enable cloud service customers to maintain the accuracy and quality of PII held in the cloud service: +- Provide APIs, admin interfaces, or data export capabilities that allow customers to update, correct, and delete PII +- Not impede corrections, updates, or deletions requested by the customer or by PII principals exercising their rights +- Process data correction and deletion requests within agreed response times +- Ensure deletion propagates to backups, caches, and sub-processors within a defined period + +**Evidence for audit:** +- Product documentation showing update/delete capabilities +- API documentation or admin console guides +- Response time SLAs for data deletion requests +- Evidence that deletion cascades to sub-processors + +--- + +### Principle 7: Openness, Transparency and Notice + +**Obligation: Sub-processor disclosure and data residency transparency** + +**7a. Disclosure of sub-processors** +The CSP shall: +- Maintain a current, accessible list of all sub-processors used to process customer PII +- Notify customers in advance of adding new sub-processors or replacing existing ones (advance notice period typically defined in contract — a common standard is 30 days) +- Provide customers with the contractual right to object to new sub-processors +- Ensure the sub-processor list includes: sub-processor name, registered country, purpose, and applicable jurisdiction + +**7b. Data residency and transfer transparency** +The CSP shall: +- Disclose the countries and regions in which customer PII may be processed, stored, or transferred +- Provide advance notice of changes to data residency locations +- Where PII is transferred to countries outside the customer's jurisdiction, clearly identify the applicable international transfer mechanism (e.g. SCCs, adequacy decision, BCRs) +- Make data residency information readily available in service documentation (not only on request) + +**7c. Government and law enforcement request transparency** +Where legally permitted, the CSP shall publish aggregated information (a transparency report) about: +- The number and types of government/law enforcement requests received +- The jurisdictions from which requests originated +- The proportion of requests challenged or rejected + +This need not identify specific customers but demonstrates the CSP's accountability posture. + +**Evidence for audit:** +- Sub-processor register (current, dated, accessible to customers) +- Advance notification records for sub-processor changes +- Service documentation or DPA schedule identifying data residency locations +- Transparency report (if published) or policy confirming CSP's approach + +--- + +### Principle 8: Individual Participation and Access + +**Obligation: Supporting data subject (PII principal) rights** + +The CSP shall not impede a cloud service customer's ability to fulfil the rights of PII principals. Specific obligations: + +**8a. Access to PII by CSP employees** +- Employee access to PII (including production data) shall be controlled, logged, and limited +- Routine service delivery shall not require CSP employees to access PII content +- Any access to customer PII by CSP staff (e.g. for troubleshooting) must be: + - Authorised by the CSP's internal approval process + - Notified to the cloud service customer where operationally practicable + - Logged and subject to review + +**8b. Supporting customer fulfilment of data subject rights** +- The CSP shall provide technical and administrative mechanisms enabling customers to respond to data subject requests (access, rectification, erasure, restriction, portability, objection) +- Export functions, deletion APIs, and data portability formats shall be documented and supported +- The CSP shall not charge unreasonable fees for assisting with data subject rights + +**Evidence for audit:** +- Access log for CSP employee access to customer PII (with justification records) +- Product documentation of data export and deletion capabilities +- Customer support procedure for assisting with data subject rights requests + +--- + +### Principle 9: Accountability + +**Obligation: Dedicated contact, records of disclosures, and breach notification** + +**9a. Dedicated point of contact for PII/privacy** +The CSP shall designate a specific named role (or team) responsible for PII protection matters: +- Contact details must be made available to cloud service customers +- The contact role must have authority to respond to PII queries, complaints, and regulatory enquiries +- The role may be a Data Protection Officer (DPO) under GDPR or an equivalent function + +**9b. Records of disclosures to third parties** +- All disclosures of customer PII to third parties (mandatory or voluntary) shall be recorded in a disclosure register +- The register shall be available to customers on request (in whole or in redacted form) +- The register entry shall include: date, recipient, legal basis, data categories, and whether customer was notified + +**9c. PII incident / data breach notification** +Where a security incident results in, or may result in, accidental or unlawful access to, loss, destruction, or alteration of PII, the CSP shall: +- Notify the affected cloud service customer without undue delay (many contracts specify 24–72 hours from discovery) +- Include in the notification: nature of the incident, categories and approximate volume of PII affected, likely consequences, measures taken or proposed +- Support customers in fulfilling their own breach notification obligations to supervisory authorities and PII principals +- Maintain an incident log with full details + +**Evidence for audit:** +- Privacy/PII contact information published in service documentation +- Disclosure register (maintained, accessible) +- Incident notification procedure with defined timelines +- Evidence of breach notifications issued (anonymised/redacted for audit purposes) + +--- + +### Principle 10: Information Security + +**Obligation: Implementing documented PII security policies and providing transparency** + +**10a. PII security policy** +The CSP shall implement a documented information security policy specifically addressing PII protection in its cloud environment: +- Policy must be approved by senior management +- Policy shall address: access control, encryption, logging, incident response, sub-processor requirements, and staff obligations +- Policy shall be reviewed at defined intervals (typically annually or following significant changes) + +**10b. Making security information available to customers** +The CSP shall make available to cloud service customers sufficient information about its security practices to enable customers to: +- Assess whether security is appropriate for their risk profile +- Fulfil their own due diligence obligations (e.g. Article 28 GDPR assessments) +- Exercise their audit rights + +Acceptable forms include: ISO 27001 certification, SOC 2 Type II reports, security whitepapers, public security pages, or direct audit access. + +**Evidence for audit:** +- Documented PII security policy (current, approved, reviewed) +- Customer-facing security documentation (whitepaper, trust page, certification) +- Certification certificates (ISO 27001, SOC 2) with scope including PII processing + +--- + +### Principle 11: Privacy Compliance + +**Obligation: Disclosing applicable authorities and enabling customer audit rights** + +**11a. Area of competent supervisory authority** +The CSP shall inform cloud service customers of: +- The countries and legal jurisdictions in which PII is processed +- The data protection supervisory authorities that have jurisdiction over its activities +- Any applicable international transfer mechanisms in use + +This information enables customers to understand which regulations apply to their data and which authorities they could approach in the event of a complaint. + +**11b. Enabling customer audit rights** +The CSP shall provide cloud service customers with practical means to verify that the CSP complies with its PII protection obligations. Options include: +- Third-party certification (ISO 27001, ISO 27018, SOC 2) with clearly defined scope +- Independent audit reports shared with customers under NDA +- Customer-conducted audits or inspections (subject to reasonable notice and security requirements) +- Self-assessment questionnaires (e.g. CSA CAIQ) completed and made available + +**Evidence for audit:** +- Legal jurisdiction and transfer mechanisms documented in DPA or service schedule +- Customer contract clause granting audit rights +- Evidence portfolio ready for customer requests (certifications, reports, questionnaires) + +--- + +## Summary Table — Annex A Control Areas + +| Privacy Principle | Control Topic | Key Obligation | +|------------------|---------------|----------------| +| Consent and choice | Purpose limitation | No processing beyond customer instructions | +| Purpose limitation | No commercial use | No use for marketing or advertising without consent | +| Purpose limitation | Sub-processor purpose | Sub-processors bound to same purpose restrictions | +| Collection limitation | Change notification | Advance notice of material changes to processing | +| Collection limitation | Sub-processor information | Sufficient info for customer processing records | +| Data minimization | Temporary files | Identify and delete; apply same controls | +| Data minimization | Access minimization | Least privilege; access reviews; MFA for privileged access | +| Use/retention/disclosure | PII return and disposal | Return or securely delete all PII at contract end; written confirmation | +| Use/retention/disclosure | Disclosure notification | Notify customers of legally required disclosures (unless prohibited) | +| Use/retention/disclosure | Disclosure records | Maintain complete disclosure register | +| Accuracy and quality | Data correction support | Enable corrections; ensure deletion cascades | +| Openness/transparency | Sub-processor list | Maintain, disclose, and give advance notice of changes | +| Openness/transparency | Data residency | Disclose processing locations; notify changes | +| Openness/transparency | Law enforcement transparency | Publish transparency report where permitted | +| Individual participation | Employee access controls | Control, log, and limit CSP employee access to PII | +| Individual participation | Data subject rights support | Provide technical tools for customer to fulfil DSRs | +| Accountability | Dedicated PII contact | Named role with contact details available to customers | +| Accountability | Disclosure register | Record all third-party PII disclosures | +| Accountability | Breach notification | Notify customers without undue delay; support their obligations | +| Information security | PII security policy | Documented, approved, reviewed policy | +| Information security | Security transparency | Provide certifications/reports to customers | +| Privacy compliance | Supervisory authority | Disclose applicable authorities and jurisdictions | +| Privacy compliance | Customer audit rights | Practical means to verify compliance | diff --git a/plugins/iso27018/skills/iso27018/references/compliance-mapping.md b/plugins/iso27018/skills/iso27018/references/compliance-mapping.md new file mode 100644 index 0000000..308519c --- /dev/null +++ b/plugins/iso27018/skills/iso27018/references/compliance-mapping.md @@ -0,0 +1,233 @@ +# ISO/IEC 27018 — Compliance Mapping Reference + +## Overview + +This reference maps ISO/IEC 27018 obligations to related frameworks, enabling organisations to understand where compliance evidence overlaps and where gaps must be addressed independently. + +--- + +## 1. ISO 27018 ↔ GDPR (EU General Data Protection Regulation) + +ISO/IEC 27018 aligns closely with GDPR because both address the obligations of organisations that process personal data on behalf of others (processors). ISO 27018 compliance provides strong evidence of technical and organisational measures for GDPR Article 28 and 32 purposes, but does not constitute full GDPR compliance. + +### Mapping Table + +| ISO 27018 Obligation | GDPR Article | GDPR Requirement | +|---------------------|--------------|-----------------| +| No processing beyond customer instructions | Art. 28(3)(a) | Processor processes only on documented instructions | +| No use for commercial/marketing purposes | Art. 28(3)(b) | Processor must ensure confidentiality | +| Sub-processor obligation — same terms | Art. 28(2), 28(4) | Sub-processors must be contracted with same data protection obligations | +| Sub-processor disclosure and advance notice | Art. 28(2) | Controller must be informed of and authorise sub-processors | +| Government request notification | Art. 28(3)(a) | Processor must inform controller unless prohibited by law | +| PII return and deletion at contract end | Art. 28(3)(g) | Delete or return all personal data after end of services | +| Technical security measures | Art. 32(1) | Appropriate technical and organisational measures | +| Encryption of PII | Art. 32(1)(a) | Pseudonymisation and encryption where appropriate | +| PII incident notification | Art. 33(2) | Processor must notify controller without undue delay | +| Support for data subject rights | Art. 28(3)(e) | Processor assists controller in responding to DSRs | +| Breach notification — 72 hours | Art. 33(1) | Controller must notify supervisory authority within 72 hours | +| Privacy by design | Art. 25 | Data protection by design and by default | +| DPO designation | Art. 37–39 | DPO required in certain circumstances | +| Records of processing activities | Art. 30(2) | Processors must maintain records | +| International transfers | Art. 44–49 | Transfers to third countries require appropriate safeguards | +| Customer audit rights | Art. 28(3)(h) | Processor contributes to audits and inspections | +| Supervisory authority identification | Art. 77 | Right to lodge complaint with supervisory authority | + +### Key Gaps: ISO 27018 does not cover + +ISO 27018 compliance alone does not satisfy: +- GDPR lawful basis for processing (Art. 6) — obligation of the controller, not processor +- GDPR rights obligations that fall on controllers (Arts. 15–22 directly) +- GDPR transparency / privacy notice obligations (Art. 13–14) — controller obligation +- GDPR data protection impact assessments (Art. 35) — controller-led; ISO 29134 relevant +- GDPR provisions specific to special category data (Art. 9) +- GDPR consent requirements (Art. 7) — controller's obligation + +--- + +## 2. ISO 27018 ↔ ISO/IEC 27701 + +ISO/IEC 27701:2019 is the Privacy Information Management System (PIMS) extension to ISO 27001 and ISO 27002. It covers both PII controllers and PII processors in more depth than ISO 27018. + +### Relationship Summary + +| Dimension | ISO 27018 | ISO 27701 | +|-----------|-----------|-----------| +| Scope | PII processors; public cloud only | PII controllers AND processors; any context | +| Base standard | ISO 27002 | ISO 27001 + ISO 27002 | +| Management system | Not a management system | PIMS — formal management system certification | +| Certification | No formal ISO 27018 certification scheme (typically demonstrated via ISO 27001 + extended controls) | ISO 27701 certification available | +| Depth of privacy coverage | Operational controls for cloud PII processors | Comprehensive privacy governance framework | +| Controller obligations | Not addressed | Addressed (separate annex for controllers) | + +### ISO 27018 Annex A → ISO 27701 Mapping (selected controls) + +| ISO 27018 Obligation | ISO 27701 Section | +|---------------------|-------------------| +| Purpose limitation (no commercial use) | 7.2.1 — Identify and document purposes | +| Sub-processor management | 7.5.2 — PII processors engaging other PII processors | +| Government request handling | 7.3.7 — Disclosure to third parties | +| PII return and deletion | 7.4.7 — Return, transfer or disposal of PII | +| Sub-processor register | 7.5.6 — PII sub-processor obligations | +| Incident notification to customers | 7.3.4 — Handling of PII processors' data breaches | +| Support for data subject rights | 7.3.2 — Determining the lawful basis | +| Customer audit rights | 7.5.5 — Enabling customers to comply with obligations | +| Transparency / sub-processor disclosure | 7.4.3 — Providing information to PII principals | +| Dedicated privacy contact | 7.2.8 — Ensuring privacy by design and default | + +### Recommendation + +Organisations requiring formal PIMS certification should pursue ISO 27701. ISO 27018 is useful as a cloud-specific supplement or as an interim framework before ISO 27701 implementation. The two are complementary, not mutually exclusive. + +--- + +## 3. ISO 27018 ↔ ISO/IEC 27017 + +ISO/IEC 27017 is the cloud security extension to ISO 27002, covering general cloud security controls for both cloud service providers and cloud service customers. ISO 27018 is the PII-specific extension. + +### Relationship Summary + +| Dimension | ISO 27017 | ISO 27018 | +|-----------|-----------|-----------| +| Focus | General information security in cloud | PII/personal data protection in public cloud | +| Addresses | CSP and cloud customer both | Primarily CSP acting as PII processor | +| Privacy controls | Limited | Core purpose of the standard | +| Sub-processor content | Some | Detailed PII sub-processor obligations | +| Shared responsibility model | Addressed | Addressed in context of PII | + +### Combined Implementation + +Most cloud providers implementing ISO 27018 should also implement ISO 27017 because: +- ISO 27017 provides the cloud security foundation; ISO 27018 adds PII-specific controls +- Many customers expect both standards to be in scope when assessing cloud providers for PII processing +- Some ISO 27017 controls directly support ISO 27018 obligations (e.g. virtual machine hardening supports PII encryption and access control obligations) + +### Cross-Reference (selected) + +| ISO 27017 Control Area | Relevance to ISO 27018 | +|-----------------------|-----------------------| +| CSP-specific: Asset management (return of assets) | Supports ISO 27018 PII return/deletion obligation | +| CSP-specific: Sharing roles (shared responsibility) | Defines CSP vs. customer PII responsibilities | +| Modified 13.1 (network controls) | Supports PII in-transit encryption | +| Modified 9.1 (access to networks) | Supports PII access control obligations | +| Modified 12.1 (operational procedures) | Supports PII operational security | +| Modified 16.1 (incident management) | Supports PII breach notification obligations | + +--- + +## 4. ISO 27018 ↔ ISO/IEC 27001 + +ISO 27001 provides the ISMS management framework within which ISO 27018 controls are typically implemented. ISO 27018 does not require ISO 27001 certification, but the two are designed to work together. + +### Relationship Summary + +| Dimension | ISO 27001 | ISO 27018 | +|-----------|-----------|-----------| +| Type | Management system standard (certifiable) | Code of practice (guidelines) | +| Focus | Information security management | PII protection in public cloud | +| Certification | Yes — widely recognised | No formal certification; demonstrated via ISMS certification + extended controls | +| Risk-based approach | Core requirement | Referenced; relies on ISO 27001 risk framework | +| Annex A | 93 controls (2022) or 114 controls (2013) | Extended controls for cloud PII (via ISO 27018 Annex A) | + +### How They Work Together + +1. ISO 27001 establishes the ISMS (policies, risk assessment, management review, continual improvement) +2. ISO 27002 provides the control guidance that ISO 27001 Annex A references +3. ISO 27018 extends ISO 27002 with PII-specific guidance for cloud providers +4. When an organisation certifies to ISO 27001 and extends its SoA to include ISO 27018 Annex A controls, this demonstrates ISO 27018 compliance within the certified ISMS + +### ISO 27018 Annex A → ISO 27001/27002 Context + +ISO 27018 Annex A controls are additional controls that supplement (not replace) the ISO 27002/27001 Annex A controls. When preparing a Statement of Applicability (SoA) for a CSP processing PII, include ISO 27018 Annex A controls alongside the standard ISO 27002 Annex A. + +--- + +## 5. ISO 27018 ↔ ISO/IEC 29100 (Privacy Framework) + +ISO/IEC 29100 is the foundational privacy framework that provides the 11 privacy principles underpinning ISO 27018 Annex A. + +### Privacy Principles Mapping + +| ISO 29100 Principle | ISO 27018 Annex A Implementation | +|--------------------|----------------------------------| +| 1. Consent and choice | No processing beyond customer instructions; no commercial use without consent | +| 2. Purpose legitimacy and specification | No marketing/advertising use; purpose defined in contract | +| 3. Collection limitation | Change notification; sub-processor information disclosure | +| 4. Data minimization | Temporary file controls; access limitation | +| 5. Use, retention and disclosure limitation | PII return/deletion at contract end; disclosure notification and register | +| 6. Accuracy and quality | Data correction/deletion mechanisms for customers | +| 7. Openness, transparency and notice | Sub-processor list; data residency disclosure; government request transparency | +| 8. Individual participation and access | Employee access controls; data subject rights support | +| 9. Accountability | Dedicated privacy contact; disclosure register; breach notification | +| 10. Information security | PII security policy; evidence of compliance | +| 11. Privacy compliance | Supervisory authority disclosure; customer audit rights | + +### Note +ISO 29100 is not certifiable and serves as a reference framework. ISO 27018 is the operational implementation of ISO 29100 principles for the public cloud PII processor context. + +--- + +## 6. ISO 27018 ↔ Regional Data Protection Laws + +ISO 27018 was designed as a jurisdiction-neutral international standard but has explicit alignment with common data protection law requirements. + +### Alignment Overview + +| Jurisdiction | Framework | ISO 27018 Support | +|-------------|-----------|-------------------| +| European Union | GDPR | Strong alignment — see Section 1 above | +| United Kingdom | UK GDPR + DPA 2018 | Same as EU GDPR; UK retained GDPR post-Brexit | +| United States | CCPA (California) | Partial — transparency and data subject rights aligned | +| United States | HIPAA (healthcare) | Partial — security measures aligned; HIPAA has additional requirements | +| Brazil | LGPD | Significant alignment — processor chapter parallels GDPR obligations | +| India | DPDP Act 2023 | Alignment on processor obligations and data principal rights | +| Australia | Privacy Act 1988 | Supports APP compliance; APPs 1, 6, 11 in particular | +| Canada | PIPEDA / Law 25 (Quebec) | Substantive alignment on processor and security obligations | +| Japan | APPI | Alignment on security, cross-border transfer, data minimization | +| Singapore | PDPA | Alignment on processor obligations and security measures | +| China | PIPL | Partial alignment — PIPL has stricter requirements in some areas | + +### Using ISO 27018 for Regulatory Compliance + +ISO 27018 provides a strong baseline for demonstrating compliance with cloud data processor obligations across multiple jurisdictions. However: +- It does not substitute for jurisdiction-specific legal advice +- Some jurisdictions (e.g. China's PIPL) impose requirements that go beyond ISO 27018 +- Data localisation requirements in some jurisdictions must be addressed separately +- Specific sectoral requirements (healthcare, finance) layer on top of ISO 27018 obligations + +--- + +## 7. ISO 27018 ↔ CSA Cloud Controls Matrix (CCM) + +The Cloud Security Alliance (CSA) Cloud Controls Matrix v4 maps to ISO 27018 across several control domains. + +### Key CCM Domains with ISO 27018 Alignment + +| CCM Domain | Relevance to ISO 27018 | +|------------|------------------------| +| DSP (Data Security and Privacy) | Core alignment — privacy controls, data classification, data residency | +| STA (Supply Chain, Transparency, Accountability) | Sub-processor management, transparency reporting | +| SEF (Security Incident Management) | PII breach notification and incident handling | +| IAM (Identity and Access Management) | Employee access controls; least privilege; MFA | +| CEK (Cryptography, Encryption, Key Management) | PII encryption at rest and in transit | +| LOG (Logging and Monitoring) | Access logging for PII systems | +| GRC (Governance, Risk and Compliance) | PII policy; audit rights; compliance evidence | + +Organisations using the CSA CCM as part of a STAR certification programme can align CSA STAR Level 2 (ISO 27001-based) with ISO 27018 obligations using this cross-reference. + +--- + +## 8. ISO 27018 Certification Landscape + +### There is no standalone ISO 27018 certification scheme. + +Compliance with ISO 27018 is typically demonstrated through one or more of the following: + +| Mechanism | Description | +|-----------|-------------| +| **ISO 27001 certification with ISO 27018 scope** | The ISMS is certified under ISO 27001 with the audit scope including ISO 27018 Annex A controls | +| **CSA STAR Certification (Level 2)** | ISO 27001-based STAR certification can include ISO 27018 controls in scope | +| **SOC 2 Type II with Privacy TSC** | Addresses similar obligations; widely accepted in North America | +| **Third-party attestation report** | Independent auditor produces an attestation report confirming compliance with ISO 27018 obligations | +| **Customer questionnaire completion** | CSP completes detailed security questionnaire (SIG, CSA CAIQ) covering ISO 27018 topics | + +**Best practice:** Combine ISO 27001 certification (provides the certifiable management system assurance) with ISO 27018 as the extended control set, and make certification evidence accessible to customers via a Trust page, security portal, or on request. diff --git a/plugins/iso27018/skills/iso27018/references/pii-protection-guidance.md b/plugins/iso27018/skills/iso27018/references/pii-protection-guidance.md new file mode 100644 index 0000000..9f6e4a5 --- /dev/null +++ b/plugins/iso27018/skills/iso27018/references/pii-protection-guidance.md @@ -0,0 +1,354 @@ +# ISO/IEC 27018 — PII Protection Implementation Guidance + +## Purpose + +This reference provides practical implementation guidance for cloud service providers (CSPs) seeking to comply with ISO/IEC 27018. It covers technical safeguards, organisational measures, staff provisions, sub-processor management, and operational controls. + +--- + +## 1. Technical Safeguards for PII in Cloud Environments + +### 1.1 Encryption + +**At rest:** +- All PII stored in cloud infrastructure must be encrypted using current strong algorithms (AES-256 or equivalent) +- Database-level, file-system-level, or object-level encryption is acceptable; key management must be documented +- Customer-managed encryption keys (CMEK) should be offered as an option, giving customers control over their own data confidentiality +- Key rotation policies must be documented and enforced + +**In transit:** +- All network transmission of PII must use TLS 1.2 or higher (TLS 1.3 preferred) +- Internal service-to-service communications carrying PII must also use encrypted channels +- Deprecated protocols (SSL, TLS 1.0, TLS 1.1) must be disabled +- Certificate management processes must be documented + +**Key management:** +- Encryption keys must be managed separately from the data they protect +- Key access must be controlled with the same rigour as access to PII itself +- Key escrow or recovery procedures must be documented to prevent data loss in the event of key loss + +--- + +### 1.2 Access Control for PII Systems + +**Least privilege principle:** +- Every user, service account, and automated process must have the minimum permissions required for their function +- PII data stores must not be accessible by default; access must be explicitly provisioned +- Database admin access must be separate from application access; both must be separately logged + +**Identity and authentication:** +- Multi-factor authentication (MFA) is required for all accounts with access to production PII +- Service accounts should use workload identity federation or short-lived credentials instead of long-lived passwords +- Shared accounts must not have access to PII + +**Access reviews:** +- All access rights to PII systems must be reviewed at minimum every 6 months (quarterly for privileged access) +- Reviews must result in documented revocations where access is no longer required +- Access review records must be retained for at least 2 years + +**Privileged access management:** +- Break-glass or emergency access procedures must be documented and require post-use review +- Just-in-time (JIT) privileged access is the preferred model for production PII environments +- All privileged access sessions in PII environments must be logged (session recording where technically feasible) + +--- + +### 1.3 Logging and Monitoring + +**Access logs:** +- All access to PII storage (read, write, delete, update) must be logged +- Logs must include: timestamp, user/service identity, action performed, data object identifier (not PII content) +- Logs must be protected from tampering and stored separately from the systems they monitor +- Log retention minimum: 12 months (extend to 24–36 months where regulation requires) + +**Anomaly detection:** +- Automated alerting for: large-scale data exports, unusual access patterns, access outside business hours, failed access attempts +- Security Information and Event Management (SIEM) or equivalent monitoring must cover PII-handling systems +- Alerts resulting in investigation must be documented with outcome + +**Audit trail:** +- An end-to-end audit trail must enable reconstruction of PII access events for any given time period +- Audit trails must be available to cloud service customers on request (in a form that does not expose other customers' data) + +--- + +### 1.4 Data Minimization and Retention + +**Collection minimization:** +- The CSP's service must not collect more PII from customers than is required to deliver the service +- Log collection in particular must be reviewed to ensure PII does not inadvertently appear in operational logs +- Data minimization must be considered at the design stage for new features (privacy by design) + +**Retention and deletion:** +- Retention periods for all categories of PII must be documented and enforced +- Automated deletion processes must be in place where PII exceeds defined retention limits +- Deletion must propagate through all tiers: primary storage, backups, caches, replicas, sub-processors +- For cloud customers' PII, deletion on customer instruction must be technically possible and complete within an agreed timeframe + +**Temporary file management:** +- Processes that create temporary files, buffers, or intermediate copies containing PII must be documented +- Temporary PII must be classified as PII and subject to the same access controls as primary PII +- Automated deletion of temporary PII must occur as soon as the operational need expires +- Debugging, diagnostic, and log files must be screened to prevent inadvertent PII retention + +--- + +### 1.5 Data Residency Controls + +**Technical enforcement of residency:** +- Where data residency commitments are made to customers, technical controls must enforce them (data cannot be processed outside committed regions) +- Regional routing, geofencing, and data localisation features must be demonstrated and auditable +- Regional failover or replication must not silently break residency commitments + +**Residency verification:** +- Customers should be able to verify the region(s) in which their PII is processed (e.g. through admin console, API, or documentation) +- Changes to data residency must be notified in advance with opportunity for customers to object or migrate data + +--- + +## 2. Organisational Measures + +### 2.1 PII Protection Roles + +**Minimum required roles:** + +| Role | Responsibility | +|------|---------------| +| **Data Protection Contact / DPO** | Primary point of contact for PII matters; receives regulatory enquiries; accessible to cloud service customers | +| **Cloud Privacy Lead / Privacy Counsel** | Owns PII policy framework; advises on contractual obligations; manages regulatory relationships | +| **Security Operations** | Implements and monitors technical controls for PII protection; manages incidents | +| **Procurement / Vendor Management** | Manages sub-processor due diligence and contracts | +| **Customer Success / Legal** | Handles customer DPA queries, data subject rights escalations, and customer audit requests | + +**RACI for key ISO 27018 processes:** + +| Activity | Responsible | Accountable | Consulted | Informed | +|----------|-------------|-------------|-----------|----------| +| Sub-processor assessment | Procurement | Privacy Lead | Legal, Security | Customers (via schedule) | +| Government request handling | Legal | DPO/Privacy Lead | CISO | Customer (where permitted) | +| PII incident notification | Security Ops | CISO | Legal, DPO | Customer, Regulator | +| Customer audit support | Customer Success | Privacy Lead | Security, Legal | Auditor/Customer | +| PII return/deletion at contract end | Engineering | Privacy Lead | Legal | Customer | + +--- + +### 2.2 Staff Training and Awareness + +**Required training elements for staff with access to PII:** +1. What constitutes PII under ISO 27018 and applicable law +2. The CSP's obligations as a PII processor (no secondary use, no commercial use) +3. How to handle customer PII access requests and data subject rights escalations +4. The CSP's government/law enforcement request handling procedure +5. Confidentiality obligations and consequences of breach +6. How to recognise and report a PII-related security incident + +**Training delivery:** +- Mandatory for all R&D, engineering, operations, customer support, and management staff with potential PII access +- New hire training must be completed before access is provisioned +- Annual refresher training for all in-scope staff +- Additional role-specific training for staff in DBA, cloud operations, and customer success roles + +**Evidence requirements:** +- Training completion records (name, date, course, signature or system confirmation) +- Competency assessment records where role-specific training includes assessment +- Acknowledgment of confidentiality obligations + +--- + +### 2.3 Confidentiality Obligations for Staff + +All staff and contractors with access to customer PII must: +- Sign a confidentiality agreement or non-disclosure undertaking covering PII +- Acknowledge that they must not use customer PII for any purpose other than delivering the contracted service +- Acknowledge penalties for breach (employment disciplinary process; potential civil/criminal liability) + +The confidentiality obligation must: +- Survive the end of the employment or contractor relationship +- Explicitly cover PII and not simply refer to general business confidentiality +- Be documented and retained in personnel records + +--- + +### 2.4 Incident and Breach Management + +**PII-specific incident classification:** + +| Severity | Definition | Customer Notification | +|----------|------------|----------------------| +| Critical | Confirmed unauthorised access to or exfiltration of PII | Within 24 hours of confirmation | +| High | Suspected PII breach; containment incomplete | Within 48 hours of awareness | +| Medium | PII security event with low impact; contained | Within 72 hours; or per contract | +| Low | Incident with no PII exposure confirmed | As part of periodic security reporting | + +**Notification contents (minimum):** +- Nature and description of the incident +- Categories of PII affected (e.g. names, email addresses, health data) +- Approximate number/volume of PII principals affected +- Likely consequences of the breach +- Measures taken or proposed to address the breach and mitigate its effects +- Name and contact details of the DPO or designated contact for further information + +**Post-incident obligations:** +- Customers must be supported in completing their own regulatory notification requirements +- Full incident report provided to customers within a defined timeframe (commonly 30 days) +- Lessons learned review must be completed and documented +- Corrective action plan must be communicated to affected customers + +--- + +## 3. Sub-processor Management + +### 3.1 Sub-processor Selection and Approval + +**Due diligence requirements before onboarding a new sub-processor:** +- Confirm the sub-processor can meet ISO 27018 equivalent obligations +- Review the sub-processor's data protection certifications, audit reports, or questionnaire responses +- Assess the sub-processor's breach notification capability and track record +- Confirm the sub-processor has a documented DPO or privacy contact +- Evaluate the sub-processor's data residency capabilities against customer commitments + +**Approval process:** +- Documented business justification for using the sub-processor +- Security and legal sign-off before onboarding +- Record in sub-processor register before first PII processing commences +- Customer notification per contractual requirement (typically 30 days in advance for new sub-processors) + +--- + +### 3.2 Sub-processor Agreements — Required Contract Terms + +All sub-processor agreements must include: + +| Term | Requirement | +|------|-------------| +| **Purpose limitation** | Sub-processor may only process PII for the purposes specified in the agreement; no commercial use or secondary processing | +| **No further sub-processing** | Sub-processor may not engage additional sub-processors without prior written approval from the CSP | +| **Security standards** | Sub-processor must implement security measures equivalent to or exceeding the CSP's obligations under ISO 27018 | +| **Breach notification** | Sub-processor must notify CSP of any PII incident within 24 hours of discovery | +| **Return and deletion** | Sub-processor must return or delete all PII at end of service; written confirmation required | +| **Audit rights** | CSP must have the right to audit the sub-processor or receive third-party audit reports | +| **Data residency** | Sub-processor must process PII only in agreed locations; changes require advance approval | +| **Regulatory compliance** | Sub-processor must comply with applicable data protection laws | +| **Liability** | Sub-processor remains liable to CSP for breach of agreement terms | +| **Survival** | Confidentiality and data deletion obligations survive termination of the agreement | + +--- + +### 3.3 Ongoing Sub-processor Monitoring + +- Annual review of sub-processor certifications and audit reports (or following significant incidents) +- Track the sub-processor register for any changes in sub-processor status (acquisition, certification lapse, regulatory sanction) +- Periodically verify that sub-processors are processing PII only in approved locations +- Conduct periodic re-assessment for high-risk sub-processors (those with access to large volumes of sensitive PII) + +--- + +### 3.4 Sub-processor Register — Required Fields + +| Field | Description | +|-------|-------------| +| Sub-processor name | Legal entity name | +| Registered country | Country of incorporation | +| Data processing location(s) | Countries/regions where PII is actually processed | +| Purpose | Specific function performed on behalf of CSP | +| Categories of PII processed | Types of PII shared with this sub-processor | +| Legal transfer mechanism | If outside EEA/UK: SCCs, adequacy, BCRs, etc. | +| Certification / audit report | Current certification or most recent audit reference | +| Customer notification date | Date customers were notified of this sub-processor | +| Contract reference | Internal reference to the sub-processor agreement | +| Review date | Date of last due diligence review | + +--- + +## 4. Government and Law Enforcement Request Handling + +### 4.1 Receiving a Request + +When a government authority, law enforcement agency, or court issues a request for customer PII, the CSP shall: + +1. **Log the request immediately** — record receipt date, requesting authority, nature of request, PII categories requested, deadline +2. **Legal review** — route to Legal immediately; assess whether the request is legally valid, properly authorised, and limited in scope +3. **Do not disclose prematurely** — no PII shall be disclosed until legal review is complete (unless imminent harm prevents delay) +4. **Challenge if appropriate** — if the request is overbroad, lacks proper legal basis, or conflicts with the CSP's legal obligations to customers, the CSP shall challenge the request + +### 4.2 Customer Notification + +Unless legally prohibited (e.g. by a court order, national security direction, or law prohibiting notification): +- Notify the affected cloud service customer promptly — within 24–48 hours of receiving the request +- Notification must include: requesting authority, nature of request, data categories requested +- If prohibited from notifying: record the prohibition in the disclosure register; publish aggregate transparency data where permitted + +### 4.3 Disclosure and Recording + +If disclosure is required after legal review: +- Disclose only the minimum PII necessary to satisfy the legal obligation +- Record the disclosure fully in the disclosure register +- Provide written record to the customer (post-prohibition if applicable) +- Note in transparency report (in aggregate form) for future publication + +### 4.4 Transparency Reporting + +The CSP shall publish an aggregate transparency report covering: +- Total number of government/law enforcement requests received in the reporting period +- Jurisdictions of requesting authorities (where disclosable) +- Number of requests fulfilled in full, in part, or rejected +- Number of requests where customer notification was legally prohibited + +--- + +## 5. Privacy by Design in Cloud Service Development + +When developing new features, services, or processing capabilities that involve PII: + +**Privacy by Design principles to apply:** + +1. **Proactive not reactive** — anticipate PII risks before development; privacy requirements included in design specifications +2. **Privacy as default** — services must default to maximum privacy settings; customers must opt into less protective configurations, not opt out of more protective ones +3. **Privacy embedded into design** — PII protection is embedded into architecture, not bolted on post-development +4. **Full functionality** — privacy and security are not treated as trade-offs; both must be achieved +5. **End-to-end security** — PII is protected throughout its full lifecycle in the service +6. **Visibility and transparency** — documentation of how PII is processed must be accessible to customers +7. **Respect for users** — customer and PII principal interests are kept central to design decisions + +**Privacy impact assessment (PIA):** +- A PIA should be conducted before launching new processing activities involving PII +- PIA should assess: what PII is processed, for what purpose, the risk to PII principals, and proposed mitigations +- ISO/IEC 29134 provides guidance on PIAs in the cloud context + +--- + +## 6. Compliance Verification and Evidence Management + +### 6.1 Internal Audit + +The CSP should conduct periodic internal audits of its ISO 27018 compliance: +- Minimum frequency: annually; more frequently where high volumes of sensitive PII are processed +- Audit scope: all Annex A control areas; sample testing of key obligations (sub-processor contracts, access logs, notification records) +- Audit findings must be tracked to remediation with documented closure + +### 6.2 Customer Audit Rights + +Customers have the right under ISO 27018 to verify compliance. The CSP should prepare: + +**Tier 1 — Always available:** +- Current ISO 27018-aligned certifications (e.g. ISO 27001, SOC 2 with privacy criteria) +- Security whitepaper covering PII protection measures +- Sub-processor register (current version) +- Summary of government request handling procedures + +**Tier 2 — Available on request under NDA:** +- Most recent third-party security audit report +- Penetration test summaries (redacted) +- Internal audit summary (last completed) + +**Tier 3 — Negotiable for high-risk / high-volume customers:** +- Direct audit access (on-site or remote) with reasonable notice (typically 30–60 days) +- Completion of customer security questionnaires (CSA CAIQ, SIG, etc.) +- Independent third-party audit commissioned by customer (costs typically to customer; CSP cooperation required) + +### 6.3 Evidence Retention + +All compliance evidence must be retained for a minimum of: +- **3 years** for operational records (access logs, training records, notification records) +- **Length of contract + 3 years** for customer-specific records (DPAs, sub-processor notifications, disposal confirmations) +- **6–10 years** for legal/regulatory records (court orders, disclosure register entries) — confirm per jurisdiction diff --git a/plugins/iso27018/skills/iso27018/references/templates.md b/plugins/iso27018/skills/iso27018/references/templates.md new file mode 100644 index 0000000..a5f9604 --- /dev/null +++ b/plugins/iso27018/skills/iso27018/references/templates.md @@ -0,0 +1,642 @@ +# ISO/IEC 27018 — Document Templates + +## Template Index + +| Template | Purpose | +|----------|---------| +| [T1: PII Protection Policy](#t1-pii-protection-policy) | Internal policy governing CSP's obligations for customer PII | +| [T2: DPA Addendum — ISO 27018 Obligations](#t2-data-processing-agreement-addendum) | Contract clauses for cloud service agreements with customers | +| [T3: Sub-processor Agreement Schedule](#t3-sub-processor-agreement-schedule) | Contract terms binding sub-processors to equivalent obligations | +| [T4: Government Request Handling Procedure](#t4-government-request-handling-procedure) | Internal procedure for receiving and responding to legal disclosure requests | +| [T5: PII Return and Disposal Confirmation Letter](#t5-pii-return-and-disposal-confirmation-letter) | Written confirmation to customers at contract end | +| [T6: Sub-processor Register](#t6-sub-processor-register) | Operational register of approved sub-processors | +| [T7: Disclosure Register](#t7-disclosure-register) | Record of legally required disclosures of PII to third parties | +| [T8: Staff PII Awareness Training Acknowledgment](#t8-staff-pii-awareness-training-acknowledgment) | Acknowledgment form for staff completing PII training | +| [T9: PII Incident Notification to Customer](#t9-pii-incident-notification-to-customer) | Template for notifying customers of PII-related security incidents | +| [T10: ISO 27018 Gap Analysis Template](#t10-iso-27018-gap-analysis-template) | Self-assessment gap analysis table | + +--- + +## Important Notice on Template Use + +These templates are frameworks based on ISO/IEC 27018 and common industry practice. They are provided for informational and guidance purposes only. They should be reviewed and adapted by qualified legal and compliance professionals before formal use, as applicable laws vary by jurisdiction. + +--- + +## T1: PII Protection Policy + +``` +[ORGANISATION NAME] +PII Protection Policy — Public Cloud Services + +Document Control +Version: [VERSION] +Author: [AUTHOR NAME / ROLE] +Approved by: [SENIOR EXECUTIVE / DATA PROTECTION OFFICER] +Date approved: [DATE] +Next review: [DATE — typically 12 months from approval] +Classification: Internal + +1. Purpose +This policy establishes [ORGANISATION NAME]'s obligations and controls as a +public cloud PII processor, in accordance with ISO/IEC 27018. It governs how +[ORGANISATION NAME] handles personally identifiable information (PII) entrusted +to it by cloud service customers. + +The policy supplements [ORGANISATION NAME]'s Information Security Policy and +applies in addition to any applicable data protection legislation. + +2. Scope +This policy applies to: +- All employees, contractors, and third parties who access or process customer PII + in the course of delivering [ORGANISATION NAME]'s cloud services +- All systems, infrastructure, and services that store, process, or transmit + customer PII +- All sub-processors engaged by [ORGANISATION NAME] to process customer PII + +3. Roles and Responsibilities + +Role | Responsibility +-------------------------------|------------------------------------------ +Data Protection Contact / DPO | Policy owner; regulatory liaison; customer queries +CISO / Security Lead | Technical control oversight; incident response +Engineering / Operations | Implementation of technical controls +Procurement | Sub-processor due diligence and contracts +All Staff with PII Access | Compliance with this policy + +4. Core Obligations + +4.1 Purpose Limitation +[ORGANISATION NAME] processes customer PII solely for the purposes specified in +the applicable service agreement and customer instructions. [ORGANISATION NAME] +shall not process customer PII for its own commercial, marketing, advertising, +or analytical purposes without the express, separate written consent of the +cloud service customer. + +4.2 No Unauthorised Disclosure +[ORGANISATION NAME] shall not disclose customer PII to any third party, except: +(a) As instructed in writing by the cloud service customer +(b) As required by binding law or regulation, in which case [ORGANISATION NAME] + will notify the customer unless legally prohibited from doing so +(c) To sub-processors, subject to paragraph 4.4 + +4.3 Government and Law Enforcement Requests +Where [ORGANISATION NAME] is legally required to disclose customer PII to a +government authority, law enforcement agency, or court, it shall: +(a) Notify the affected customer promptly, unless legally prohibited +(b) Disclose only the minimum PII necessary to satisfy the legal obligation +(c) Log the disclosure in the Disclosure Register +(d) Challenge any request that is overbroad or lacks proper legal authority + +4.4 Sub-processors +[ORGANISATION NAME] shall only engage sub-processors that have been approved +through its sub-processor management process and that are contractually bound +to equivalent PII protection obligations. [ORGANISATION NAME] shall maintain a +current Sub-processor Register, notify customers of any changes to sub-processors +with [ADVANCE NOTICE PERIOD, e.g. 30 days'] notice, and remain liable for +sub-processor compliance. + +4.5 PII Return and Disposal +Upon termination of a service agreement, [ORGANISATION NAME] shall, within +[AGREED PERIOD — e.g. 30 days] of the termination date, either return all +customer PII to the customer or securely delete it, including all copies held by +sub-processors, unless retention is required by applicable law. Written +confirmation of return/deletion shall be provided to the customer. + +4.6 Employee Obligations +All employees and contractors with access to customer PII must: +(a) Complete mandatory PII awareness training before access is provisioned +(b) Access customer PII only to the extent necessary for their role +(c) Comply with [ORGANISATION NAME]'s confidentiality obligations +(d) Report any suspected PII security incident immediately to + [INCIDENT REPORTING CONTACT] + +5. Data Residency +[ORGANISATION NAME] processes customer PII only in the following regions: +[LIST REGIONS / COUNTRIES] + +Any change to processing regions will be notified to affected customers with +[ADVANCE NOTICE PERIOD] days' prior notice. + +6. Compliance and Audit +[ORGANISATION NAME] will conduct an annual internal review of its compliance +with this policy and will provide cloud service customers with evidence of +compliance on request, in the form of: +- Current third-party security certifications +- Independent audit reports (under appropriate confidentiality terms) +- Completion of security questionnaires + +7. Review Cycle +This policy shall be reviewed at least annually and following any significant +change to [ORGANISATION NAME]'s PII processing activities, applicable legal +requirements, or findings from audits or incidents. +``` + +--- + +## T2: Data Processing Agreement Addendum + +``` +DATA PROCESSING ADDENDUM — ISO/IEC 27018 + +This Data Processing Addendum ("Addendum") supplements the [MASTER SERVICE +AGREEMENT / TERMS OF SERVICE] between [CLOUD SERVICE PROVIDER] ("CSP") and +[CUSTOMER NAME] ("Customer"), effective [DATE]. + +1. Definitions +"PII" means personally identifiable information as defined in ISO/IEC 27018, +including personal data or personal information as defined in applicable +data protection law. + +"Customer PII" means PII that Customer uploads, submits, or causes to be +processed through the Service. + +"Processing" means any operation on PII as described in ISO/IEC 27018. + +"Sub-processor" means a third party engaged by CSP to process Customer PII. + +2. CSP's Role +CSP is a PII processor in respect of Customer PII. CSP processes Customer PII +solely on Customer's instructions, as set out in this Addendum and the Service +Agreement. + +3. Restrictions on CSP's Use of Customer PII +3.1 CSP shall not process Customer PII for its own commercial, marketing, + advertising, or analytical purposes. + +3.2 CSP shall not disclose Customer PII to third parties except: + (a) As instructed in writing by Customer; + (b) As required by binding law, in which case CSP will comply with + Section 7 of this Addendum; + (c) To Sub-processors in accordance with Section 5. + +4. Security Measures +CSP shall implement and maintain technical and organisational security measures +appropriate to the risks presented by the processing, including as a minimum: +(a) Encryption of Customer PII at rest and in transit +(b) Access controls limiting employee access to Customer PII to the minimum + necessary +(c) Multi-factor authentication for all privileged access to systems containing + Customer PII +(d) Audit logging of access to Customer PII +(e) Documented incident response procedures including breach notification + +5. Sub-processors +5.1 CSP shall not engage Sub-processors for the processing of Customer PII + without Customer's prior knowledge. + +5.2 CSP shall notify Customer of any proposed addition or replacement of a + Sub-processor with [30] days' prior notice. + +5.3 Customer may object to a new Sub-processor on reasonable data protection + grounds within [15] days of notification. + +5.4 CSP shall contract with each Sub-processor on terms that impose equivalent + PII protection obligations to those in this Addendum. + +5.5 CSP shall remain liable to Customer for Sub-processor compliance with + this Addendum. + +5.6 The current Sub-processor list is maintained at [URL / schedule attached]. + +6. PII Principals' Rights +CSP shall provide Customer, upon written request and within a reasonable +timeframe, with technical assistance to enable Customer to respond to requests +from PII principals (data subjects) exercising their rights, including access, +rectification, erasure, restriction, portability, and objection. + +7. Government and Law Enforcement Requests +7.1 If CSP receives a legally binding request from a government authority or + law enforcement agency to disclose Customer PII, CSP shall: + (a) Promptly notify Customer of the request, unless legally prohibited; + (b) Disclose only the minimum PII required by the request; + (c) Challenge any request that is overbroad or lacks proper authority. + +7.2 CSP shall maintain a record of all legally required PII disclosures and + shall provide Customer with a summary of such disclosures on request + (subject to any applicable legal restrictions). + +8. Data Residency +CSP processes Customer PII only in the following regions: [LIST REGIONS]. +Any change will be notified to Customer with [30] days' prior notice. + +9. PII Return and Deletion +9.1 Upon termination of the Service Agreement, CSP shall, within [30] days, + either return all Customer PII to Customer or securely delete it, unless + legally required to retain it. + +9.2 CSP shall provide written confirmation of return or deletion upon request. + +10. Audit Rights +10.1 CSP shall make available to Customer the information necessary to + demonstrate compliance with this Addendum, including: + (a) Third-party security certifications (ISO 27001, SOC 2) + (b) Independent security audit reports (under NDA) + (c) Responses to security questionnaires + +10.2 Customer may, with [30] days' prior written notice, conduct or commission + an audit of CSP's compliance with this Addendum, subject to CSP's + reasonable security requirements and a suitable confidentiality arrangement. + +11. Incident Notification +CSP shall notify Customer without undue delay (and within [72 hours]) upon +becoming aware of a security incident that results or may result in accidental +or unlawful destruction, loss, alteration, unauthorised disclosure of, or +access to, Customer PII. Such notification shall include the information +required by applicable law and, where known: the nature of the incident, +the affected PII categories and approximate volume, and the measures taken +or proposed. + +12. Governing Data Protection Law +This Addendum is governed by [APPLICABLE LAW / JURISDICTION]. +``` + +--- + +## T3: Sub-processor Agreement Schedule + +``` +SUB-PROCESSOR DATA PROCESSING SCHEDULE + +This Schedule is incorporated into and forms part of the [MASTER AGREEMENT] +between [CSP] ("Controller-Processor") and [SUB-PROCESSOR NAME] ("Sub-processor"), +effective [DATE]. + +1. Scope of Processing +Sub-processor may process PII only for the following purposes: [DESCRIBE PURPOSE] +Processing of PII for any other purpose is expressly prohibited without prior +written consent from Controller-Processor. + +2. Restrictions +2.1 Sub-processor shall not use PII for its own commercial, marketing, or + analytical purposes. + +2.2 Sub-processor shall not engage further sub-processors without prior + written approval from Controller-Processor. + +3. Security Requirements +Sub-processor shall implement security measures at least equivalent to those +required of Controller-Processor under its customer data processing agreements, +including: +(a) Encryption at rest and in transit +(b) Access controls and least-privilege +(c) Audit logging of access to PII +(d) Multi-factor authentication for privileged access + +4. Incident Notification +Sub-processor shall notify Controller-Processor within 24 hours of becoming +aware of any actual or suspected breach of security involving PII. + +5. Data Residency +Sub-processor shall process PII only in the following regions: [LIST REGIONS]. + +6. Return and Deletion +Upon termination, Sub-processor shall return or delete all PII within [15] +days and provide written confirmation. + +7. Audit Rights +Controller-Processor shall have the right to audit Sub-processor's PII +handling on [30] days' notice, or to receive third-party audit reports. + +8. Survival +Obligations under this Schedule survive termination of the Master Agreement. +``` + +--- + +## T4: Government Request Handling Procedure + +``` +[ORGANISATION NAME] +Government and Law Enforcement PII Request Handling Procedure + +Version: [VERSION] +Author: [AUTHOR] +Approved by: [DPO / GENERAL COUNSEL] +Date: [DATE] +Next review: [DATE] + +1. Purpose +This procedure governs how [ORGANISATION NAME] responds to legally binding +requests from government authorities, law enforcement agencies, courts, and +regulators to disclose customer PII. + +2. Scope +Applies to: Legal, Privacy, Security, and Customer Success teams. + +3. Step-by-Step Procedure + +Step 1 — Receipt and Logging +- Log receipt in the Government Request Register immediately +- Record: date received, requesting authority, nature of request, data + categories requested, stated legal authority, deadline + +Step 2 — Legal Review +- Route to General Counsel / Legal immediately +- Assess: Is the request legally valid? Is it from a competent authority? + Is the stated legal basis correct? Is the scope proportionate? + +Step 3 — Notify Customer +- Unless legally prohibited, notify the affected customer within 24–48 hours +- Notification: name of requesting authority, nature of request, + categories of data requested (not the data itself) +- If a legal prohibition prevents notification, document the prohibition + in the Government Request Register + +Step 4 — Challenge if Appropriate +- If the request is overbroad, lacks proper authority, or conflicts with + applicable law, [ORGANISATION NAME] will challenge the request +- Legal to advise on challenge procedure per applicable jurisdiction + +Step 5 — Disclosure (if required) +- Disclose only the minimum PII required to satisfy the legal obligation +- Obtain confirmation of the legal basis in writing from requesting authority +- Record the disclosure in the Government Request Register and Disclosure Register + +Step 6 — Post-Disclosure +- Provide customer record of the disclosure when legally permitted +- Include disclosure in next Transparency Report (aggregate form) + +4. Transparency Reporting +[ORGANISATION NAME] publishes an annual Transparency Report summarising: +- Total number of government/law enforcement requests received +- Jurisdictions of requesting authorities +- Number fulfilled in full, in part, or rejected +- Number of notifications prohibited by law +``` + +--- + +## T5: PII Return and Disposal Confirmation Letter + +``` +[ORGANISATION NAME LETTERHEAD] + +Date: [DATE] +To: [CUSTOMER CONTACT NAME] +Organisation: [CUSTOMER NAME] +Re: Confirmation of PII Return/Deletion — [SERVICE NAME] +Contract: [CONTRACT REFERENCE] + +Dear [CONTACT NAME], + +Following the termination of the above-referenced service agreement on +[TERMINATION DATE], we write to confirm that all Customer PII processed +by [ORGANISATION NAME] under that agreement has been handled as follows: + +[SELECT APPLICABLE:] + +[ ] Returned to Customer: All Customer PII was exported and transferred to + [METHOD/DESTINATION] on [DATE]. Copies have been deleted from our systems. + +[ ] Deleted/Destroyed: All Customer PII has been securely deleted from + [ORGANISATION NAME]'s systems and from all sub-processors' systems, as of + [COMPLETION DATE]. + +The above includes all primary data, backups, caches, replicas, and any copies +held by sub-processors. + +[IF ANY RETENTION REQUIRED:] +The following data has been retained solely as required by [LAW/REGULATION]: +[DESCRIBE CATEGORY AND RETENTION PERIOD] + +This confirmation is provided in accordance with [ORGANISATION NAME]'s +obligations under our Data Processing Addendum and ISO/IEC 27018. + +Please retain this letter as part of your compliance records. + +Yours sincerely, + +[SIGNATORY NAME] +[TITLE] +[DATE] +[CONTACT EMAIL] +``` + +--- + +## T6: Sub-processor Register + +| Field | Description / Example | +|-------|----------------------| +| Sub-processor Name | Cloud Storage Corp Ltd | +| Registered Country | United States | +| Processing Location(s) | US East, EU West | +| Purpose | Object storage for customer data | +| PII Categories Processed | Documents, user data, email addresses | +| Transfer Mechanism (if outside EEA) | Standard Contractual Clauses (SCCs) | +| Certification | ISO 27001, SOC 2 Type II | +| CSP Contract Reference | SUBP-2024-00123 | +| Date Customers Notified | 2024-03-01 | +| Last Due Diligence Review | 2025-01-15 | +| Next Review Due | 2026-01-15 | + +*Maintained by: [Procurement / Privacy Team]* +*Updated: [DATE]* +*Approved by: [DPO / Privacy Lead]* + +--- + +## T7: Disclosure Register + +| Field | Description / Example | +|-------|----------------------| +| Reference ID | DISC-2025-001 | +| Date of Request | 2025-02-14 | +| Date of Disclosure | 2025-02-18 | +| Requesting Authority | [e.g. Jurisdiction Court / Authority] | +| Requesting Jurisdiction | [Country] | +| Legal Basis Cited | [Court order / statutory authority] | +| PII Categories Disclosed | [e.g. Name, email, account records] | +| Approximate Volume | [Number of records / individuals] | +| Customer Notified? | Yes / No | +| If No — Reason | [Legal prohibition / order prohibiting notification] | +| Challenge Made? | Yes / No | +| Challenge Outcome | [Withdrawn / Modified / Upheld] | +| Record Owner | [Name] | + +*Classified: Restricted — Legal Privilege may apply* +*Maintained by: Legal / Privacy Team* + +--- + +## T8: Staff PII Awareness Training Acknowledgment + +``` +[ORGANISATION NAME] +PII Awareness Training — Completion and Acknowledgment + +Employee/Contractor Name: ____________________________ +Role/Department: ____________________________ +Training Completed: ____________________________ (Date) +Training Delivered By: ____________________________ + +I confirm that I have completed the PII Awareness Training for [ORGANISATION NAME] +and that I understand and agree to the following: + +1. I understand what constitutes personally identifiable information (PII) in + the context of [ORGANISATION NAME]'s cloud services. + +2. I understand that [ORGANISATION NAME] acts as a PII processor for its cloud + service customers and that I must only process customer PII as required by + my role and in line with company policy. + +3. I understand that I must not use customer PII for any purpose other than + delivering the contracted service, including not using it for personal + purposes, marketing, or any purpose not authorised by [ORGANISATION NAME]. + +4. I understand my confidentiality obligations regarding customer PII and that + these obligations continue after I leave [ORGANISATION NAME]'s employment. + +5. I know how to recognise and report a PII-related security incident and will + report such incidents immediately to [REPORTING CONTACT/CHANNEL]. + +6. I understand the consequences of breaching these obligations, including + disciplinary action up to and including dismissal, and potential civil or + criminal liability. + +Signature: _________________________ Date: ___________ + +Retained by: HR / Privacy Team +``` + +--- + +## T9: PII Incident Notification to Customer + +``` +[ORGANISATION NAME LETTERHEAD] + +CONFIDENTIAL — SECURITY INCIDENT NOTIFICATION + +Date: [DATE] +To: [CUSTOMER CONTACT NAME / SECURITY/DPO CONTACT] +Organisation: [CUSTOMER NAME] +Re: Security Incident Notification — [INCIDENT REFERENCE] + +Dear [CONTACT NAME], + +We are writing to notify you of a security incident that may involve +personally identifiable information (PII) processed by [ORGANISATION NAME] +under our service agreement. + +1. Nature of the Incident +[DESCRIBE THE INCIDENT — e.g. "On [DATE], we detected unauthorised access +to [SYSTEM/SERVICE]."] + +2. Discovery and Response Timeline +- [DATE/TIME]: Incident detected +- [DATE/TIME]: Initial containment measures implemented +- [DATE/TIME]: Customer notification initiated + +3. PII Potentially Affected +Categories of PII: [e.g. Names, email addresses, usage logs] +Approximate number of +individuals affected: [NUMBER / RANGE / UNKNOWN AT THIS TIME] +Affected customer tenant: [YOUR ACCOUNT / ALL CUSTOMERS] + +4. Likely Consequences +[DESCRIBE KNOWN OR LIKELY CONSEQUENCES — e.g. "There is a risk that the +affected data could be accessible to the unauthorised party. We have no +current evidence of onward disclosure."] + +5. Measures Taken and Proposed +Immediate actions: [DESCRIBE] +Ongoing investigation: [DESCRIBE] +Planned remediation: [DESCRIBE] + +6. Your Actions +[DESCRIBE WHAT THE CUSTOMER SHOULD DO — e.g. "We recommend you assess +whether your obligations under [GDPR / applicable law] to notify your +supervisory authority or affected individuals apply. We are available to +provide further information to support your assessment."] + +7. Contact +For further information, please contact: +Name: [DPO / SECURITY CONTACT NAME] +Email: [EMAIL] +Phone: [PHONE] + +We take this incident very seriously and are committed to keeping you informed +as our investigation progresses. A full incident report will be provided within +[30] days. + +Yours sincerely, + +[SIGNATORY / CISO / DPO] +[DATE] +``` + +--- + +## T10: ISO 27018 Gap Analysis Template + +Use this template to assess compliance across ISO 27018's Annex A obligations and key extended controls. + +**Assessment Metadata:** +- Organisation / CSP: [NAME] +- Service(s) in scope: [NAME] +- Assessor: [NAME / ROLE] +- Assessment date: [DATE] +- ISO 27018 version assessed: [ ] 2025 (3rd edition) [ ] 2019 (2nd edition) + +**Status definitions:** +- **Implemented** — Control is in place, documented, and evidenced +- **Partial** — Control exists but has gaps (undocumented, inconsistently applied, missing evidence) +- **Not Implemented** — No control exists or control is clearly insufficient +- **N/A** — Not applicable; justification documented + +--- + +**Gap Analysis Table:** + +| Control Area | Obligation / Topic | Status | Evidence Available | Gaps / Notes | Priority | +|---|---|---|---|---|---| +| **Consent & Purpose** | No processing beyond customer instructions | | | | | +| **Consent & Purpose** | DPA contract terms defining purpose | | | | | +| **Purpose Limitation** | No commercial/marketing use of customer PII | | | | | +| **Purpose Limitation** | Sub-processor purpose restriction in contracts | | | | | +| **Change Notification** | Advance notice of changes to processing | | | | | +| **Sub-processor Info** | Sub-processor info provided to customers | | | | | +| **Temporary Files** | Temp file identification and deletion | | | | | +| **Access Minimization** | Least-privilege access to PII systems | | | | | +| **Access Minimization** | Privileged access requires MFA | | | | | +| **Access Minimization** | Periodic access reviews documented | | | | | +| **PII Return/Deletion** | End-of-contract return/deletion procedure | | | | | +| **PII Return/Deletion** | Written confirmation issued to customers | | | | | +| **Disclosure Notification** | Government request notification procedure | | | | | +| **Disclosure Notification** | Customer notification sent (unless prohibited) | | | | | +| **Disclosure Register** | Disclosure register maintained | | | | | +| **Sub-processor Disclosure** | Sub-processor register maintained and accessible | | | | | +| **Sub-processor Disclosure** | Advance notice of new sub-processors | | | | | +| **Sub-processor Disclosure** | Sub-processor contracts with PII obligations | | | | | +| **Data Residency** | Processing regions disclosed to customers | | | | | +| **Data Residency** | Advance notice of residency changes | | | | | +| **Employee Access** | Employee access to PII logged | | | | | +| **Employee Access** | Employee PII access controls and justification | | | | | +| **Data Subject Rights** | Technical tools available for DSR fulfilment | | | | | +| **Privacy Contact** | Dedicated PII/privacy contact designated | | | | | +| **Privacy Contact** | Contact details accessible to customers | | | | | +| **Breach Notification** | PII incident notification procedure (72 hours) | | | | | +| **Breach Notification** | Incident notification log maintained | | | | | +| **Security Policy** | PII-specific information security policy | | | | | +| **Compliance Evidence** | Certifications/audit reports available to customers | | | | | +| **Supervisory Authority** | Applicable authorities disclosed to customers | | | | | +| **Audit Rights** | Customer audit rights clause in DPA | | | | | +| **Staff Training** | PII awareness training delivered and recorded | | | | | +| **Confidentiality** | Staff confidentiality obligations documented | | | | | +| **Transparency Report** | Transparency report published (where permitted) | | | | | + +--- + +**Summary:** +- Total controls assessed: [NUMBER] +- Implemented: [NUMBER] +- Partial: [NUMBER] +- Not Implemented: [NUMBER] +- N/A: [NUMBER] + +**Priority Actions:** +1. [Critical gaps] +2. [High priority actions] +3. [Medium priority actions] diff --git a/plugins/iso27701/.claude-plugin/plugin.json b/plugins/iso27701/.claude-plugin/plugin.json new file mode 100644 index 0000000..62772ce --- /dev/null +++ b/plugins/iso27701/.claude-plugin/plugin.json @@ -0,0 +1,22 @@ +{ + "name": "iso27701", + "description": "ISO/IEC 27701:2019 Privacy Information Management System (PIMS) advisor — gap analysis, PII Controller and PII Processor control guidance, privacy impact assessments, GDPR mapping, records of processing activities, PII principal rights workflows, and certification readiness as an extension to ISO 27001.", + "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": [ + "iso27701", + "pims", + "privacy", + "pii", + "gdpr", + "data-protection", + "privacy-information-management", + "grc" + ] +} diff --git a/plugins/iso27701/skills/iso27701/SKILL.md b/plugins/iso27701/skills/iso27701/SKILL.md new file mode 100644 index 0000000..1a70f2c --- /dev/null +++ b/plugins/iso27701/skills/iso27701/SKILL.md @@ -0,0 +1,460 @@ +--- +name: iso27701 +description: > + Expert ISO/IEC 27701:2019 Privacy Information Management System (PIMS) compliance advisor. + Use this skill whenever a user asks about ISO 27701, Privacy Information Management, PIMS + implementation or certification, PII Controller controls, PII Processor controls, privacy risk + assessment, privacy impact assessment (PIA), records of processing activities, PII principal + rights, privacy by design, privacy by default, consent management, lawful basis for processing, + cross-border PII transfers, or any topic related to building or auditing a PIMS. Also trigger + for questions like "how does ISO 27701 extend ISO 27001?", "what controls apply to PII + Processors?", "how do I map ISO 27701 to GDPR?", "what is a Privacy Information Management + System?", "how do I achieve ISO 27701 certification?", "what is the difference between a PII + Controller and PII Processor under 27701?", or any request involving privacy governance layered + on an existing ISMS. Use alongside the iso27001 skill when the user needs both ISMS and PIMS + coverage simultaneously. +--- + +# ISO 27701 Privacy Information Management Skill + +You are an expert ISO/IEC 27701:2019 Lead Auditor and PIMS implementation consultant. You assist organisations — whether PII Controllers, PII Processors, or both — with implementing, auditing, and certifying a Privacy Information Management System (PIMS) as an extension to ISO/IEC 27001. + +--- + +## How to Respond + +Always clarify the organisation's role if not stated — **PII Controller** (determines purposes and means of processing), **PII Processor** (processes on behalf of a controller), or **both** — as this determines which clauses and controls apply. + +Also clarify whether the organisation holds an existing ISO 27001 certification, is pursuing joint certification, or is implementing ISO 27701 as a standalone PIMS programme. + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| Gap analysis | Table: Clause/Control ID \| Requirement \| Status (Implemented/Partial/Not Implemented/N/A) \| Evidence Needed \| Gap Notes | +| PIMS scope definition | Structured narrative: PII types, PII principals, processing purposes, jurisdictions, legal bases | +| Privacy impact assessment | PIA structured report with risk ratings | +| Policy generation | Full structured policy with document control block | +| Control implementation guidance | Purpose → Requirements → Implementation Steps → Evidence → Audit Tips | +| Records of processing activities | RoPA table with all required fields | +| PII principal rights implementation | Per-right procedure with timelines | +| GDPR mapping | Table: ISO 27701 clause/control → GDPR article → compliance notes | +| 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., 5.2.1, 7.2.2, 8.4.1) in all outputs. + +--- + +## Standard Overview + +**ISO/IEC 27701:2019** was published on **6 August 2019** — the first international standard providing requirements and guidance for a Privacy Information Management System (PIMS). It extends **ISO/IEC 27001:2013** (requirements) and **ISO/IEC 27002:2013** (controls guidance) to include privacy management. + +### Key Design Principles +- ISO 27701 is an **extension** standard: it cannot be implemented or certified independently without ISO 27001 as a foundation. An organisation certified to ISO 27001 can obtain a combined ISO 27001 / ISO 27701 certificate. +- It applies the same **High Level Structure (HLS / Annex SL)** framework as ISO 27001, enabling integrated management system alignment. +- It addresses both **PII Controllers** (equivalent to GDPR Data Controllers) and **PII Processors** (equivalent to GDPR Data Processors) with separate control sets. +- Informative annexes map ISO 27701 to **GDPR**, **ISO/IEC 29151** (PII Controller guidance), **ISO/IEC 27018** (PII Processor guidance), and **ISO/IEC 29100** (privacy framework). + +### Applicability +- Any organisation that processes PII, regardless of size or sector +- Cloud service providers acting as PII Processors +- Organisations seeking to demonstrate GDPR or other privacy regulation compliance through a structured, auditable framework +- Organisations that have ISO 27001 and wish to extend it to privacy + +### Relationship to Other Standards + +| Standard | Relationship | +|----------|-------------| +| ISO/IEC 27001:2013 | Foundation — PIMS requirements extend every clause of ISO 27001 | +| ISO/IEC 27002:2013 | Foundation — clause 6 of ISO 27701 provides privacy-specific implementation guidance for each relevant ISO 27002 control | +| ISO/IEC 29100:2011 | Privacy framework — defines PII, privacy principles, and roles referenced throughout ISO 27701 | +| ISO/IEC 29151:2017 | Code of practice for PII Controllers — Annex D maps ISO 27701 PII Controller controls to ISO 29151 | +| ISO/IEC 27018:2019 | Code of practice for PII Processors in public cloud — Annex E maps ISO 27701 PII Processor controls to ISO 27018 | +| GDPR | EU/UK data protection regulation — Annex C maps ISO 27701 to GDPR articles | + +> **Note on ISO 27001:2022 compatibility:** ISO 27701:2019 normatively references ISO 27001:2013 and ISO 27002:2013. Organisations implementing ISO 27001:2022 can still use ISO 27701, but should acknowledge the control mapping differences. ISO/IEC is expected to publish an updated version of ISO 27701 aligned to the 2022 editions; as of 2024 the 2019 version remains current. When assisting users on ISO 27001:2022 + ISO 27701, note that the PIMS extensions still apply in principle and cross-reference accordingly. + +--- + +## Core Terminology + +| ISO 27701 Term | Definition | GDPR Equivalent | +|----------------|-----------|-----------------| +| PII (Personally Identifiable Information) | Any information that can be used to identify a PII principal, directly or indirectly | Personal data (Art. 4(1)) | +| PII Principal | Natural person to whom the PII relates | Data subject (Art. 4(1)) | +| PII Controller | Organisation that determines purposes and means of PII processing | Data controller (Art. 4(7)) | +| PII Processor | Organisation that processes PII on behalf of a PII controller | Data processor (Art. 4(8)) | +| PIMS | Privacy Information Management System — management system for privacy, as an extension to the ISMS | — | +| Privacy impact assessment (PIA) | Process to identify and assess privacy risks | DPIA — Data Protection Impact Assessment (Art. 35) | +| Consent | Freely given, specific, informed, unambiguous indication of a PII principal's agreement to processing | Consent (Art. 6(1)(a), Art. 7) | +| Privacy notice | Communication to a PII principal about how their PII is processed | Privacy notice / fair processing notice (Art. 13–14) | +| Processing | Any operation on PII (collection, recording, storage, use, disclosure, erasure, etc.) | Processing (Art. 4(2)) | +| Lawful basis | Legal justification permitting PII processing | Legal ground for processing (Art. 6) | +| Sub-processor | A processor engaged by a PII processor to process PII on the controller's behalf | Sub-processor (Art. 28(2)) | + +--- + +## Document Structure — ISO 27701:2019 + +### Clause 5: PIMS-Specific Requirements (Extensions to ISO 27001 Clauses) + +Clause 5 does not replace ISO 27001 clauses — it **adds** PIMS-specific obligations on top of each clause. Both the ISO 27001 requirement and the ISO 27701 extension must be met. + +| ISO 27701 Sub-clause | Extends ISO 27001 | PIMS Extension Summary | +|----------------------|-------------------|------------------------| +| 5.2.1 | 4.1 | When understanding the organisation's context, include identification of applicable privacy laws, regulations, and contractual obligations related to PII processing | +| 5.2.2 | 4.2 | Interested parties must include PII principals, supervisory/regulatory authorities, PII processors used, and joint controllers | +| 5.2.3 | 4.3 | PIMS scope must include the types of PII processed, the roles of PII controller and/or processor, the PII principals, and the processing purposes | +| 5.2.4 | 4.4 | The PIMS must be established, implemented, maintained, and continually improved as an integrated extension of the ISMS | +| 5.3.1 | 5.1 | Top management must demonstrate commitment to privacy; establish and communicate the privacy policy; ensure PIMS objectives are set and resourced | +| 5.3.2 | 5.2 | A top-level privacy policy must be established, communicated to interested parties, and available to PII principals as appropriate | +| 5.3.3 | 5.3 | Assign privacy-specific roles and responsibilities; consider appointing a DPO-equivalent where required by law; define accountability for PII controller/processor obligations | +| 5.4.1 | 6.1 | Privacy risk assessment must consider PII-specific threats, vulnerabilities, and impacts; PIA triggers must be documented | +| 5.4.2 | 6.2 | Privacy objectives must be measurable, aligned with the privacy policy, communicated, and monitored | +| 5.5 | 7 | Competence, awareness, and communication must include privacy-specific content; staff processing PII must receive role-appropriate privacy training | +| 5.6.1 | 8.1 | Operational planning must include PII inventories, PIA procedures, lawful basis documentation, and response procedures for PII principal rights | +| 5.6.2 | 8.2 | Privacy risk assessments must be performed and documented at planned intervals and when significant changes occur | +| 5.6.3 | 8.3 | Privacy risk treatment plans must address identified privacy risks; risk treatment decisions must reference applicable PII Controller or PII Processor controls | +| 5.7 | 9 | Performance monitoring must include privacy-specific metrics, PII breach tracking, complaint resolution rates, and PII principal rights fulfilment | +| 5.8 | 10 | Nonconformities and corrective actions must include privacy-related incidents and breaches; continual improvement applies to the PIMS as well as the ISMS | + +### Clause 6: PIMS-Specific Guidance Related to ISO/IEC 27002 + +Clause 6 is **informative** guidance. It provides privacy context for a selection of ISO 27002:2013 controls, explaining how each control contributes to meeting PIMS requirements. It applies to both PII Controllers and PII Processors unless otherwise noted. Load `references/pims-overview.md` for detail on which ISO 27002 controls have PIMS guidance and what that guidance requires. + +### Clause 7: Additional ISO/IEC 27002 Guidance for PII Controllers + +Clause 7 is **normative** for organisations acting as PII Controllers. It contains extended control requirements beyond the ISO 27002 base controls. + +See `references/controller-controls.md` for the complete control set. + +**Summary of Clause 7 structure:** +- **7.2** — Conditions for collection and processing (9 controls: 7.2.1–7.2.9) +- **7.3** — Obligations to PII principals (8 controls: 7.3.1–7.3.8) +- **7.4** — Privacy by design and privacy by default (7 controls: 7.4.1–7.4.7) +- **7.5** — PII sharing, transfer and disclosure (3 controls: 7.5.1–7.5.3) + +### Clause 8: Additional ISO/IEC 27002 Guidance for PII Processors + +Clause 8 is **normative** for organisations acting as PII Processors. It contains extended control requirements for processor-specific obligations. + +See `references/processor-controls.md` for the complete control set. + +**Summary of Clause 8 structure:** +- **8.2** — Conditions for collection and processing (5 controls: 8.2.1–8.2.5) +- **8.3** — Obligations to PII principals (2 controls: 8.3.1–8.3.2) +- **8.4** — Privacy by design and privacy by default (2 controls: 8.4.1–8.4.2) +- **8.5** — PII sharing, transfer and disclosure (6 controls: 8.5.1–8.5.6) + +### Informative Annexes + +| Annex | Content | +|-------|---------| +| Annex A | PIMS-specific reference control objectives and controls — PII Controllers only (maps to ISO 27002:2013 structure) | +| Annex B | PIMS-specific reference control objectives and controls — PII Processors only | +| Annex C | Mapping of ISO 27701 clauses and controls to GDPR articles | +| Annex D | Mapping of ISO 27701 PII Controller controls to ISO/IEC 29151 | +| Annex E | Mapping of ISO 27701 PII Processor controls to ISO/IEC 27018 | +| Annex F | ISO/IEC 29100 privacy framework alignment reference | + +--- + +## Core Workflows + +### 1. Gap Analysis + +When asked to perform or help with a gap analysis: + +1. Confirm: Is the organisation a PII Controller, PII Processor, or both? +2. Confirm: Does the organisation already hold ISO 27001 certification? What version? +3. Produce two tables — one for Clause 5 (PIMS requirement extensions) and one for the applicable control clauses (7 for controller, 8 for processor, or both): + +**Clause 5 Gap Analysis Table:** +| Sub-clause | ISO 27001 Clause Extended | PIMS Requirement | Status | Evidence Needed | Gap | +|------------|--------------------------|------------------|--------|----------------|-----| + +**Control Gap Analysis Table:** +| Control ID | Control Name | Status | Evidence Needed | Gap Notes | +|------------|-------------|--------|----------------|-----------| + +**Status definitions:** +- Implemented — control/requirement fully in place with evidence +- Partial — some evidence exists but gaps remain +- Not Implemented — no evidence of implementation +- N/A — documented exclusion with justification (note: most controls cannot be excluded for active PII processing) + +4. Summarise critical gaps and recommend a prioritised remediation roadmap +5. Offer to generate a PIMS Statement of Applicability (PIMS-SoA) + +### 2. PIMS Statement of Applicability (PIMS-SoA) + +The PIMS-SoA supplements (or is integrated into) the ISO 27001 Statement of Applicability. It records: + +| Control ID | Control Name | Applicable (Y/N) | Justification | Implementation Status | Evidence Reference | +|------------|-------------|-----------------|---------------|-----------------------|-------------------| + +For all Clause 7 controls, the organisation must document applicability determination. Controls relating to active processing activities cannot be excluded. Where a control is not applicable, the justification must relate to the processing in scope (e.g., "7.2.7 Joint PII controllers: N/A — no joint controller arrangements in scope"). + +### 3. Privacy Impact Assessment (PIA) + +When asked to assist with a PIA (also referred to as a DPIA in GDPR contexts): + +**PIA structure (per 27701 guidance):** + +``` +## Privacy Impact Assessment + +**System/Process Name:** [Name] +**Date:** [Date] +**Assessor:** [Name/Role] +**Review Date:** [Date] + +### 1. Description of Processing +- Purpose of processing: +- Categories of PII: +- Volumes of PII principals affected: +- Retention period: +- Recipients / recipients categories: +- Third country transfers (if any): + +### 2. Necessity and Proportionality Assessment +- Lawful basis relied upon: [Consent / Contract / Legal obligation / Vital interests / Public task / Legitimate interests] +- Is processing limited to the stated purpose? [Yes/No — details] +- Is data minimisation applied? [Yes/No — details] + +### 3. Privacy Risk Assessment +| Risk | Likelihood (1-5) | Severity (1-5) | Risk Score | Treatment | +|------|-----------------|----------------|------------|-----------| +| Unauthorised access to PII | | | | | +| Inaccurate PII leading to adverse decisions | | | | | +| Excessive PII collection | | | | | +| Unlawful cross-border transfer | | | | | +| Inability to execute PII principal rights | | | | | +| PII retention beyond stated period | | | | | +| Third-party / sub-processor breach | | | | | + +### 4. Privacy Measures +[List technical and organisational measures applied to treat identified risks] + +### 5. PII Principal Rights +[Confirm mechanisms in place for each applicable right: access, rectification, erasure, restrict, portability, object, automated decision-making] + +### 6. Outcome and Sign-off +- Overall risk level: [Low / Medium / High / Very High] +- Residual risk accepted by: [Role] +- DPO / Privacy Officer consulted: [Yes/No] +- Supervisory authority consultation required: [Yes/No — if high residual risk] +``` + +**PIA trigger criteria (document these in PIMS procedures):** +Any of the following should trigger a PIA: +- Processing involving systematic profiling with significant effects on individuals +- Processing special categories of PII (health, biometric, racial/ethnic origin, political opinions, etc.) at scale +- Systematic monitoring of publicly accessible areas +- New technology or processing approaches involving PII +- Processing that prevents individuals from exercising rights or using services +- Cross-border transfers to new or uncovered jurisdictions + +### 4. Policy and Document Generation + +When generating privacy policies or PIMS documents, always include: +- Purpose and scope +- Policy statement +- Roles and responsibilities +- Procedures or controls +- Review cycle (minimum annual) +- References to applicable ISO 27701 clauses +- Document control block: Version | Author | Approved By | Date | Next Review + +**Common PIMS policy types and their primary control mappings:** + +| Policy Document | ISO 27701 Clause | Notes | +|----------------|-----------------|-------| +| Privacy Policy (external) | 5.3.2 | Communicated to PII principals; must meet Art. 13/14 requirements if GDPR applies | +| Privacy Policy (internal) | 5.3.1, 5.3.2 | Top management approved; sets organisational commitment | +| PII Handling Procedure | 5.6.1, 7.4.1, 7.4.2 | Covers collection, use, storage, and disposal of PII | +| Consent Management Procedure | 7.2.3, 7.2.4 | Mechanism to obtain, record and withdraw consent | +| Privacy Impact Assessment Procedure | 5.4.1, 5.6.2, 7.2.5 | Defines triggers, methodology, roles, and approval | +| PII Principal Rights Procedure | 7.3.1–7.3.7 | Covers access, rectification, erasure, objection, portability | +| Records of Processing Activities (RoPA) | 7.2.8 | Mandatory inventory of processing activities | +| Data Retention and Deletion Policy | 7.4.7 | Defines retention schedules and secure disposal | +| Cross-border Transfer Policy | 7.5.1, 7.5.2 | Lawful mechanisms for international PII transfers | +| Privacy Incident Response Plan | 5.6.1, 5.8 | Breach identification, containment, notification timelines | +| Processor / Sub-processor Contract Requirements | 7.2.6, 8.2.1 | Contractual privacy obligations for processors | +| Privacy Training Policy | 5.5 | Role-based privacy awareness and training requirements | + +### 5. Records of Processing Activities (RoPA) + +When generating a RoPA template: + +| Field | Description | ISO 27701 Reference | +|-------|------------|---------------------| +| Processing activity name | Description of what is processed and why | 7.2.1, 7.2.8 | +| Controller name and contact | Legal entity name, address, and DPO contact | 7.2.8 | +| Purposes of processing | Specific, documented purposes | 7.2.1 | +| Lawful basis | Legal justification for each purpose | 7.2.2 | +| Categories of PII principals | Employees, customers, job applicants, etc. | 7.2.8 | +| Categories of PII | Name, email, health data, financial data, etc. | 7.2.8, 7.2.9 | +| Special category PII | Health, biometric, political opinions, etc. — flag separately | 7.2.2 | +| Retention period | How long PII is held for each purpose | 7.4.7 | +| Recipients | Third parties that receive the PII | 7.5.3 | +| Third country transfers | Countries outside the jurisdiction and the safeguard used | 7.5.1, 7.5.2 | +| Security measures | Reference to technical/organisational controls applied | 5.4.1, 5.6.3 | +| Date last reviewed | Maintain accuracy of the register | 5.7 | + +### 6. PII Principal Rights Implementation + +When asked about implementing PII principal (data subject) rights: + +For each right, document a procedure covering: **Trigger → Verification → Processing → Response → Timelines → Logging** + +| Right | ISO 27701 Reference | Required Procedure Elements | +|-------|--------------------|-----------------------------| +| Right of access | 7.3.6 | Identity verification, scope of disclosure, 30-day response target, fee policy | +| Right to rectification | 7.3.7 | Accuracy check process, notification to processors and recipients | +| Right to erasure | 7.3.7 | Erasure conditions assessment, notification cascade to processors, backup policy | +| Right to withdraw consent | 7.3.4 | Mechanism provided, withdrawal process documented, downstream effect managed | +| Right to object | 7.3.5 | Basis for objection assessed, processing suspended pending review | +| Right to restrict processing | 7.3.1 | Restriction flag mechanism, notification to recipients | +| Right to data portability | 7.3.6 | Machine-readable format (JSON/CSV), direct transfer capability where applicable | +| Right not to be subject to automated decisions | 7.3.1 | Human review escalation path, profiling disclosure | + +### 7. Control Implementation Guidance + +For any Clause 7 or Clause 8 control, structure your response as: + +**Control: [ID] [Name]** +- **Purpose**: Why this control exists and what privacy outcome it achieves +- **Who it applies to**: PII Controller / PII Processor / Both +- **Requirements**: What the standard requires +- **Implementation steps**: Concrete, actionable implementation activities +- **Evidence for audit**: What an auditor will look for +- **Common pitfalls**: What teams typically miss +- **GDPR relevance** (if applicable): Relevant GDPR article(s) + +Load `references/controller-controls.md` for all Clause 7 controls. +Load `references/processor-controls.md` for all Clause 8 controls. + +--- + +## Certification Path + +### Prerequisites +1. **ISO 27001 certification (or simultaneous pursuit):** ISO 27701 cannot be certified independently; the audit is conducted as an extension to an ISO 27001 audit. +2. **PIMS scope defined:** Must document PII types, processing purposes, applicable laws, and controller/processor roles within the scope. +3. **Clause 5 extensions implemented:** All PIMS requirement extensions to ISO 27001 clauses must be in place. +4. **Applicable control set implemented:** Clause 7 (controller), Clause 8 (processor), or both, as applicable. +5. **PIMS-SoA completed:** Statement of Applicability covering all applicable controls with justification. + +### Certification Readiness Checklist + +**Foundation (Clause 5) — Required for All:** +- [ ] Privacy law and regulatory requirements identified and documented (5.2.1) +- [ ] Interested parties include PII principals, DPAs, processors, and joint controllers as applicable (5.2.2) +- [ ] PIMS scope documented: PII types, processing purposes, controller/processor role stated (5.2.3) +- [ ] Top-level privacy policy established, approved, and published (5.3.2) +- [ ] Privacy roles and responsibilities assigned; DPO appointed where legally required (5.3.3) +- [ ] Privacy risk assessment procedure documented and performed (5.4.1, 5.6.2) +- [ ] PIA procedure documented, triggers defined, at least one PIA conducted (7.2.5) +- [ ] Privacy objectives defined, measurable, and monitored (5.4.2) +- [ ] Privacy competence and awareness training programme in place (5.5) +- [ ] PII inventory / data asset register maintained (7.2.9 / 5.6.1) +- [ ] Records of processing activities (RoPA) maintained (7.2.8) +- [ ] Privacy incident response procedure documented (5.8) +- [ ] Internal PIMS audit conducted (5.7) +- [ ] Management review included PIMS topics (5.7) +- [ ] PIMS-SoA completed for all applicable controls + +**PII Controller Controls (Clause 7) — Required if acting as PII Controller:** +- [ ] All processing purposes identified and documented (7.2.1) +- [ ] Lawful basis identified for each processing purpose (7.2.2) +- [ ] Consent mechanism designed, documented, and operational where consent is the lawful basis (7.2.3, 7.2.4) +- [ ] Contracts with all PII processors in place (7.2.6) +- [ ] Joint controller arrangements documented where applicable (7.2.7) +- [ ] Mechanisms for all PII principal rights implemented and tested (7.3.1–7.3.8) +- [ ] Privacy by design embedded in new processing and systems (7.4.1–7.4.4) +- [ ] Retention schedules defined and enforced; deletion/anonymisation procedures in place (7.4.5–7.4.7) +- [ ] Cross-border transfer mechanisms documented and lawful (7.5.1–7.5.3) + +**PII Processor Controls (Clause 8) — Required if acting as PII Processor:** +- [ ] Customer (controller) agreements in place covering all processing performed (8.2.1) +- [ ] Organisation's public privacy commitments (privacy notice for processing services) published (8.2.2) +- [ ] No PII used for marketing/advertising to PII principals without controller instruction (8.2.3) +- [ ] Process for handling infringing customer instructions documented (8.2.4) +- [ ] Customer obligations communicated and tracked (8.2.5) +- [ ] Mechanism to support PII principals' rights on behalf of the controller (8.3.1, 8.3.2) +- [ ] Processing limited to controller instructions; no exceeding of scope (8.4.1) +- [ ] Data minimisation applied to processor operations (8.4.2) +- [ ] Sub-processor agreements in place; sub-processor list maintained (8.5.6) +- [ ] Cross-border transfer mechanisms documented (8.5.1–8.5.3) +- [ ] Process to notify controller of third-party PII disclosure requests (8.5.4, 8.5.5) + +--- + +## Mandatory Documentation + +When asked for a certification-readiness document checklist, produce: + +**Mandatory documented information (ISO 27701:2019):** +- [ ] PIMS scope document (5.2.3) +- [ ] Privacy policy (5.3.2) +- [ ] Privacy risk assessment results (5.6.2) +- [ ] Privacy risk treatment plan (5.6.3) +- [ ] PIMS Statement of Applicability (5.6.3 / Annex A or B) +- [ ] Privacy objectives (5.4.2) +- [ ] Evidence of privacy competence (5.5) +- [ ] PII processing inventory / data asset register (7.2.9) +- [ ] Records of processing activities (RoPA) (7.2.8) +- [ ] Lawful basis records for each processing activity (7.2.2) +- [ ] Consent records where consent is the lawful basis (7.2.4) +- [ ] PIA procedure and completed PIA(s) (7.2.5) +- [ ] PII processor contracts (7.2.6) +- [ ] Privacy notices provided to PII principals (7.3.3) +- [ ] PII principal rights procedures and fulfilment records (7.3.1–7.3.7) +- [ ] Retention schedules (7.4.7) +- [ ] Cross-border transfer records (7.5.3) +- [ ] Privacy incident log and notification records (5.8) +- [ ] Internal PIMS audit results (5.7) +- [ ] Management review records including PIMS items (5.7) +- [ ] Nonconformity and corrective action records (5.8) + +--- + +## Common Questions — Quick Reference + +**Q: Can ISO 27701 be certified independently of ISO 27001?** +No. ISO 27701 certification requires ISO 27001 as the base. Certification bodies issue a combined certificate or an extension certificate. An organisation that is not yet ISO 27001 certified must simultaneously pursue ISO 27001 certification. + +**Q: Does ISO 27701 apply to ISO 27001:2022?** +Yes, in practice. ISO 27701:2019 normatively references ISO 27001:2013, but the PIMS extensions apply in principle to any ISMS. When working with ISO 27001:2022, cross-reference the 2022 clause structure and update control mappings accordingly. An updated ISO 27701 aligned to the 2022 editions has not been published as of 2024. + +**Q: Does achieving ISO 27701 certification mean GDPR compliance?** +No. ISO 27701 is a management system standard, not a legal compliance certification. However, it provides strong evidence of implementing appropriate technical and organisational measures (GDPR Art. 25, Art. 32), and certification can be used to demonstrate accountability (Art. 5(2)). See `references/gdpr-iso29100-mapping.md` for the detailed mapping. + +**Q: What is the difference between a PIA and a DPIA?** +A PIA (Privacy Impact Assessment) is the ISO 27701 term for a structured privacy risk assessment on a specific processing activity. A DPIA (Data Protection Impact Assessment) is the GDPR term for the same concept (required under Art. 35 for high-risk processing). ISO 27701 Annex C maps PIA obligations (7.2.5) to GDPR Art. 35. + +**Q: What controls apply to a cloud provider acting as a PII Processor?** +A cloud provider acting as a PII Processor is subject to Clause 8 controls (8.2–8.5) plus the ISO 27001/27002 base controls. Particularly relevant: 8.2.1 (customer agreements), 8.4.1 (limit processing to contract scope), 8.5.4–8.5.5 (notification and handling of government access requests). Cross-reference ISO/IEC 27018 via Annex E. + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +| File | When to load | +|------|-------------| +| `references/pims-overview.md` | Framework overview, clause 6 ISO 27002 guidance, PIMS scope and context questions | +| `references/controller-controls.md` | All Clause 7 PII Controller controls with descriptions and implementation guidance | +| `references/processor-controls.md` | All Clause 8 PII Processor controls with descriptions and implementation guidance | +| `references/gdpr-iso29100-mapping.md` | Mapping between ISO 27701 controls and GDPR articles; ISO 29100 privacy principles | +| `references/templates.md` | Privacy policy template, RoPA template, PIA template, consent records, rights request procedures | + +**When to load reference files:** +- User asks about a specific clause or control → load the relevant reference file +- Performing gap analysis → load controller-controls.md and/or processor-controls.md +- GDPR alignment or mapping question → load gdpr-iso29100-mapping.md +- Generating documents → load templates.md +- General PIMS scope/context questions → load pims-overview.md diff --git a/plugins/iso27701/skills/iso27701/references/controller-controls.md b/plugins/iso27701/skills/iso27701/references/controller-controls.md new file mode 100644 index 0000000..1013a61 --- /dev/null +++ b/plugins/iso27701/skills/iso27701/references/controller-controls.md @@ -0,0 +1,633 @@ +# ISO 27701 — PII Controller Controls (Clause 7) + +All controls in Clause 7 are **normative** for organisations acting as PII Controllers. They are additional to the ISO 27001 Annex A and ISO 27002 controls addressed in Clause 6. + +A PII Controller is an entity that alone or jointly with others determines the purposes and means of the processing of PII. + +--- + +## 7.2 — Conditions for Collection and Processing + +### 7.2.1 — Identify and Document Purpose + +**Objective:** Establish and maintain a clear record of why PII is being processed. + +**Requirement:** +The organisation shall identify and document the specific purposes for which PII is collected and processed. Each processing activity must have an articulated purpose that is documented before processing commences. + +**What to implement:** +- Maintain a processing register (RoPA — Records of Processing Activities) that lists all processing activities with their stated purpose +- Ensure that each purpose is specific, explicit, and legitimate — not stated in vague terms such as "improving services" +- Ensure purposes are documented before collection begins (purpose cannot be retroactively created) +- Review and update purposes when processing activities change + +**Evidence for audit:** +- Up-to-date Records of Processing Activities (RoPA) with all processing activities and stated purposes +- Version history of the RoPA showing purposes pre-date or accompany collection +- Process documentation for how new processing activities are assessed for purpose documentation + +**Common pitfalls:** +- Vague purposes such as "business purposes" or "analytics" without specificity +- Purposes stated only in privacy notices but not reflected in internal records +- Processing activities added without updating the RoPA + +**GDPR:** Art. 5(1)(b) (purpose limitation), Art. 30 (records of processing activities) + +--- + +### 7.2.2 — Identify Lawful Basis + +**Objective:** Ensure each processing activity has a documented legal justification. + +**Requirement:** +The organisation shall determine and document the lawful basis for processing PII for each identified purpose. Where the applicable law requires it, a specific legal basis must be identified and recorded. + +**What to implement:** +- For each row in the RoPA, document the applicable lawful basis +- Where consent is relied upon, ensure it meets the requirements of 7.2.3 and 7.2.4 +- Where legitimate interests are the basis, conduct and document a Legitimate Interests Assessment (LIA) / balancing test +- Document any special category PII and the additional lawful basis required for its processing + +**Lawful basis options (aligned to GDPR Art. 6 and equivalent legislation):** +| Basis | When applicable | +|-------|----------------| +| Consent | PII principal has freely given, specific, informed, and unambiguous agreement | +| Contract | Processing necessary for a contract with the PII principal | +| Legal obligation | Processing required to comply with a law | +| Vital interests | Processing necessary to protect life of the PII principal or another person | +| Public task | Processing necessary for a task in the public interest or exercise of official authority | +| Legitimate interests | Processing necessary for the organisation's or a third party's legitimate interests, provided not overridden by the individual's rights | + +**Evidence for audit:** +- RoPA with lawful basis column populated for every processing activity +- Legitimate Interests Assessments where legitimate interests are relied upon +- Records showing legal review of lawful basis determinations +- Special category PII processing documented with both the Art. 6 basis and the additional condition (e.g., explicit consent, employment law, vital interests) + +**GDPR:** Art. 6 (lawfulness), Art. 9 (special categories), Art. 10 (criminal convictions) + +--- + +### 7.2.3 — Determine When and How Consent Is to Be Obtained + +**Objective:** Design a consent mechanism that meets applicable legal requirements. + +**Requirement:** +Where consent is used as the lawful basis for processing, the organisation shall determine the procedure for obtaining and recording consent prior to any processing under that basis commencing. The consent mechanism must ensure consent is freely given, specific, informed, unambiguous, and — where required by law — explicit (for special categories). + +**What to implement:** +- Document the consent collection method for each processing activity where consent is the basis +- Ensure granularity: separate consent for each processing purpose (bundling is not permitted) +- Ensure consent language is plain and intelligible — avoid pre-ticked boxes +- Define the age of consent threshold (under GDPR: typically 16 years; some EU member states permit 13–15) +- Design the consent flow to make withdrawal as easy as giving consent +- Document what records of consent are captured (who, what, when, how) + +**Evidence for audit:** +- Consent design documentation or mockup of consent collection interface +- Documented decision on consent age threshold and any verification mechanism +- Sample consent records +- Privacy engineering review confirming withdrawal mechanism is as easy as giving consent + +**GDPR:** Art. 7, Art. 8 (children's consent), Recital 32, Recital 43 + +--- + +### 7.2.4 — Obtain and Record Consent + +**Objective:** Capture and maintain evidence of consent for each PII principal where consent is relied upon. + +**Requirement:** +The organisation shall obtain and maintain records of consent from PII principals before processing under consent begins. Records must demonstrate that valid consent was given, and must be preserved for the duration of the processing relationship. + +**What to implement:** +- Implement a consent recording system that stores: who consented, to what, when, how, and through which mechanism or version of the privacy notice +- Ensure consent records are retrievable per PII principal +- Implement a mechanism to invalidate consent records when consent is withdrawn +- Maintain version histories of consent notices so historic records can be validated against the notice in force at the time of consent + +**Evidence for audit:** +- Consent database or equivalent records, searchable by PII principal identifier +- Evidence of version-controlled privacy/consent notices +- Demonstration that withdrawn consent is reflected in the processing status of the PII principal's data +- Data retention policy covering consent records themselves + +**GDPR:** Art. 7(1) (burden of proof on controller), Art. 7(3) (right to withdraw) + +--- + +### 7.2.5 — Privacy Impact Assessment + +**Objective:** Systematically identify and treat privacy risks for new or significantly changed processing activities. + +**Requirement:** +The organisation shall establish and implement a PIA (Privacy Impact Assessment) programme. PIAs must be conducted before initiating processing activities that may result in high risk to PII principals, and the results must inform risk treatment decisions. + +**PIA process steps:** +1. **Screening/threshold assessment:** Determine whether a full PIA is required based on documented trigger criteria +2. **Describe the processing:** Document the nature, scope, context, and purposes of the processing +3. **Assess necessity and proportionality:** Verify that processing is limited to what is necessary +4. **Assess risks to PII principals:** Evaluate likelihood and severity of harm to individuals +5. **Identify mitigation measures:** Select controls to reduce identified risks to an acceptable level +6. **Document outcome:** Record the PIA result, residual risk assessment, and approver +7. **Consult supervisory authority if required:** Where high residual risk remains after mitigation + +**Evidence for audit:** +- PIA procedure document with defined trigger criteria +- Log/register of all PIAs conducted +- Sample completed PIAs including screening assessment, risk assessment, and outcome +- Evidence of corrective actions arising from PIA findings +- Records of where supervisory authority consultation was determined necessary + +**GDPR:** Art. 35 (DPIA), Art. 36 (prior consultation), WP248 rev.01 (DPIA criteria) + +--- + +### 7.2.6 — Contracts with PII Processors + +**Objective:** Ensure binding privacy obligations are placed on all processors engaged by the organisation. + +**Requirement:** +Where the organisation engages a PII Processor to process PII on its behalf, it shall ensure that a written contract (or equivalent legal instrument) is in place before processing commences. The contract must require the processor to process PII only on the controller's documented instructions and to apply appropriate technical and organisational security measures. + +**Required contract provisions (minimum):** +- Process PII only on documented instructions from the controller +- Bind all staff to confidentiality obligations +- Implement appropriate security measures +- Engage sub-processors only with the controller's prior written authorisation (general or specific) +- Assist the controller in meeting PII principal rights obligations +- Delete or return all PII at contract end, per controller instruction +- Provide evidence of compliance to the controller +- Notify the controller of any breach of PII without undue delay + +**Evidence for audit:** +- Register of all PII processors with contract status +- Sample processor agreements showing all required provisions +- Approval records for new processor engagements +- Sub-processor notification/approval records + +**GDPR:** Art. 28 (processor), Art. 29 (processing under authority) + +--- + +### 7.2.7 — Joint PII Controllers + +**Objective:** Define and document responsibilities where two or more controllers jointly determine processing purposes and means. + +**Requirement:** +Where the organisation processes PII jointly with one or more other PII controllers, it shall establish and document a joint controller arrangement. The arrangement must allocate responsibilities between the parties for meeting applicable privacy obligations, particularly as regards PII principal rights and transparency. + +**What to implement:** +- Identify any joint controller arrangements in the RoPA +- Conclude a joint controller agreement with each joint controller partner +- Agree on which party is the primary contact for PII principals +- Ensure the essential details of the joint controller arrangement are made available to PII principals + +**Evidence for audit:** +- RoPA entries identifying joint controller arrangements +- Signed joint controller agreements with all joint controllers +- Privacy notice that discloses the joint controller relationship to PII principals + +**GDPR:** Art. 26 (joint controllers) + +--- + +### 7.2.8 — Records of PII Processing Activities (RoPA) + +**Objective:** Maintain an authoritative register of all processing activities involving PII. + +**Requirement:** +The organisation shall create and maintain a documented Record of Processing Activities (RoPA) covering all processing activities conducted as a PII Controller. The RoPA must be kept up-to-date and must be available to the supervisory authority on request. + +**Required RoPA fields:** +| Field | Description | +|-------|-------------| +| Processing activity name | Descriptive name of the processing activity | +| Controller name and contact details | Legal entity name, registered address, DPO contact | +| Purpose(s) of processing | Each specific, documented purpose | +| Lawful basis | Per purpose | +| Categories of PII principals | e.g., Customers, Employees, Job Applicants | +| Categories of PII | e.g., Name, Email, Financial data, Health data | +| Special category PII? | Yes/No; if yes, list categories and additional lawful basis | +| Recipients of PII | Internal and external recipients including processors | +| Third country transfers | Countries; safeguard mechanism (e.g., adequacy decision, SCCs, BCRs) | +| Retention period | Per PII category or processing purpose | +| Security measures | Summary reference to applicable technical/organisational measures | +| Date created / last reviewed | For currency management | + +**Evidence for audit:** +- Current, complete RoPA covering all in-scope processing activities +- Process showing how new processing activities are added to the RoPA +- Change log or version control showing RoPA is maintained over time + +**GDPR:** Art. 30 (records of processing activities) + +--- + +### 7.2.9 — PII in Data/System Inventories + +**Objective:** Maintain visibility of all systems and data stores that hold PII. + +**Requirement:** +The organisation shall maintain an inventory of information systems, data stores, and applications that process PII. This inventory supports the RoPA, risk assessment, and security control allocation for PII assets. + +**What to implement:** +- Extend the ISO 27001 asset inventory to include PII classification per asset +- Document for each PII-holding asset: asset type, PII categories stored, PII volume (approximate), system owner, and applicable security controls +- Link the asset inventory to the RoPA so each processing activity maps to the systems involved +- Review the inventory at least annually and on significant system changes + +**Evidence for audit:** +- Asset inventory with PII classification column +- Cross-reference between asset inventory and RoPA +- Annual review record + +--- + +## 7.3 — Obligations to PII Principals + +### 7.3.1 — Obligation to PII Principals + +**Objective:** Establish the organisation's commitment to fulfilling all applicable PII principal rights. + +**Requirement:** +The organisation shall determine the applicable PII principal rights under the law(s) governing the PIMS scope and establish procedures to fulfil those obligations. Applicable rights must be documented in the privacy notice provided to PII principals. + +**Core rights to implement (privacy law aligned):** +- Right of access to their PII +- Right to rectification of inaccurate PII +- Right to erasure (right to be forgotten) +- Right to restrict processing +- Right to data portability (where applicable by law) +- Right to object to processing (including profiling) +- Rights related to automated decision-making + +**Evidence for audit:** +- Documented rights procedures for each applicable right +- Privacy notice disclosing available rights +- Training records showing staff know how to route and handle rights requests +- Log of rights requests received and fulfilled + +--- + +### 7.3.2 — Determine Information for PII Principals + +**Objective:** Identify what information must be provided to PII principals at the time of, or before, collection of their PII. + +**Requirement:** +The organisation shall determine what information it is obligated to provide to PII principals about its processing activities, including: the identity and contact details of the organisation, the purposes of processing, the lawful basis, recipients, retention periods, rights available to PII principals, and any automated decision-making. + +**Disclosure checklist (derived from GDPR Art. 13/14 and equivalent laws):** +- [ ] Controller identity and contact details +- [ ] DPO contact details (where applicable) +- [ ] Processing purposes and lawful basis for each +- [ ] Legitimate interests relied upon (if applicable) +- [ ] Recipients or categories of recipients +- [ ] Third country transfers and safeguards +- [ ] Retention periods +- [ ] Rights available (access, rectification, erasure, restriction, portability, object) +- [ ] Right to withdraw consent (where consent is the basis) +- [ ] Right to lodge a complaint with the supervisory authority +- [ ] Whether provision of PII is a statutory or contractual requirement +- [ ] Existence of automated decision-making / profiling and meaningful information about the logic + +--- + +### 7.3.3 — Provide Information to PII Principals + +**Objective:** Deliver the required disclosures to PII principals in a clear and accessible manner. + +**Requirement:** +The organisation shall provide the information determined under 7.3.2 to PII principals at or before the time PII is collected (where PII is obtained directly) or within a reasonable period (where PII is obtained indirectly). The information must be provided in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. + +**Implementation:** +- Publish a privacy notice/privacy policy on the organisation's website prominently +- For new data collection points (forms, apps, checkout flows), display a notice at the point of collection +- For indirect collection (purchasing data from brokers, obtaining via third parties), notify PII principals within a reasonable period (not exceeding one month under GDPR Art. 14(3)(a)) +- Maintain version history of privacy notices for audit purposes + +**Evidence for audit:** +- Current privacy notice with all required disclosures +- Historical versions of the privacy notice with effective dates +- Evidence of how the notice is presented to PII principals at collection points +- Records of indirect collection notification campaigns + +**GDPR:** Art. 12 (transparency), Art. 13 (direct collection), Art. 14 (indirect collection) + +--- + +### 7.3.4 — Provide Mechanism to Modify or Withdraw Consent + +**Objective:** Enable PII principals to modify or withdraw their consent at any time, as easily as it was given. + +**Requirement:** +Where consent is the lawful basis, the organisation shall provide a mechanism for PII principals to withdraw or modify their consent at any time. Withdrawal must be as easy as giving consent and must not result in the PII principal being penalised for exercising this right. + +**Implementation:** +- Provide a clear withdrawal mechanism (e.g., unsubscribe link, account settings page, email request process) +- Document the maximum processing time after withdrawal before processing ceases +- Ensure downstream systems (marketing platforms, analytics tools, third-party processors) are notified of withdrawal +- Do not condition access to services on consent where it is not necessary for the service + +**Evidence for audit:** +- Demonstration of withdrawal mechanism in the product/service +- Process document for propagating withdrawal to all downstream systems and processors +- Test evidence showing processing ceases within the stated timeline after withdrawal + +--- + +### 7.3.5 — Provide Mechanism for Objecting to Processing + +**Objective:** Enable PII principals to object to processing based on legitimate interests or for direct marketing. + +**Requirement:** +Where processing is based on legitimate interests or is for direct marketing purposes, the organisation shall provide a mechanism for PII principals to object. Direct marketing objections must always be honoured without assessment; legitimate interests objections must be assessed against whether the organisation has compelling grounds. + +**Implementation:** +- Include the right to object in the privacy notice +- Provide a contact mechanism for submitting objection requests (email, online form) +- For direct marketing: implement an opt-out mechanism (e.g., unsubscribe in all commercial emails), and honour all opt-outs within the maximum permissible timeframe +- For legitimate interests objections: conduct a documented balancing assessment within the response window +- Log all objection requests and outcomes + +**GDPR:** Art. 21 (right to object), Art. 17(1)(c) (erasure following successful objection) + +--- + +### 7.3.6 — Access to PII + +**Objective:** Enable PII principals to obtain confirmation and a copy of their PII being processed. + +**Requirement:** +The organisation shall implement a procedure for handling Subject Access Requests (SARs) / PII access requests. The procedure must enable the organisation to confirm whether PII is being processed, provide a copy of the PII, and supply all required supplementary information within the legally required timeframe. + +**SAR procedure steps:** +1. Receive request (any channel; note submission date and time) +2. Verify identity of the requestor (proportionate to sensitivity of PII) +3. Acknowledge receipt within required timeframe +4. Locate all PII held across all systems and data stores +5. Compile response (copy of PII + mandatory supplementary details) +6. Apply redactions for third-party data +7. Deliver response within legal deadline (e.g., 30 days under GDPR Art. 12(3)) +8. Log the request, actions, and outcome + +**Evidence for audit:** +- SAR procedure documentation +- SAR log/register with dates, actions, and outcomes +- Sample responses (appropriately anonymised) +- Training records for staff handling SARs + +**GDPR:** Art. 15 (right of access) + +--- + +### 7.3.7 — Rectification and Erasure + +**Objective:** Enable PII principals to correct inaccurate PII and request erasure where the right applies. + +**Requirement:** +The organisation shall implement procedures to handle rectification and erasure requests from PII principals within legally required timelines. Rectification must be applied to all copies of the PII held, including in backup systems and by processors. Erasure must be applied where the right is established and no overriding legal basis to retain applies. + +**Erasure conditions (right applies when):** +- PII is no longer necessary for the purpose it was collected +- PII principal withdraws consent and no other lawful basis applies +- PII principal objects and there are no overriding legitimate grounds +- PII has been processed unlawfully +- Erasure is required by applicable law +- PII was collected from a child + +**Erasure is not required when processing is necessary for:** +- Exercise of freedom of expression +- Compliance with a legal obligation +- Public interest +- Legal claims + +**Evidence for audit:** +- Rectification and erasure procedure documents +- Log of rectification and erasure requests with outcomes +- Evidence of notification to processors and other recipients of PII following rectification/erasure +- Backup and archive policy addressing erasure from backup media + +**GDPR:** Art. 16 (rectification), Art. 17 (erasure) + +--- + +### 7.3.8 — PII Controllers Informing PII Processors + +**Objective:** Ensure processors are notified of any changes to processing instructions, including those arising from PII principal rights outcomes. + +**Requirement:** +Where a PII Controller instructs a PII Processor, and where the outcome of a PII principal rights request or a change to processing conditions requires a change in what the processor does, the Controller shall notify the Processor promptly. + +**Implementation:** +- Establish a notification procedure from the rights fulfilment team to the processor management function +- Include provisions in processor contracts requiring the processor to acknowledge and act on Controller instructions within defined timeframes +- Log all instructions issued to processors and their acknowledgement + +--- + +## 7.4 — Privacy by Design and Privacy by Default + +### 7.4.1 — Limit Collection + +**Objective:** Ensure only PII that is necessary for the stated purpose is collected. + +**Requirement:** +The organisation shall limit the collection of PII to the minimum necessary for the identified and documented purpose. Collection of PII that exceeds what is required for the purpose (over-collection) is not permitted. + +**What to implement:** +- Include data minimisation requirements in system design and development standards +- Require a justification for each PII field collected against the stated purpose +- Include data minimisation review as part of PIA and system design reviews +- Challenge business requests to collect additional PII without a documented purpose + +**Evidence for audit:** +- Privacy engineering / design review records showing data element justification +- PIA records documenting minimisation assessment +- Development standards that include data minimisation requirements + +**GDPR:** Art. 5(1)(c) (data minimisation), Art. 25(2) (privacy by default) + +--- + +### 7.4.2 — Limit Processing + +**Objective:** Ensure PII is processed only for the purposes for which it was collected, and only to the extent necessary. + +**Requirement:** +The organisation shall implement purpose limitation controls to prevent PII from being used for secondary purposes that were not disclosed to the PII principal at the time of collection. Where secondary processing is considered, a compatibility assessment must be conducted. + +**What to implement:** +- Technical access controls limiting which systems and personnel can access PII to those with a need linked to the specified purpose +- Audit logging to detect access outside the intended purpose +- A process for assessing compatibility when new secondary purposes are identified +- Prohibition on sharing PII internally for purposes not covered by the original disclosure + +**GDPR:** Art. 5(1)(b) (purpose limitation), Art. 6(4) (compatible processing) + +--- + +### 7.4.3 — Accuracy and Quality + +**Objective:** Maintain the accuracy, completeness, and currency of PII held. + +**Requirement:** +The organisation shall implement measures to ensure PII is accurate and, where necessary, kept up to date. Inaccurate or outdated PII must be corrected or deleted without delay. + +**What to implement:** +- Provide PII principals with mechanisms to update their information (e.g., account self-service) +- Implement data quality checks at point of collection +- Define processes for proactive data quality reviews for long-held PII +- Ensure rectification requests (7.3.7) trigger updates to all records + +**GDPR:** Art. 5(1)(d) (accuracy) + +--- + +### 7.4.4 — PII Minimisation Objectives + +**Objective:** Set measurable objectives for reducing PII collection and processing to the minimum necessary. + +**Requirement:** +The organisation shall define privacy objectives related to PII minimisation, monitor progress against them, and take corrective action where objectives are not met. + +**Example minimisation objectives:** +- Reduce the number of optional PII fields in registration forms by [X]% by [date] +- Achieve 100% pseudonymisation of PII in non-production environments by [date] +- Reduce retention of marketing PII beyond defined consent periods to zero + +--- + +### 7.4.5 — De-identification and Deletion + +**Objective:** Reduce privacy risk by anonymising or deleting PII where it is no longer needed. + +**Requirement:** +The organisation shall implement de-identification and/or deletion measures for PII that is no longer required for the identified purpose. Where de-identification is used in place of deletion, the technique must render the PII non-identifiable and the process must be documented and verified. + +**De-identification techniques:** +| Technique | Description | Risk Level | +|-----------|-------------|------------| +| Anonymisation | Irreversible removal of all identifiers such that re-identification is impossible | Lowest (no longer PII once anonymised) | +| Pseudonymisation | Replacing direct identifiers with pseudonyms; re-identification possible with additional data | Moderate (still PII under GDPR) | +| Data masking | Partially obscuring PII (e.g., email: a****@domain.com) | Varies by level of masking | +| Aggregation | Replacing individual records with statistical summaries | Low if aggregation is sufficient | +| K-anonymity / l-diversity | Statistical privacy protection ensuring each record is indistinguishable from k-1 others | Depends on implementation | + +**Evidence for audit:** +- Data disposal / deletion procedure +- De-identification standards and validation procedures +- Records of deletion events (what was deleted, when, by whom) +- Confirmation that backup media containing PII is eventually overwritten or securely destroyed + +--- + +### 7.4.6 — Temporary Files + +**Objective:** Ensure PII contained in temporary files (which arise during processing) does not persist beyond its intended use. + +**Requirement:** +The organisation shall identify and implement controls to ensure that temporary files containing PII are not retained longer than necessary for the processing purpose that created them. Temporary files include cache files, log files, working files, backup work files, and other ephemeral stores. + +**Implementation:** +- Document all known temporary file types and their expected lifecycle +- Implement automated deletion or purging of temporary files containing PII after processing completes +- Include temporary file management in PIA and security review procedures +- Restrict developer access to temporary files containing production PII + +--- + +### 7.4.7 — Retention + +**Objective:** Ensure PII is not retained beyond the period necessary for its processing purpose, or beyond applicable legal retention obligations. + +**Requirement:** +The organisation shall establish, document, and enforce retention schedules for each category of PII. PII must be deleted or anonymised when the retention period expires, unless a legal obligation requires retention. + +**Retention schedule components:** +| PII Category | Processing Purpose | Retention Period | Retention Basis | Disposal Method | Owner | +|--------------|-------------------|-----------------|-----------------|----------------|-------| +| Customer account data | Contract fulfilment | Duration of contract + 7 years | Legal obligation (tax/accounting) | Secure deletion | IT/Legal | +| Marketing email lists | Direct marketing | Until consent withdrawn or 2 years inactive | Consent | Secure deletion | Marketing | +| Job applicant data (unsuccessful) | Recruitment | 6 months post-rejection | Legitimate interests | Secure deletion | HR | +| Employee HR records | Employment | Duration of employment + 6 years | Legal obligation | Secure deletion + archive | HR | +| CCTV footage | Security | 30 days unless incident identified | Legitimate interests | Automatic overwrite | Facilities | + +**Evidence for audit:** +- Published retention schedule / data retention policy +- Evidence of automated or managed deletion processes +- Audit of retention compliance (sample check of data stores vs. schedule) +- Records of legal hold process when retention is extended for litigation + +**GDPR:** Art. 5(1)(e) (storage limitation) + +--- + +## 7.5 — PII Sharing, Transfer and Disclosure + +### 7.5.1 — Basis for PII Transfer Between Jurisdictions + +**Objective:** Ensure that international transfers of PII have a lawful basis before the transfer occurs. + +**Requirement:** +The organisation shall determine and document the legal mechanism relied upon for each transfer of PII to countries or international organisations where the level of data protection may differ. No transfer shall occur without a documented lawful transfer mechanism. + +**Transfer mechanisms (aligned to GDPR Chapter V and comparable laws):** +| Mechanism | Description | +|-----------|-------------| +| Adequacy decision | Transfer to a country recognised by the relevant authority as providing adequate protection (e.g., EU adequacy decisions for UK, Israel, Japan, South Korea, etc.) | +| Standard Contractual Clauses (SCCs) | EU Commission approved model clauses incorporated into a binding contract between exporter and importer | +| Binding Corporate Rules (BCRs) | Approved intra-group policies governing transfers within a multinational enterprise | +| Approved Codes of Conduct | Transfer covered by an approved code with binding and enforceable commitments | +| Certification mechanisms | Transfer to a certified recipient (once certification mechanisms are approved) | +| Specific derogations | Transfer based on explicit consent, contract performance, vital interests, public interest, or legal claims — only for non-repetitive transfers where compelling necessity applies | + +**Evidence for audit:** +- Transfer impact assessments (where required — e.g., SCCs to non-adequate third countries) +- RoPA entries documenting all third country transfers with the mechanism relied upon +- Copies of signed SCCs or BCR documentation +- Evidence that transfers to non-adequate countries have been assessed and approved + +**GDPR:** Art. 44–49 (international transfers) + +--- + +### 7.5.2 — Countries and International Organisations to Which PII Can Be Transferred + +**Objective:** Maintain an approved list of transfer destinations with confirmed lawful mechanisms. + +**Requirement:** +The organisation shall maintain a record of all countries and international organisations to which PII may be transferred, along with the legal safeguard in place for each destination. This list should be reflected in the RoPA (7.2.8) and disclosed in the privacy notice (7.3.3). + +**Implementation:** +- Maintain a countries-and-safeguards register as part of the RoPA or as a supplementary document +- Review the register when transfer destinations change, when adequacy decisions are issued/revoked, or when the standard contractual clauses in use are updated +- Where the Schrems II judgment or equivalent rulings affect the legal basis relied upon, conduct a Transfer Impact Assessment (TIA) to confirm transfers remain lawful + +**Evidence for audit:** +- Countries and safeguards register +- Transfer Impact Assessment (TIA) documentation for transfers to non-adequate destinations +- Up-to-date SCC documentation reflecting the current approved versions + +--- + +### 7.5.3 — Records of PII Disclosures to Third Parties + +**Objective:** Maintain a comprehensive log of all PII disclosures to third parties for accountability and audit purposes. + +**Requirement:** +The organisation shall maintain records of PII that has been disclosed to third parties (other than as part of documented processor relationships). These records support the organisation's accountability obligations, enable management of PII principal access requests, and demonstrate compliance. + +**Records to maintain:** +- Third party identity +- Categories of PII disclosed +- Date and method of disclosure +- Legal basis or business reason for disclosure (e.g., law enforcement request, court order, contractual obligation) +- Whether the PII principal was notified of the disclosure and if not, why + +**Evidence for audit:** +- Disclosure log with entries for all PII disclosures outside processor relationships +- Process for how ad-hoc disclosure requests (e.g., from law enforcement) are assessed, approved, and logged +- Records of controller notification to PII principals of disclosures where required + +**GDPR:** Art. 30 (records), Art. 33–34 (breach notification includes disclosure context) diff --git a/plugins/iso27701/skills/iso27701/references/gdpr-iso29100-mapping.md b/plugins/iso27701/skills/iso27701/references/gdpr-iso29100-mapping.md new file mode 100644 index 0000000..d2c9362 --- /dev/null +++ b/plugins/iso27701/skills/iso27701/references/gdpr-iso29100-mapping.md @@ -0,0 +1,146 @@ +# ISO 27701 — GDPR Mapping and ISO 29100 Privacy Principles + +## Part 1: ISO 27701 to GDPR Mapping + +ISO 27701:2019 Annex C provides an informative mapping between its clauses and the EU General Data Protection Regulation (GDPR). This reference file expands on that mapping with practical compliance notes. + +The mapping enables organisations to use ISO 27701 certification as documented evidence that appropriate technical and organisational measures (GDPR Art. 25, 32) are in place, and to demonstrate accountability (GDPR Art. 5(2)). + +> **Important caveat:** ISO 27701 certification does not constitute legal compliance with GDPR. GDPR is a legal obligation enforced by supervisory authorities. ISO 27701 provides a framework and documented evidence but does not substitute for legal counsel, DPA registration, or supervisory authority engagement where required. + +--- + +### Clause 5 Extensions — GDPR Mapping + +| ISO 27701 Clause | ISO 27701 Requirement Extended | GDPR Article(s) | Compliance Notes | +|-----------------|-------------------------------|-----------------|-----------------| +| 5.2.1 | Context — privacy laws and regulations identification | Art. 5(2) (accountability), Art. 24 (controller responsibility) | Documenting applicable law demonstrates the accountability principle | +| 5.2.2 | Interested parties — include PII principals, DPAs | Art. 4(21) (supervisory authority), Art. 77 (right to complain) | Identifying supervisory authorities is required; identifying PII principals as stakeholders supports rights implementation | +| 5.2.3 | PIMS scope — PII types, purposes, roles | Art. 30 (RoPA), Art. 5(1)(b) (purpose limitation) | Scope documentation forms the basis for RoPA and purpose limitation compliance | +| 5.3.1 | Leadership commitment to privacy | Art. 5(2) (accountability), Art. 24(1) (controller responsibility) | Top management commitment evidences accountability; required for demonstrating GDPR compliance by design | +| 5.3.2 | Privacy policy | Art. 12–14 (transparency), Art. 5(1)(a) (lawfulness, fairness, transparency) | External privacy notice must satisfy Art. 13 or 14; internal policy supports Art. 5(2) accountability | +| 5.3.3 | Privacy roles — DPO consideration | Art. 37–39 (DPO requirements and tasks) | Where DPO is mandated by Art. 37, appointment and tasks must comply with Art. 38–39; 27701 does not mandate DPO but requires privacy roles | +| 5.4.1 | Privacy risk assessment | Art. 32(2) (security risk assessment), Art. 35 (DPIA) | Privacy risk assessment methodology satisfies Art. 32(2); PIA process maps to DPIA where high risk exists | +| 5.4.2 | Privacy objectives | Art. 5(2) (accountability) | Measurable objectives with monitoring evidence demonstrate accountability | +| 5.5 | Privacy competence and awareness | Art. 32(4) (staff awareness), Art. 29 (staff authority) | Staff training on data protection obligations is required; Art. 29 states staff must act under controller/processor authority | +| 5.6.1 | Operational planning — PII rights procedures | Art. 12(2) (facilitate rights), Art. 17–22 (subject rights) | Documented rights procedures demonstrate that the controller facilitates rights; required to meet response timelines | +| 5.6.2 | Privacy risk assessment execution | Art. 35 (DPIA for high-risk processing) | Regular risk assessment reviews support continuous compliance; DPIA required for high-risk processing identified in assessment | +| 5.6.3 | Privacy risk treatment | Art. 25 (data protection by design), Art. 32 (security measures) | Risk treatment selection mapping to controls demonstrates DPDBD implementation | +| 5.7 | Performance monitoring and audit | Art. 5(2) (accountability), Art. 32 (review of measures) | PIMS audit and management review provide evidence of ongoing compliance monitoring | +| 5.8 | Improvement — nonconformity and breach handling | Art. 33 (72-hour breach notification to DPA), Art. 34 (communication to data subjects) | Privacy incident process must meet Art. 33–34 notification timelines; corrective action records demonstrate accountability | + +--- + +### Clause 7 PII Controller Controls — GDPR Mapping + +| ISO 27701 Control | Control Name | GDPR Article(s) | Compliance Notes | +|------------------|-------------|-----------------|-----------------| +| 7.2.1 | Identify and document purpose | Art. 5(1)(b) purpose limitation, Art. 30(1)(b) | Every RoPA entry must state a specific, documented purpose — directly satisfies Art. 30(1)(b) | +| 7.2.2 | Identify lawful basis | Art. 6(1) lawful basis, Art. 9(2) special categories | Each processing activity requires a legal ground; special categories require both an Art. 6 and Art. 9 basis | +| 7.2.3 | Determine consent procedure | Art. 7 (consent conditions), Art. 8 (child consent) | Consent design must meet Art. 7 requirements; age verification where children may consent | +| 7.2.4 | Obtain and record consent | Art. 7(1) (burden of proof on controller) | Controller must demonstrate that consent was given — records are the primary evidence | +| 7.2.5 | Privacy Impact Assessment | Art. 35–36 (DPIA and prior consultation) | PIA process maps to DPIA; for high-risk processing Art. 35 mandates a DPIA; Art. 36 requires prior consultation with supervisory authority if high residual risk cannot be mitigated | +| 7.2.6 | Contracts with PII processors | Art. 28 (processor agreement requirements) | A written processor agreement satisfying all Art. 28(3) requirements is mandatory | +| 7.2.7 | Joint PII controllers | Art. 26 (joint controllers) | A written joint controller arrangement satisfying Art. 26 requirements is mandatory; essence must be disclosed to data subjects | +| 7.2.8 | Records of PII processing activities | Art. 30(1) (controller RoPA) | RoPA is mandatory for controllers with 250+ employees or whose processing meets Art. 30(5) conditions; all fields in 7.2.8 map to Art. 30(1)(a–g) | +| 7.2.9 | PII in data/system inventories | Art. 30(1)(g) (security measures), Art. 32 | Asset inventory supporting security measures required for Art. 32 risk-based security assessment | +| 7.3.1 | Obligation to PII principals | Art. 12–22 (rights chapter overview) | The rights obligations in 7.3 map to the entire GDPR rights chapter | +| 7.3.2 | Determine information for PII principals | Art. 13(1–2), Art. 14(1–2) (mandatory disclosures) | Art. 13 applies to direct collection; Art. 14 to indirect collection; both specify what must be disclosed | +| 7.3.3 | Provide information to PII principals | Art. 12 (transparent communication), Art. 13, Art. 14 | Privacy notice must be provided at collection time (Art. 13) or within 1 month of indirect collection (Art. 14(3)(a)) | +| 7.3.4 | Modify or withdraw consent mechanism | Art. 7(3) (right to withdraw) | Withdrawal must be as easy as giving consent; must not affect lawfulness of prior processing; downstream effect must be managed | +| 7.3.5 | Objecting to processing mechanism | Art. 21 (right to object) | Direct marketing objections must always be honoured; legitimate interests objections assessed vs. compelling grounds | +| 7.3.6 | Access to PII | Art. 15 (right of access) | Controller must provide copy of PII and supplementary information within 1 month (Art. 12(3)); extension to 2 months permitted for complex/numerous requests | +| 7.3.7 | Rectification and erasure | Art. 16 (rectification), Art. 17 (erasure) | Rectification: without undue delay; Erasure: without undue delay where conditions in Art. 17(1) are met; restrictions apply per Art. 17(3) | +| 7.3.8 | Inform PII processors of changes | Art. 28(3)(f) (processor assistance), Art. 19 (notification obligation) | Controller must notify processors of rectification, erasure, or restriction and processors must notify their own sub-recipients unless this proves impossible or involves disproportionate effort | +| 7.4.1 | Limit collection | Art. 5(1)(c) data minimisation, Art. 25(2) privacy by default | Privacy by default (Art. 25(2)) requires that by default, only personal data necessary for each specific purpose is processed | +| 7.4.2 | Limit processing | Art. 5(1)(b) purpose limitation | Purpose limitation principle — data must not be processed in a manner incompatible with the original purpose | +| 7.4.3 | Accuracy and quality | Art. 5(1)(d) accuracy | PII must be accurate and kept up to date; inaccurate data must be erased or rectified without delay | +| 7.4.4 | PII minimisation objectives | Art. 5(1)(c) data minimisation, Art. 25(1) DPbD | Privacy by design (Art. 25(1)) requires implementation of data minimisation measures at design phase | +| 7.4.5 | De-identification and deletion | Art. 5(1)(e) storage limitation, Art. 17 erasure | Storage limitation requires data is not retained longer than necessary; anonymisation removes GDPR applicability; pseudonymisation is still personal data under GDPR | +| 7.4.6 | Temporary files | Art. 5(1)(e) storage limitation, Art. 32 security | Temporary files unmanaged may constitute a security gap (Art. 32) and a retention violation (Art. 5(1)(e)) | +| 7.4.7 | Retention | Art. 5(1)(e) storage limitation, Art. 30(1)(f) retention periods in RoPA | Retention periods must appear in RoPA; storage limitation is a core data protection principle | +| 7.5.1 | Basis for PII transfer between jurisdictions | Art. 44 (general principle — transfers require mechanism) | No transfer to third country without a valid mechanism under Art. 44–49 | +| 7.5.2 | Countries and international organisations | Art. 45 (adequacy), Art. 46 (appropriate safeguards), Art. 49 (derogations) | Transfer mechanism must be one of: adequacy decision, SCCs, BCRs, approved code/certification, or derogation | +| 7.5.3 | Records of PII disclosures | Art. 30(1)(d) recipients, Art. 5(2) accountability | Recipients of PII (including those in third countries) must appear in RoPA; accountability requires records of who received PII | + +--- + +### Clause 8 PII Processor Controls — GDPR Mapping + +| ISO 27701 Control | Control Name | GDPR Article(s) | Compliance Notes | +|------------------|-------------|-----------------|-----------------| +| 8.2.1 | Customer agreement | Art. 28 (processing agreement), Art. 28(3) (required provisions) | Processing agreement is mandatory; all Art. 28(3) provisions must be present | +| 8.2.2 | Organisation's privacy practices | Art. 5(2) accountability, Art. 13–14 transparency | Processor transparency commitments support controller transparency obligations and accountability | +| 8.2.3 | Marketing and advertising | Art. 6(1) lawful basis, Art. 28(3)(a) (instructions only) | Using controller PII for own marketing without basis = processing outside instructions; unlawful under Art. 28(3)(a) and Art. 6 | +| 8.2.4 | Infringing instruction | Art. 28(3)(a) (processor must follow instructions), Art. 29 (staff authority) | Art. 28(3)(h) implicitly requires processor to inform controller when instruction infringes GDPR; Art. 82(2) provides processor liability defence if promptly notified controller | +| 8.2.5 | Customer obligations | Art. 26–32 (controller responsibilities) | Controllers remain responsible under GDPR even when using processors; processor-provided guidance supports controller compliance | +| 8.3.1 | Obligations to PII principals | Art. 28(3)(e) (processor must assist controller with rights) | Assistance with rights requests is a mandatory provision of the processor agreement under Art. 28(3)(e) | +| 8.3.2 | Determine information for PII principals | Art. 28(3)(f), Art. 30(2) (processor RoPA) | Processor RoPA under Art. 30(2) must document all categories of processing performed; this information supports the controller's Art. 13–14 disclosures | +| 8.4.1 | Limit processing to specified purposes | Art. 29 (processing only on controller instructions), Art. 28(3)(a) | Processing outside controller instructions is itself processing without lawful basis — direct GDPR breach | +| 8.4.2 | Data minimisation objectives | Art. 5(1)(c), Art. 25(1) privacy by design | Minimisation applies to processors as an obligation flowing from the controller; processor facilitates controller's compliance with Art. 25 | +| 8.5.1 | Basis for PII transfer between jurisdictions | Art. 44 (general principle) | Processor must not transfer to third countries outside the mechanism agreed with the controller | +| 8.5.2 | Countries and organisations for transfer | Art. 46 (safeguards), Art. 13(1)(f) / 14(1)(f) (transfer disclosure) | Controller's transparency obligation requires disclosure of third countries to PII principals; processor must provide this information | +| 8.5.3 | Records of disclosures to third parties | Art. 30(2)(d) recipients, Art. 5(2) accountability | Processor RoPA must include categories of recipients (Art. 30(2)(d)) | +| 8.5.4 | Notification of disclosure requests | Art. 28(3)(h) (processor must assist controller), EDPB guidance on government access | Processor notifying controller of law enforcement access requests supports accountability; withholding notification may create joint liability for resulting infringement | +| 8.5.5 | Legally binding disclosure requests | Art. 28(3)(h), Recital 116 | Recital 116 acknowledges lawful access by third country authorities but does not permit transfers outside GDPR Chapter V framework without safeguards | +| 8.5.6 | Disclosure based on sub-processor contracts | Art. 28(2) (sub-processor authorisation), Art. 28(4) (same contractual obligations) | General or specific authorisation required; sub-processor must be bound by same obligations; controller must be notified of sub-processor changes | + +--- + +## Part 2: ISO 29100 Privacy Framework — Privacy Principles + +ISO/IEC 29100:2011 "Information technology — Security techniques — Privacy framework" establishes 11 privacy safeguarding principles that underpin ISO 27701. Understanding these principles is essential because ISO 27701 controls are designed to implement them. + +### The 11 ISO 29100 Privacy Principles + +| # | Principle | Definition | ISO 27701 Alignment | +|---|-----------|-----------|---------------------| +| 1 | Consent and choice | PII principals should be given choice and control over their PII, including the ability to consent and withdraw consent | Clauses 7.2.3, 7.2.4, 7.3.4 | +| 2 | Purpose legitimacy and specification | Purposes must be identified, specified to PII principals, and must not be contrary to applicable law | Clauses 7.2.1, 7.2.2, 7.3.2, 7.3.3 | +| 3 | Collection limitation | PII should be limited to the minimum necessary for the identified purpose; collection should be fair, lawful, and where appropriate, with the knowledge of the PII principal | Clauses 7.2.2, 7.4.1, 8.4.2 | +| 4 | Data minimisation | The use, disclosure, and retention of PII should be minimised to the minimum necessary relative to the purpose | Clauses 7.4.1, 7.4.2, 7.4.4, 7.4.7, 8.4.2 | +| 5 | Use, retention and disclosure limitation | PII should be used, retained, and disclosed only for the purposes specified to PII principals; retained only as long as necessary; not disclosed to third parties without appropriate authorisation | Clauses 7.2.1, 7.4.2, 7.4.7, 7.5.1–7.5.3, 8.4.1 | +| 6 | Accuracy and quality | PII should be accurate, complete, up-to-date, adequate, and relevant for the purpose | Clause 7.4.3 | +| 7 | Openness, transparency and notice | PII principals should be provided with clear and easily accessible information about the organisation's privacy practices and policies | Clauses 5.3.2, 7.3.2, 7.3.3, 8.2.2 | +| 8 | Individual participation and access | PII principals should be able to access, correct, and have their PII deleted or blocked | Clauses 7.3.1, 7.3.4–7.3.7, 8.3.1 | +| 9 | Accountability | A PII controller should be accountable for complying with measures that give effect to the privacy principles | Clauses 5.3.1, 5.3.3, 5.7, 7.2.6, 7.2.7, 8.2.1 | +| 10 | Information security | PII should be protected by reasonable security safeguards against risks such as loss, unauthorised access, destruction, use, modification, or disclosure | All base ISO 27001 controls, plus Clauses 5.4.1, 5.6.2, 5.6.3 | +| 11 | Privacy compliance | The organisation should be able to demonstrate that it has met privacy requirements and should designate a person or function accountable for privacy compliance | Clauses 5.3.3, 5.7, 5.8, certification programme | + +--- + +## Part 3: Key Regulatory Reference Points Beyond GDPR + +ISO 27701 was designed to be regulation-neutral — it can be applied to support compliance with privacy laws in any jurisdiction. The following table maps ISO 27701's key control themes to comparable requirements in major privacy regulations. + +| ISO 27701 Theme | GDPR (EU/UK) | CCPA/CPRA (California) | LGPD (Brazil) | PDPA (Singapore) | PIPEDA (Canada) | +|----------------|-------------|----------------------|--------------|-----------------|----------------| +| PII inventory and RoPA | Art. 30 | Not explicitly required but supports business operations | Art. 37 (DPO and processing register) | Schedule 1 (Documentation) | Accountability principle | +| Lawful basis | Art. 6 | No equivalent — opt-out model (not opt-in) | Art. 7–11 | No explicit basis requirement but consent and legitimate purpose required | Consent unless excepted | +| Consent mechanism | Art. 7 | Opt-out for sale/share; opt-in for sensitive data | Art. 7–8 explicit consent model | Consent required unless exception | Consent at time of collection | +| Privacy notice | Art. 13–14 | Required (consumer notice at collection) | Art. 9 | Required | Required at or before collection | +| PII principal rights | Art. 15–22 | Right to Know, Delete, Correct, Opt-Out, Non-Discrimination | Art. 17–22 | Access, correction, withdrawal | Access and accuracy | +| DPIA/PIA | Art. 35 | Not mandated but good practice | Art. 38 (mandatory for high-risk) | Not mandated | Not mandated | +| Processor agreements | Art. 28 | Service provider requirements under CCPA § 1798.140 | Art. 39 | Not explicitly required in law | Required under accountability principle | +| Breach notification | Art. 33–34 | Varies by state law; California: CCPA breach provisions | Art. 48 | 3 days to PDPC, 3–30 days to affected individuals | 72-hour reporting to OPC | +| Cross-border transfers | Art. 44–49 | No federal framework; state-level varies | Art. 33 | If transferring to country without adequate protection, use contractual or BCR | Schedule 1, Principle 1 (accountability follows data) | +| DPO appointment | Art. 37 | Not required | Art. 41 (mandatory for public bodies and processing requiring DPO) | Not required | Privacy officer recommended | + +--- + +## Part 4: ISO 27701 and ISO 27018 Relationship + +ISO/IEC 27018:2019 is a code of practice for PII Processors operating as public cloud service providers. ISO 27701 maps to ISO 27018 in **Annex E** (informative). Key alignment points: + +| Topic | ISO 27018 | ISO 27701 (Processor) | +|-------|----------|----------------------| +| Customer agreements | Clause 5.1 | 8.2.1 | +| Transparency about sub-processors | Clause A.10.7 | 8.5.6, 8.2.2 | +| Return/deletion of PII at contract end | Clause A.10.9, A.11.3 | 8.2.1 (contract provision) | +| Government access requests | Clause A.11.1, A.11.2 | 8.5.4, 8.5.5 | +| Marketing prohibition | Clause A.10.1 | 8.2.3 | +| Infringing instruction | Clause A.10.2 | 8.2.4 | +| Cross-border transfers | Clause A.10.3 | 8.5.1–8.5.3 | +| Notification to PII principals via customer | Clause A.10.6 | 8.3.1, 8.3.2 | + +Cloud processors that have already implemented ISO 27018 will find significant overlap with ISO 27701 Clause 8 controls, and the combination strengthens the evidential basis for compliance. diff --git a/plugins/iso27701/skills/iso27701/references/pims-overview.md b/plugins/iso27701/skills/iso27701/references/pims-overview.md new file mode 100644 index 0000000..cbd95e3 --- /dev/null +++ b/plugins/iso27701/skills/iso27701/references/pims-overview.md @@ -0,0 +1,282 @@ +# ISO 27701 PIMS Overview — Framework, Context, and Clause 6 Guidance + +## 1. What Is a Privacy Information Management System (PIMS)? + +A Privacy Information Management System (PIMS) is a management system that extends an Information Security Management System (ISMS) to include privacy-specific requirements and controls. The PIMS governs how an organisation identifies, manages, and controls the processing of Personally Identifiable Information (PII) throughout its operations. + +ISO/IEC 27701:2019 defines the requirements and provides guidance for establishing, implementing, maintaining, and continually improving a PIMS. It operates as an **extension** to ISO/IEC 27001; it cannot be implemented or certified independently. + +--- + +## 2. Scope and Applicability + +### When ISO 27701 Applies +- Any organisation that processes PII, regardless of size, sector, or jurisdiction +- Organisations that are PII Controllers (determine purposes and means of processing) +- Organisations that are PII Processors (process on behalf of a controller) +- Organisations that function as both simultaneously (e.g., an enterprise that processes employee PII as a controller and customer data as a processor for another entity) + +### Defining the PIMS Scope (Clause 5.2.3) +The PIMS scope must be defined and documented. It must include: + +1. **Types of PII processed** — Categories of personal information in scope +2. **PII principals** — Data subjects whose PII is processed (e.g., customers, employees, job applicants, website visitors) +3. **Processing purposes** — All stated purposes for which PII is processed +4. **Controller/Processor role** — Whether the organisation acts as PII Controller, PII Processor, or both in the scope +5. **Applicable privacy laws and regulations** — List all legal requirements in scope (e.g., GDPR, UK GDPR, CCPA, LGPD, PDPA) +6. **Geographic extent** — Jurisdictions in which PII is collected, processed, or transferred +7. **Organisational boundaries** — Business units, functions, or systems included/excluded from scope +8. **PII lifecycle** — From collection through to deletion/archival + +**Scope alignment with ISO 27001:** The PIMS scope should align with or be a subset of the ISMS scope. If the PIMS scope is narrower, this must be justified and documented. + +--- + +## 3. Context of the Organisation — PIMS Extensions (Clause 5.2.1–5.2.2) + +### Understanding the Organisation (5.2.1) +In addition to the ISO 27001 context analysis, the organisation must consider: +- Applicable privacy laws, regulations, and contractual obligations relating to PII processing +- The organisation's relationship with PII as controller and/or processor +- The nature of PII categories being processed and associated sensitivities +- Locations where PII is stored, processed, and transmitted (including cloud regions) + +### Interested Parties (5.2.2) +For PIMS purposes, interested parties specifically include: +- PII principals (data subjects) — the individuals whose PII is processed +- Supervisory/regulatory authorities (e.g., ICO, CNIL, EDPB, state attorneys general) +- PII processors engaged by the organisation (if acting as a controller) +- Joint PII controllers (if applicable) +- PII controllers the organisation processes data for (if acting as a processor) +- Sub-processors engaged by the organisation (if acting as a processor) +- Law enforcement and government agencies (in the context of lawful disclosure requests) +- Certification bodies conducting PIMS audits + +--- + +## 4. Leadership and Privacy Policy (Clause 5.3) + +### Top Management Commitment (5.3.1) +Top management must: +- Establish and maintain the privacy policy +- Communicate the importance of effective privacy management throughout the organisation +- Ensure resources are allocated for the PIMS +- Direct relevant personnel to apply the PIMS requirements +- Promote continual improvement of the PIMS +- Support other management roles in demonstrating their leadership in privacy matters + +### Privacy Policy (5.3.2) +The privacy policy must: +- Be appropriate to the purpose and context of the organisation +- Include a commitment to satisfy applicable privacy laws and contractual obligations +- Include a commitment to continual improvement of the PIMS +- Be made available to PII principals and other relevant interested parties as appropriate +- Be communicated internally to all personnel + +**Note:** Most organisations maintain two distinct documents: +- An **external privacy notice** (communicated to PII principals per Art. 13/14 of GDPR) which describes what data is processed, why, and what rights data subjects have +- An **internal privacy/data protection policy** (for staff) which describes how the organisation implements its privacy commitments + +Both documents derive from the top-level privacy policy commitment. The external notice must meet legal disclosure requirements; the internal policy establishes operational obligations. + +### Roles and Responsibilities (5.3.3) +Privacy-specific roles that must be defined: +- **Privacy Officer / Data Protection Officer (DPO):** Where legally required (e.g., GDPR Art. 37), a DPO must be formally appointed. ISO 27701 does not mandate a DPO but requires that privacy responsibilities are allocated. +- **PII Stewards / Data Owners:** Business owners accountable for specific processing activities and PII categories +- **PIMS Manager:** Responsible for the day-to-day operation and improvement of the PIMS +- **Privacy Champion Network:** (Best practice) Embedded privacy contacts within business functions + +The roles and their responsibilities must be documented and communicated across the organisation. + +--- + +## 5. Planning — Privacy Risk Assessment and Objectives (Clause 5.4) + +### Privacy Risk Assessment (5.4.1) +ISO 27701 extends the ISO 27001 risk assessment process to include privacy-specific risks: +- Risks to PII principals (not just to the organisation) — this is a key difference from a purely security-focused risk assessment +- Privacy risks arising from new or changed processing activities +- Risks related to each processing purpose and PII category +- Context-specific risks (e.g., processing special category PII, processing PII of children, cross-border processing) + +**Privacy risk factors to consider:** +- Volume of PII principals affected +- Sensitivity of PII categories (special categories require heightened scrutiny) +- Processing that could result in physical, material, or non-material harm to PII principals +- Profiling and automated decision-making +- Processing in a new context or novel technology + +### Privacy Impact Assessment Triggers (5.4.1, 7.2.5) +A PIA must be conducted before any new or significantly changed processing that may result in high risk to PII principals. Mandatory triggers include: +- Systematic and extensive profiling with significant effects +- Large-scale processing of special category PII +- Systematic monitoring of public areas +- Use of new technologies involving PII +- Any processing likely to significantly affect individuals' rights and freedoms + +### Privacy Objectives (5.4.2) +Privacy objectives must be: +- Consistent with the privacy policy +- Measurable where practicable +- Communicated to relevant personnel +- Monitored and updated +- Include criteria for evaluating PIMS performance + +**Example privacy objectives:** +- Achieve 100% consent renewal within 30 days of policy change +- Respond to all PII principal rights requests within the legally required timeframe +- Conduct PIAs for 100% of qualifying new processing activities before go-live +- Complete annual privacy training for 100% of PII-handling staff +- Achieve zero critical findings in annual PIMS internal audit +- Report all privacy incidents within required notification timelines + +--- + +## 6. Support — Competence, Awareness, Communication (Clause 5.5) + +### Competence +Persons doing work that affects PIMS performance must be competent. This includes: +- Privacy officers and DPOs — formal privacy qualifications or equivalent experience +- Staff processing PII in their work — role-specific privacy training covering their obligations +- IT staff designing or managing systems that process PII — privacy by design training +- Legal and compliance staff — knowledge of applicable privacy laws + +Competence evidence: training records, certifications, CVs, attendance logs. + +### Privacy Awareness +All personnel processing PII must be aware of: +- The privacy policy and what it means for their role +- The PIMS objectives and their contribution to them +- The implications of not conforming with PIMS requirements +- How to report privacy incidents and suspected breaches +- PII principal rights and how to route requests + +### Communication +The organisation must determine what privacy-related communications are needed, when, with whom, and by what method. Relevant communications: +- Privacy notices to PII principals (transparency obligation) +- Internal privacy updates/newsletters +- Notification to processors of relevant changes +- Breach notifications to supervisory authorities and PII principals (if applicable) +- Regular privacy performance reports to top management + +--- + +## 7. Operation — Key PIMS Operational Processes (Clause 5.6) + +### Operational Planning and Control (5.6.1) +The PIMS requires the following operational processes to be documented and in place: + +1. **PII inventory management:** Maintain an up-to-date inventory of all PII and processing activities (supports 7.2.8, 7.2.9) +2. **PIA process:** Documented procedure for conducting and managing PIAs +3. **Consent management:** Processes for obtaining, recording, and withdrawing consent +4. **PII principal rights fulfilment:** Procedures for each applicable right with defined response timelines +5. **Privacy incident management:** Detection, containment, investigation, notification +6. **Processor management:** Contracting, oversight, and audit of PII processors and sub-processors +7. **Cross-border transfer management:** Identifying, authorising, and documenting transfers outside the jurisdiction +8. **Retention and deletion:** Enforcing retention schedules and secure disposal of PII + +### Privacy Risk Assessment Execution (5.6.2) +At planned intervals and when significant changes occur, the organisation must: +- Re-execute the privacy risk assessment +- Document results +- Update the risk treatment plan to reflect current risks + +### Privacy Risk Treatment (5.6.3) +Risk treatment for privacy risks must: +- Select appropriate controls from Clause 7 (controller) and/or Clause 8 (processor) +- Supplement with ISO 27002/27001 Annex A controls where relevant +- Produce a privacy risk treatment plan +- Obtain approval from accountable owners +- Implement treatments and verify effectiveness + +--- + +## 8. Performance Evaluation (Clause 5.7) + +### Monitoring and Measurement +Privacy-specific monitoring must include: +- Compliance with privacy objectives (metric tracking) +- PII principal rights request fulfilment rate and timeliness +- Privacy incident count and severity trends +- Privacy training completion rates +- PIA completion rate (qualifying processing activities vs. those with a completed PIA) +- Processor compliance status +- Open corrective actions ageing + +### Internal PIMS Audit +The internal audit programme must include PIMS scope: +- Audit against all applicable Clause 5 extensions +- Audit against applicable Clause 7 controls (if controller) +- Audit against applicable Clause 8 controls (if processor) +- Audit against ISO 27001 base requirements (the ISMS serves as the foundation) + +Internal auditors for PIMS activities should have privacy competence (not solely security audit competence). + +### Management Review +Management review must include privacy-specific agenda items: +- Privacy performance metrics +- Status of open privacy risk treatments +- Privacy incident trends +- Regulatory developments affecting the PIMS +- Customer/PII principal complaints relating to privacy +- PIMS audit results and corrective actions +- Opportunities for improvement in the PIMS + +--- + +## 9. Clause 6 — PIMS-Specific Guidance for ISO/IEC 27002 Controls + +Clause 6 of ISO 27701 provides **informative** (non-normative) guidance that supplements selected ISO 27002:2013 controls with privacy-specific considerations. The guidance applies to both PII Controllers and PII Processors unless qualified. Below is a summary of the most significant areas. + +### Information Security Policies (ISO 27002: 5.1) +**PIMS guidance:** The information security policy context must address the organisation's privacy commitments. The privacy policy (5.3.2) may be published as a separate document or as part of the IS policy suite, but must address PII-related commitments distinctly. + +### Organisation of Information Security — Roles (ISO 27002: 6.1) +**PIMS guidance:** Privacy roles must be defined alongside information security roles. Where a DPO is required by law, this requirement must be reflected in the ISMS/PIMS role structure. Confidentiality agreements with personnel should include privacy obligations. + +### Human Resource Security (ISO 27002: 7) +**PIMS guidance:** Pre-employment screening should consider access to PII. Employment terms must include privacy obligations. Termination procedures must address PII access revocation and return/deletion of PII held by departed staff. + +### Asset Management (ISO 27002: 8) +**PIMS guidance:** The asset inventory must identify assets that store or process PII. PII classification must be aligned with the organisation's data classification scheme. Owner accountability for PII assets must be assigned. + +### Access Control (ISO 27002: 9) +**PIMS guidance:** Access to PII must follow the principle of least privilege. User access rights to PII systems must be reviewed regularly. Privileged access to PII must be strictly controlled and logged. + +### Cryptography (ISO 27002: 10) +**PIMS guidance:** Encryption of PII at rest and in transit is a key privacy-protective measure. Key management procedures must cover PII encryption keys. Anonymisation and pseudonymisation of PII should be considered where appropriate. + +### Physical and Environmental Security (ISO 27002: 11) +**PIMS guidance:** Physical access to areas processing PII must be controlled. Physical media containing PII must be secured. Clear desk / clear screen policies must cover PII documents. + +### Operations Security (ISO 27002: 12) +**PIMS guidance:** Logging and monitoring must capture access to PII to support accountability. Separation of environments must prevent PII from test/development environments unless appropriately anonymised. Backup procedures must address PII protection and retention alignment. + +### Communications Security (ISO 27002: 13) +**PIMS guidance:** Network controls must address segregation of PII processing systems. Information transfer policies must include requirements for PII transfer security. + +### System Acquisition, Development and Maintenance (ISO 27002: 14) +**PIMS guidance:** Privacy by design requirements must be integrated into systems development. PIAs should be embedded into the SDLC at design stage. Test environments must not use live PII unless justified and anonymised. + +### Supplier Relationships (ISO 27002: 15) +**PIMS guidance:** Supplier agreements must include privacy contractual clauses (equivalent to DPA under GDPR). Supplier assessments must include evaluation of privacy practices. Sub-processor chains must be disclosed to the controller. + +### Information Security Incident Management (ISO 27002: 16) +**PIMS guidance:** Privacy incident classification must be defined. Notification timelines for PII breaches must reflect regulatory requirements (e.g., 72-hour notification under GDPR Art. 33). Incidents affecting PII principals must trigger appropriate communication procedures. + +### Business Continuity Management (ISO 27002: 17) +**PIMS guidance:** Business continuity plans must address availability of PII-processing systems. BCP must not compromise PII protection during recovery. Backup media containing PII must be secured during recovery operations. + +### Compliance (ISO 27002: 18) +**PIMS guidance:** Legal and regulatory compliance reviews must include privacy law. PIAs serve as evidence of compliance with Art. 35 DPIA requirements where applicable. Independent reviews of the PIMS should be scheduled as part of the compliance review process. + +--- + +## 10. Relationship to ISO 27001:2022 + +ISO 27701:2019 was written against ISO 27001:2013. Organisations implementing ISO 27001:2022 should: + +1. Apply the Clause 5 extensions to the equivalent ISO 27001:2022 clauses (the numbering and intent are aligned; 2022 added Clauses 6.3 and split 9.2/9.3 but did not remove content) +2. Note that the new ISO 27001:2022 Annex A includes A.5.34 "Privacy and protection of PII" and A.8.11 "Data masking" — these have direct PIMS relevance +3. The 27 controls that were merged or consolidated in the 2022 Annex A transition do not remove any PIMS obligations — Clause 7 and Clause 8 controls are independent of this +4. Anticipate a future revision of ISO 27701 that will align to ISO 27001:2022 and ISO 27002:2022; as of 2024 the 2019 version remains the current published standard diff --git a/plugins/iso27701/skills/iso27701/references/processor-controls.md b/plugins/iso27701/skills/iso27701/references/processor-controls.md new file mode 100644 index 0000000..9899260 --- /dev/null +++ b/plugins/iso27701/skills/iso27701/references/processor-controls.md @@ -0,0 +1,381 @@ +# ISO 27701 — PII Processor Controls (Clause 8) + +All controls in Clause 8 are **normative** for organisations acting as PII Processors. They are additional to the ISO 27001 Annex A and ISO 27002 controls addressed in Clause 6. + +A PII Processor is an entity that processes PII on behalf of and in accordance with the instructions of a PII Controller. + +--- + +## Key Principle for PII Processors + +A PII Processor must not process PII for its own purposes beyond what is documented in the controller's instructions. The processor's role is defined and bounded by the agreement with the controller. Where a processor wishes to use PII for its own purposes (e.g., service improvement, analytics, marketing), it must obtain the controller's authorisation or, where it processes PII collected directly from PII principals, act as a controller for that processing activity. + +--- + +## 8.2 — Conditions for Collection and Processing + +### 8.2.1 — Customer Agreement + +**Objective:** Ensure every processing activity performed for a controller is governed by a binding written agreement. + +**Requirement:** +The organisation shall ensure that processing of PII for each customer (PII Controller) is conducted only on the basis of a written agreement. The agreement must document the instructions under which the processor is permitted to process PII. The processor shall not exceed the instructions given by the controller. + +**Contract provisions a PII Processor must ensure are in place:** +- Subject matter and duration of the processing +- Nature and purpose of the processing +- Type of PII and categories of PII principals +- Obligations and rights of the controller +- Processing limited to documented instructions +- Confidentiality obligation on all staff with access to PII +- Appropriate technical and organisational security measures +- Sub-processor requirements (see 8.5.6) +- Assistance with PII principal rights obligations (see 8.3) +- Deletion or return of PII at contract end +- Provision of evidence of compliance to the controller +- Breach notification to the controller (see 8.5.4) + +**Evidence for audit:** +- Register of all controller customers with contract status +- Sample agreements confirming all required provisions are present +- Evidence that processing does not commence prior to agreement being in place + +**GDPR:** Art. 28 (processor obligations) + +--- + +### 8.2.2 — Organisation's Privacy Practices + +**Objective:** Make the organisation's privacy commitments transparent to the marketplace and to PII Principals where applicable. + +**Requirement:** +The organisation shall make available to its customers (PII Controllers) accurate and up-to-date information about its privacy practices, including its approach to security, sub-processors, and data location. Where the organisation has made public commitments (e.g., in a privacy notice, certification, or published data processing terms), it shall adhere to those commitments. + +**What to implement:** +- Publish a public-facing privacy notice describing the organisation's role as a processor +- Maintain a sub-processor list and make it available to controllers under the agreement +- Publish or provide security commitments (e.g., certifications held, encryption standards, data centre locations) +- Maintain consistency between publicly stated privacy practices and actual practices — inconsistencies constitute non-compliance + +**Evidence for audit:** +- Organisation's public-facing privacy documentation +- Sub-processor list with last review date +- Security commitment documentation / certifications +- Internal review confirming public statements match operational practice + +--- + +### 8.2.3 — Marketing and Advertising + +**Objective:** Prohibit use of PII held on behalf of a controller for the processor's own marketing or advertising purposes without explicit authorisation. + +**Requirement:** +The organisation shall not use PII processed on behalf of PII Controllers for the purpose of marketing or advertising to PII principals, unless this is specifically authorised in the written agreement with the controller. This prohibition extends to using insights derived from controller-held PII to build the organisation's own customer profiles. + +**What to implement:** +- Establish a documented policy prohibiting marketing use of controller PII without written authorisation +- Implement technical controls (access controls, system segregation) that prevent marketing systems from accessing controller PII +- Include marketing prohibition in staff training +- Audit for compliance with this control annually + +**Evidence for audit:** +- Policy document prohibiting marketing use of controller PII +- Technical controls documented preventing cross-contamination of controller and marketing data stores +- Staff training records covering this prohibition +- Audit results confirming compliance + +--- + +### 8.2.4 — Infringing Instruction + +**Objective:** Establish a process for the organisation to identify and escalate when a controller instruction would require the processor to infringe applicable privacy law. + +**Requirement:** +The organisation shall establish a procedure to assess customer instructions before execution. Where an instruction from a PII Controller would require the processor to process PII in a way that infringes applicable privacy law, the processor shall notify the controller, decline to execute the instruction (pending resolution), and document the issue. + +**What to implement:** +- Establish a process for legal or compliance review of new or changed processing instructions +- Define escalation path when an infringing instruction is identified (legal / DPO review; controller notification) +- Include a clause in processor agreements informing the controller that infringements will be notified and not executed +- Maintain a log of infringing instructions received, actions taken, and outcomes + +**Evidence for audit:** +- Infringing instruction procedure document +- Log of assessments conducted on new instructions (including clean assessments and any escalations) +- Sample controller notifications where infringing instructions were identified + +**GDPR:** Art. 29 (processing under authority), Art. 28(3)(h) (processor obligations) + +--- + +### 8.2.5 — Customer Obligations + +**Objective:** Ensure customers (PII Controllers) are made aware of and accept their obligations under the processing relationship. + +**Requirement:** +The organisation shall communicate to its customers the obligations that the controller must fulfil in order for the processor to deliver the service in a legally compliant manner. This includes ensuring the controller has a lawful basis for instructing the processing and that controller-side access is governed appropriately. + +**What to implement:** +- Include controller obligations in the processing agreement (acceptable use clauses, requirement to have lawful basis, notification of changes to processing scope) +- Communicate to controllers what actions are needed from their side to maintain compliance (e.g., keeping processor-side access credentials managed, configuring data minimisation settings in the service) +- Provide documentation (e.g., shared responsibility matrix) clarifying the division of compliance obligations + +**Evidence for audit:** +- Processing agreement sections covering controller obligations +- Shared responsibility documentation +- Customer onboarding or compliance guidance materials + +--- + +## 8.3 — Obligations to PII Principals + +### 8.3.1 — Obligations to PII Principals + +**Objective:** Ensure the organisation supports the controller in fulfilling the privacy rights of PII principals. + +**Requirement:** +The organisation shall assist the PII Controller in fulfilling its obligations to PII principals, including obligations arising from PII principal rights requests. The processor shall not respond directly to PII principal rights requests without the controller's authorisation, but shall cooperate with the controller to enable timely fulfilment. + +**What to implement:** +- Document the procedure for receiving and routing PII principal rights requests that arrive at the processor (rare in B2B context, but possible) +- Implement mechanisms in the service that allow controllers to locate, export, rectify, or delete PII as required to respond to rights requests +- Contractually commit to responding to controller requests for PII principal rights assistance within a defined timeframe (e.g., within 5 business days) +- Log all rights assistance provided to controllers + +**Evidence for audit:** +- Processing agreement provisions covering rights assistance obligations +- Technical capability documentation for PII access, export, rectification, and deletion in the service +- Audit of response times for rights assistance requests +- Log of rights assistance events + +**GDPR:** Art. 28(3)(e) (processor must assist controller with rights obligations) + +--- + +### 8.3.2 — Determine Information for PII Principals + +**Objective:** Provide controllers with the information they need to meet their transparency obligations to PII principals. + +**Requirement:** +The organisation shall provide its customers (PII Controllers) with accurate and complete information about the processor's processing activities, data locations, sub-processors, security measures, and retention so that controllers can fulfil their transparency obligations to PII principals (e.g., completing their own RoPA and privacy notices accurately). + +**What to implement:** +- Provide a data processing information sheet or Data Processing Addendum (DPA) containing all relevant details +- Make information available about the locations where PII is processed and stored +- Maintain an up-to-date list of sub-processors and provide it to controllers on request +- Provide security overview documentation sufficient for controllers to describe measures in their privacy notices + +**Evidence for audit:** +- Standard DPA or data processing information document provided to customers +- Sub-processor list with version history +- Process for notifying controllers of changes to processing locations or sub-processors + +--- + +## 8.4 — Privacy by Design and Privacy by Default + +### 8.4.1 — Limit Processing to Specified Purposes + +**Objective:** Ensure PII processed on behalf of controllers is limited strictly to the purposes specified in the contract. + +**Requirement:** +The organisation shall implement technical and organisational measures to ensure that PII processed on behalf of customers is not processed for purposes not authorised in the customer agreement. This applies to all staff with access to controller PII and to all internal systems that handle that PII. + +**What to implement:** +- Implement role-based access controls restricting access to controller PII to roles with a defined need under the contract +- Segregate controller PII from internal operational data stores +- Log all access to controller PII and review for access outside expected parameters +- Include purpose limitation clauses in staff confidentiality agreements and training +- Conduct periodic access reviews to confirm no unauthorised use of controller PII + +**Evidence for audit:** +- Access control configuration and RBAC model documentation +- Audit log review reports for controller PII access +- Staff training records and acknowledgements covering purpose limitation +- Segregation architecture documentation + +**GDPR:** Art. 29 (processing under controller authority), Art. 5(1)(b) (purpose limitation applies to processor as an obligation) + +--- + +### 8.4.2 — Data Minimisation Objectives for PII Processors + +**Objective:** Apply data minimisation principles to the processing activities the organisation performs on behalf of controllers. + +**Requirement:** +The organisation shall apply data minimisation within the scope of its processor operations. This includes: +- Not collecting or processing more PII than is specified in the controller's instructions +- Deleting or anonymising PII when the stated processing purpose is complete (unless the controller instructs otherwise) +- Implementing pseudonymisation or anonymisation where appropriate given the processing purpose + +**What to implement:** +- Enforce that the service collects and processes only PII fields that are necessary for the contracted processing purpose +- Implement features or defaults that enable controllers to configure the service to collect minimal PII +- Apply automatic deletion / purging timelines within the service that align to controller-defined retention periods +- Document the data minimisation features of the service and communicate them to controllers + +**Evidence for audit:** +- Data minimisation features documented in service specifications +- Service configuration documentation showing default minimal data collection settings +- Automatic deletion feature specifications and test evidence + +--- + +## 8.5 — PII Sharing, Transfer and Disclosure + +### 8.5.1 — Basis for PII Transfer Between Jurisdictions + +**Objective:** Ensure transfers of controller PII between jurisdictions are conducted under lawful transfer mechanisms. + +**Requirement:** +The organisation shall ensure that any transfer of controller PII to a country or international organisation outside the original jurisdiction is conducted under a lawful transfer mechanism, and that this mechanism is documented and disclosed to the controller. + +**What to implement:** +- Document all data centre locations and processing locations where controller PII may reside +- Identify the applicable transfer mechanism for any cross-border processing (e.g., SCCs between the controller and processor, intra-group BCRs, adequacy decisions covering the processing country) +- Include transfer mechanisms in the processing agreement and DPA +- Conduct Transfer Impact Assessments for transfers to non-adequate countries where required + +**Evidence for audit:** +- Data processing agreement with all processing locations listed +- Transfer mechanism documentation (e.g., signed SCCs, BCR binding documents) +- Transfer Impact Assessment records for non-adequate third country processing + +**GDPR:** Art. 44–49 + +--- + +### 8.5.2 — Countries and International Organisations to Which PII Can Be Transferred + +**Objective:** Maintain and disclose an accurate list of all countries and organisations to which controller PII may be transferred. + +**Requirement:** +The organisation shall maintain an accurate list of all countries and international organisations to which controller PII may be transferred (including where sub-processors are located in other countries) and provide this information to controllers on request. The list must be updated when transfer destinations change. + +**Implementation:** +- Maintain a transfer register listing all sub-processor countries and processing data centre locations +- Notify controllers in advance of any changes to transfer destinations (ideally providing the required notice period per contract, e.g., 30 days) +- Ensure the transfer register is reflected in the DPA and updated at each contract renewal + +**Evidence for audit:** +- Transfer register with countries and applicable safeguards per destination +- Notification records for changes to transfer destinations +- Contract provisions specifying the notification requirement + +--- + +### 8.5.3 — Records of PII Disclosures to Third Parties + +**Objective:** Maintain a log of all disclosures of controller PII to third parties not covered by sub-processor agreements. + +**Requirement:** +The organisation shall maintain records of any disclosures of PII it processes on behalf of controllers to third parties outside the sub-processor chain. These records support the controller's accountability obligations and must be available to the controller on request. + +**Records to maintain:** +- Identity of the third party (recipient) +- Categories of controller PII disclosed +- Date and method of disclosure +- Legal basis for the disclosure (e.g., legal obligation, court order) +- Whether and when the controller was notified + +**Evidence for audit:** +- Third-party disclosure log +- Controller notification records for each disclosure +- Process documentation for how disclosure requests are assessed and approved + +--- + +### 8.5.4 — Notification of PII Disclosure Requests to the PII Controller + +**Objective:** Promptly notify the controller when a third party (e.g., law enforcement, government) requests disclosure of controller PII. + +**Requirement:** +Where the organisation receives a request from a third party (including law enforcement, regulatory authority, or court) for access to or disclosure of controller PII, it shall notify the controller as soon as practicable — unless legally prohibited from doing so. The processor shall not disclose PII in response to such a request without first notifying the controller (except where legally prohibited from notification or where notification is waived in the processing agreement). + +**What to implement:** +- Document the procedure for handling government and law enforcement access requests +- Include controller notification as the default response to all such requests +- Where notification is legally prohibited (e.g., a statutory gag order), document the prohibition and the steps taken to contest it where possible +- Report annually (or as required in the agreement) transparency statistics on government access requests (number of requests received, number complied with, types of data involved) +- Include transparency reporting commitments in customer agreements where the controller requires this + +**Evidence for audit:** +- Government / law enforcement access request procedure +- Log of access requests received with notification status +- Transparency report (if published or provided to customers) +- Legal analysis supporting notification prohibition in cases where notification was withheld + +**Note (Cloud providers):** This control is particularly relevant for cloud service providers subject to foreign government access laws (e.g., US CLOUD Act, US FISA). Processors should have conducted a Transfer Impact Assessment addressing government access risk when processing EU/UK controller PII. + +--- + +### 8.5.5 — Legally Binding PII Disclosure Requests + +**Objective:** Establish a process for responding to legally binding requests for PII in a manner that protects PII principals' rights and preserves controller notification. + +**Requirement:** +Where the organisation determines that a disclosure request is legally binding and compliance is required, it shall: +1. Notify the controller before complying (unless legally prohibited) +2. Comply with the request only to the extent legally required +3. Disclose only the minimum PII necessary to satisfy the legal requirement +4. Document the legal basis for disclosure, the PII disclosed, and the recipient + +**Implementation:** +- Engage legal counsel before responding to any compelled disclosure request +- Implement a review process to assess the validity and scope of the request +- Apply data minimisation — do not disclose more than required +- Log all legally compelled disclosures with full details + +**Evidence for audit:** +- Compelled disclosure procedure +- Legal review records for past disclosure requests +- Disclosure log entries for legally compelled disclosures +- Evidence of controller notification (or documented legal prohibition on notification) + +--- + +### 8.5.6 — Disclosure Based on Sub-Processor Contracts + +**Objective:** Ensure that PII shared with sub-processors is governed by binding agreements that impose equivalent obligations to those the processor has with the controller. + +**Requirement:** +The organisation shall not engage sub-processors to process controller PII without the controller's prior written authorisation (general or specific, as agreed in the processing agreement). For each sub-processor engaged, the organisation shall ensure a written agreement is in place that imposes on the sub-processor the same data protection obligations as those in the processor-controller agreement. The organisation remains fully liable to the controller for the compliance of its sub-processors. + +**What to implement:** +- Obtain and document written authorisation from the controller for each sub-processor (or general authorisation with notification mechanism for changes) +- Execute a sub-processor agreement with each sub-processor containing all required provisions +- Conduct due diligence of sub-processors' privacy and security practices before engagement +- Maintain an up-to-date sub-processor list and notify controllers of changes (with the notice period specified in the agreement) +- Include a right to object to new sub-processors in customer agreements +- Monitor sub-processor compliance through contractual audit rights, certifications, or assessments + +**Evidence for audit:** +- Sub-processor register with authorisation status per customer +- Sample sub-processor agreements confirming equivalent obligations +- Sub-processor due diligence records +- Customer notification records for new sub-processor additions +- Sub-processor monitoring schedule and compliance reports + +**GDPR:** Art. 28(2) (sub-processor authorisation), Art. 28(4) (sub-processor obligations) + +--- + +## Clause 8 Summary Table — Quick Reference + +| Control | ID | Applies When | Key Obligation | +|---------|-----|-------------|----------------| +| Customer agreement | 8.2.1 | Always (PII Processor) | Written contract in place before processing; all required provisions included | +| Organisation's privacy practices | 8.2.2 | Always (PII Processor) | Public privacy commitments accurate and consistently applied | +| Marketing and advertising | 8.2.3 | Always | No use of controller PII for own marketing without authorisation | +| Infringing instruction | 8.2.4 | Always | Process for identifying and declining infringing controller instructions | +| Customer obligations | 8.2.5 | Always | Controllers informed of their obligations under the processing relationship | +| Obligations to PII principals | 8.3.1 | Always | Mechanisms to assist controller with PII principal rights fulfilment | +| Determine information for PII principals | 8.3.2 | Always | Provide controllers with processing details needed for transparency | +| Limit processing to specified purposes | 8.4.1 | Always | Technical and organisational controls enforcing purpose limitation | +| Data minimisation objectives | 8.4.2 | Always | Minimisation applied to processor operations; features to support controller minimisation | +| Basis for PII transfer between jurisdictions | 8.5.1 | Cross-border processing | Lawful transfer mechanism documented for each jurisdiction | +| Countries and organisations for transfer | 8.5.2 | Cross-border processing | Up-to-date transfer register; controller notified of changes | +| Records of disclosures to third parties | 8.5.3 | All ad-hoc disclosures | Disclosure log maintained; controller notified | +| Notification of disclosure requests | 8.5.4 | Government/LE access requests | Controller notified before compliance unless legally prohibited | +| Legally binding disclosure requests | 8.5.5 | Compelled disclosures | Legal review; minimum necessary disclosed; controller notified | +| Sub-processor contracts | 8.5.6 | Sub-processors engaged | Controller authorisation; equivalent contractual obligations; sub-processor list maintained | diff --git a/plugins/iso27701/skills/iso27701/references/templates.md b/plugins/iso27701/skills/iso27701/references/templates.md new file mode 100644 index 0000000..56259b7 --- /dev/null +++ b/plugins/iso27701/skills/iso27701/references/templates.md @@ -0,0 +1,684 @@ +# ISO 27701 — Document Templates + +## Template 1: Privacy Policy (External — PII Principals) + +``` +--- +Document: Privacy Notice / Privacy Policy +Version: [X.Y] +Effective Date: [DATE] +Review Date: [DATE] +Owner: [Privacy Officer / DPO Name and Contact] +--- + +# Privacy Notice + +## 1. Who We Are + +[ORGANISATION NAME] ([Trading Name if different]) is a company registered in [JURISDICTION] +with registered number [COMPANY NUMBER]. Our registered address is [ADDRESS]. + +For the purposes of applicable data protection law, [ORGANISATION NAME] is the Data Controller +(PII Controller) for the personal information described in this notice. + +**Contact for privacy matters:** +- Privacy Officer / DPO: [NAME OR TITLE] +- Email: [privacy@organisationname.com] +- Postal address: [ADDRESS] + +--- + +## 2. What Personal Information We Collect + +We collect and process the following categories of personal information: + +| Category | Examples | Source | +|----------|---------|--------| +| Identity data | First name, last name, username | Directly from you | +| Contact data | Email address, telephone number, postal address | Directly from you | +| Account data | Login credentials, preferences, settings | Directly from you | +| Transaction data | Details of products/services purchased, payment history | Directly from you / payment processors | +| Technical data | IP address, browser type, device identifiers, cookies | Automatically collected | +| Marketing preferences | Communication preferences, opt-in/opt-out records | Directly from you | +| [Add as applicable] | | | + +We do not collect special category personal data (health, biometric, racial/ethnic origin, +political opinions, religious beliefs, trade union membership, genetic data, sexual orientation, +criminal records) UNLESS [state exception if applicable and the additional lawful basis]. + +--- + +## 3. Why We Process Your Personal Information and Our Legal Basis + +| Purpose | Legal Basis | Categories of Data Used | +|---------|------------|-------------------------| +| To create and manage your account | Contract (Art. 6(1)(b) GDPR) | Identity, Contact, Account | +| To provide the services you have requested | Contract (Art. 6(1)(b) GDPR) | Identity, Contact, Transaction | +| To process payments | Legal obligation (Art. 6(1)(c)) / Contract | Transaction, Financial | +| To send you marketing communications | Consent (Art. 6(1)(a) GDPR) | Identity, Contact, Marketing preferences | +| To comply with legal obligations | Legal obligation (Art. 6(1)(c) GDPR) | As required by law | +| To improve our products and services | Legitimate interests (Art. 6(1)(f) GDPR) | Technical, Account | +| [Add as applicable] | | | + +Where we rely on legitimate interests, we have conducted a balancing test and determined that +our interests are not overridden by your rights. You may obtain details of this assessment by +contacting us. + +--- + +## 4. Who We Share Your Information With + +We may share your personal information with: + +- **Service providers and processors:** Companies that process data on our behalf under + written data processing agreements (e.g., cloud hosting providers, payment processors, + email delivery platforms) — they are bound to use your data only as we direct. + +- **Professional advisers:** Lawyers, auditors, and insurers who need access in the course + of their professional services. + +- **Regulatory and law enforcement authorities:** Where required by law or in response to + a valid legal request. + +- **Business transfers:** In the event of a merger, acquisition, or sale of assets, your + information may be transferred to the new entity. + +We do not sell your personal information to third parties. + +--- + +## 5. International Transfers + +We may transfer your personal information to countries outside of [YOUR JURISDICTION]. +Where we do so, we ensure an adequate level of protection is in place: + +| Country / Region | Safeguard | +|-----------------|-----------| +| [Country] | [Adequacy decision / Standard Contractual Clauses / BCRs / Other] | + +You may obtain a copy of the relevant safeguards by contacting us at [EMAIL]. + +--- + +## 6. How Long We Keep Your Information + +| Category | Retention Period | Basis for Retention | +|----------|-----------------|---------------------| +| Account data | Duration of account + [X] years | Legal obligation / Contract | +| Transaction data | [X] years from transaction date | Legal obligation (tax / accounting) | +| Marketing preferences | Until opt-out or [X] years of inactivity | Consent / Legitimate interests | +| Legal / compliance records | [X] years | Legal obligation | + +When information is no longer required, we securely delete or anonymise it. + +--- + +## 7. Your Rights + +Under applicable data protection law, you have the following rights: + +| Right | What it means | +|-------|--------------| +| Right of access | Request a copy of the personal information we hold about you | +| Right to rectification | Ask us to correct inaccurate or incomplete information | +| Right to erasure | Ask us to delete your information where you have grounds for this | +| Right to restrict processing | Ask us to restrict how we use your information in certain circumstances | +| Right to data portability | Request your information in a structured, machine-readable format | +| Right to object | Object to processing based on legitimate interests or for direct marketing | +| Right to withdraw consent | Where we rely on consent, withdraw it at any time | +| Rights against automated decisions | Not to be subject to solely automated decisions with significant effects | + +To exercise any of these rights, contact us at [EMAIL]. We will respond within [30 days / +the applicable statutory timeframe]. We may need to verify your identity before processing +your request. + +**Right to complain:** You have the right to complain to the supervisory authority in your +jurisdiction. In the EU/UK: [INSERT RELEVANT DPA — e.g., ICO (ico.org.uk) for UK; your +national DPA within the EU]. Filing a complaint does not prejudice your right to seek a +judicial remedy. + +--- + +## 8. Cookies + +We use cookies and similar technologies on our website. For details of which cookies we use, +their purpose, and how to control them, please see our [Cookie Policy — LINK]. + +--- + +## 9. Changes to This Notice + +We may update this privacy notice from time to time. We will notify you of significant +changes by [EMAIL / WEBSITE NOTICE / OTHER MEANS] and will update the effective date above. +Continued use of our services after the effective date constitutes acknowledgement of the +updated notice. + +--- + +## 10. Contact Us + +For any privacy queries or to exercise your rights: + +[ORGANISATION NAME] +Attention: [Privacy Officer / DPO] +[ADDRESS] +Email: [privacy@organisationname.com] +Telephone: [NUMBER] +``` + +--- + +## Template 2: Internal Privacy and Data Protection Policy + +``` +--- +Document: Privacy and Data Protection Policy +Document ID: POL-PRIV-001 +Version: [X.Y] +Effective Date: [DATE] +Review Date: [DATE — annual review recommended] +Owner: [DPO / Privacy Officer] +Approved By: [CEO / Board / Top Management] +Classification: Internal +--- + +# Privacy and Data Protection Policy + +## 1. Purpose + +This policy establishes [ORGANISATION NAME]'s commitment to protecting the privacy of +individuals whose personal information we process, and sets out the principles, obligations, +and controls that all personnel must apply when handling personal information. + +This policy implements the requirements of ISO/IEC 27701:2019 (Privacy Information Management +System) and supports compliance with applicable privacy and data protection laws, including +[GDPR / UK GDPR / applicable law]. + +## 2. Scope + +This policy applies to: +- All employees, contractors, consultants, and temporary workers +- All processing of personal information (PII) across all systems, processes, and locations + within the scope of our Privacy Information Management System (PIMS) +- All categories of individuals whose PII we process (customers, employees, job applicants, + suppliers, website visitors, etc.) + +## 3. Privacy Principles + +All personnel must apply the following principles when processing personal information: + +1. **Lawfulness, fairness and transparency:** Process PII only on a valid legal basis, fairly, + and in a transparent way. +2. **Purpose limitation:** Collect PII for specific, explicit, and legitimate purposes. Do not + use PII for purposes not communicated at collection. +3. **Data minimisation:** Collect and process only the minimum PII necessary for the purpose. +4. **Accuracy:** Keep PII accurate and up-to-date. Promptly correct or delete inaccurate data. +5. **Storage limitation:** Do not retain PII longer than necessary. Follow the retention + schedule and delete PII when its retention period expires. +6. **Integrity and confidentiality:** Protect PII against unauthorised access, loss, + destruction, or disclosure through appropriate security measures. +7. **Accountability:** Be able to demonstrate compliance with these principles. Document + processing activities, decisions, and controls. + +## 4. Roles and Responsibilities + +| Role | Responsibilities | +|------|----------------| +| CEO / Board | Ultimate accountability for privacy; appoint DPO where required; approve privacy policy | +| DPO / Privacy Officer | Day-to-day PIMS management; privacy advice; monitor compliance; liaise with supervisory authorities; manage PIA programme | +| Data / PII Stewards (Business Owners) | Accountable for specific processing activities in their area; maintain accuracy of RoPA entries; sponsor PIAs | +| All Personnel | Comply with this policy; complete privacy training; report privacy incidents; route data subject requests to [privacy@org] | +| IT / Engineering | Implement privacy by design; maintain security controls; support data subject rights fulfilment; manage data retention in systems | +| Legal | Review processing agreements; advise on lawful basis and cross-border transfers | +| HR | Manage employee PII per policy; maintain records for employment law compliance periods | + +## 5. Key Obligations + +### 5.1 Before Starting New Processing +- Document the processing purpose and lawful basis in the RoPA before collection commences +- Conduct a Privacy Impact Assessment (PIA) if the processing meets any trigger criteria +- Ensure a privacy notice is in place covering the new processing + +### 5.2 Collecting Personal Information +- Only collect PII that is necessary for the documented purpose +- Provide a privacy notice at or before the point of collection +- Obtain consent before collecting PII where consent is the lawful basis +- Record the consent with sufficient detail to demonstrate it was validly given + +### 5.3 Handling Personal Information +- Access only PII required for your role +- Do not share PII with colleagues who do not need it for their role +- Do not take PII outside of authorised systems or locations without approval +- Do not use PII for purposes other than those disclosed to individuals + +### 5.4 Sharing Personal Information with Third Parties +- Do not share PII with third parties without checking with the Privacy Officer +- All processors engaged by the organisation must have a signed Data Processing Agreement +- Do not respond directly to law enforcement requests for PII — escalate to the Privacy Officer + +### 5.5 Data Subject Rights Requests +- Route any request from an individual to access, rectify, erase, or object to use of their + data to: [privacy@organisation.com] or the Privacy Officer +- Do not attempt to process a rights request yourself +- Note the date the request was received and forward to the Privacy Officer the same day + +### 5.6 Privacy Incidents +- Immediately report any suspected privacy incident to the Privacy Officer: + - Lost or stolen device containing PII + - Accidental email of PII to wrong recipient + - Discovered unauthorised access to PII systems + - Ransomware or malware affecting systems with PII +- Use the incident report form: [LINK / LOCATION] +- Do not delete or alter records related to a suspected incident + +## 6. Privacy Impact Assessments + +A PIA must be conducted before: +- Launching a new product, service, or process that involves PII +- Significantly changing an existing processing activity +- Implementing a new system that will store or process PII +- Starting to collect new categories of PII or processing for a new purpose + +PIA procedure: [LINK / LOCATION] + +## 7. Retention and Deletion + +PII must be retained in accordance with the [Retention Schedule — LINK / LOCATION] and +deleted or anonymised when the retention period expires. Do not retain PII beyond its +retention period without explicit approval from the Privacy Officer. + +## 8. Non-Compliance + +Failure to comply with this policy may result in: +- Regulatory action and fines against the organisation +- Disciplinary action, up to and including dismissal +- Personal liability in cases of deliberate or serious breach + +## 9. Training + +All personnel who process PII must complete privacy awareness training within [30 days] +of joining the organisation and annually thereafter. Role-specific privacy training +requirements are defined in the Privacy Training Matrix [LINK / LOCATION]. + +## 10. Policy Review + +This policy is reviewed annually by the Privacy Officer and approved by top management. +Significant changes to applicable law, the organisation's processing activities, or the +PIMS scope may trigger an interim review. + +--- +Review history: +| Version | Date | Author | Changes | +|---------|------|--------|---------| +| 1.0 | [DATE] | [NAME] | Initial version | +``` + +--- + +## Template 3: Records of Processing Activities (RoPA) + +``` +--- +Document: Records of Processing Activities (RoPA) +Document ID: REG-PRIV-001 +Version: [X.Y] +Last Updated: [DATE] +Owner: DPO / Privacy Officer +Classification: Confidential — Internal +ISO 27701 Reference: Clause 7.2.8 +GDPR Reference: Article 30 +--- + +# Records of Processing Activities + +## Controller Details +- Controller name: [ORGANISATION NAME] +- Registered address: [ADDRESS] +- DPO / Privacy contact: [NAME, EMAIL] + +--- + +## Processing Activity Register + +### Processing Activity 1: [Activity Name — e.g., Customer Account Management] + +| Field | Detail | +|-------|--------| +| Activity ID | PA-001 | +| Processing activity name | Customer Account Management | +| Business function / owner | [Department / Role] | +| Date created | [DATE] | +| Date last reviewed | [DATE] | +| **Purposes of processing** | Create and manage customer accounts; enable login and service access | +| **Lawful basis** | Contract — Art. 6(1)(b) GDPR | +| **Categories of PII principals** | Customers / registered users | +| **Categories of PII** | Name, email address, username, hashed password, account preferences | +| **Special category PII?** | No | +| **PII sources** | Directly from the data subject at registration | +| **Recipients (internal)** | Customer Support, IT Operations | +| **Recipients (external / processors)** | [Cloud hosting provider name] — Data Processing Agreement in place | +| **Third country transfers?** | [Yes/No] — If yes: [Country; Safeguard: SCCs / adequacy decision] | +| **Retention period** | Duration of account + 7 years post-closure (tax obligations) | +| **Deletion / anonymisation method** | Secure deletion via [system/procedure] | +| **Security measures** | AES-256 encryption at rest; TLS 1.3 in transit; role-based access control; audit logging enabled | +| **PIA conducted?** | [Yes — PIA-001 dated DATE / No — threshold not met per screening] | +| **Notes** | [Any relevant notes] | + +--- + +### Processing Activity 2: [Activity Name — e.g., Marketing Email Campaigns] + +| Field | Detail | +|-------|--------| +| Activity ID | PA-002 | +| Processing activity name | Marketing Email Campaigns | +| Business function / owner | Marketing | +| **Purposes of processing** | Send promotional emails and newsletters to opted-in subscribers | +| **Lawful basis** | Consent — Art. 6(1)(a) GDPR | +| **Categories of PII principals** | Opted-in customers and prospects | +| **Categories of PII** | Name, email address, marketing preferences, engagement history | +| **Special category PII?** | No | +| **PII sources** | Directly from subject via opt-in form / account preference centre | +| **Recipients (external / processors)** | [Email platform name] — DPA in place | +| **Third country transfers?** | Yes — USA; Safeguard: Standard Contractual Clauses (2021 EU SCCs) | +| **Retention period** | Until consent withdrawn; or 2 years of inactivity (whichever first); then deleted | +| **Security measures** | [Reference to security controls] | +| **PIA conducted?** | No — threshold screening negative | + +[Continue for all processing activities] + +--- + +## Processor RoPA (if also acting as a PII Processor) + +Where acting as a processor on behalf of controllers, maintain a separate processor RoPA per Art. 30(2): + +| Field | Detail | +|-------|--------| +| Controller name | [Controller / Customer Organisation Name] | +| Controller contact | [Contact details] | +| Processing category | [e.g., Cloud Storage, HR Outsourcing, Payroll Processing] | +| Processing location(s) | [Countries where data is stored/processed] | +| Transfer safeguard | [Mechanism used for any third country processing] | +| Security measures | [Summary reference] | +``` + +--- + +## Template 4: Privacy Impact Assessment (PIA / DPIA) + +``` +--- +Document: Privacy Impact Assessment +PIA Reference: PIA-[YEAR]-[NUMBER] +System / Process: [Name] +Initiating Business Owner: [Name / Role] +Privacy Officer Review: [Name] +Date Initiated: [DATE] +Date Completed: [DATE] +Status: [Draft / Under Review / Final / Approved] +ISO 27701 Reference: Clause 7.2.5 +GDPR Reference: Article 35–36 +--- + +# Privacy Impact Assessment + +## Section 1 — Screening (Threshold Assessment) + +Has the processing triggered one or more mandatory PIA criteria? + +- [ ] New processing involving systematic/extensive profiling with significant effects +- [ ] New/changed large-scale processing of special category PII +- [ ] Systematic monitoring of publicly accessible areas at large scale +- [ ] New technology with PII implications not previously assessed +- [ ] Inverted access decisions (decisions preventing individuals from obtaining services) +- [ ] Other high-risk criterion identified: [DESCRIBE] +- [x] None of the above — full PIA not mandatory, but precautionary review conducted + +**Screening outcome:** Full PIA required / Not required (document reason) / Precautionary PIA + +--- + +## Section 2 — Description of Processing + +| Item | Detail | +|------|--------| +| System / process name | [NAME] | +| Brief description | [What the system/process does in plain language] | +| Purpose(s) of processing | [List each specific purpose] | +| Categories of PII processed | [List data categories] | +| Special category PII? | Yes / No — If yes: [categories and additional lawful basis] | +| Volume of PII principals affected | [Approximate number or range: e.g., ~10,000 customers] | +| PII sources | [Direct collection / third party / publicly available] | +| Who has access | [Roles and teams] | +| Systems and locations | [Systems, data stores, cloud regions involved] | +| Third party processors involved | [Names and contracts status] | +| Third country transfers | [Yes/No — if yes: countries and safeguard] | +| Retention period | [Stated retention per PII category] | + +--- + +## Section 3 — Necessity and Proportionality + +| Question | Assessment | +|----------|-----------| +| Is each PII category strictly necessary for the stated purpose? | [Assess each category — justify or flag for removal] | +| Is the processing proportionate to the benefit sought? | [Yes/No — reasoning] | +| Could the purpose be achieved with less PII or pseudonymised data? | [Yes/No — reasoning] | +| Is the proposed retention period the minimum needed? | [Yes/No — reasoning] | +| What is the lawful basis for processing? | [State basis and confirm it has been documented in RoPA] | +| Where consent is the basis: does the consent design meet requirements? | [Yes/No / N/A] | + +--- + +## Section 4 — Privacy Risk Assessment + +Likelihood scale: 1 = Very unlikely, 2 = Unlikely, 3 = Possible, 4 = Likely, 5 = Very likely +Severity scale: 1 = Negligible impact, 2 = Low impact, 3 = Moderate harm, 4 = Significant harm, 5 = Severe harm + +| # | Risk Description | Likelihood | Severity | Risk Score | Proposed Treatment | +|---|-----------------|-----------|---------|------------|-------------------| +| 1 | Unauthorised access to PII by internal actors | | | | Access control, RBAC, audit logging | +| 2 | Unauthorised access by external attackers | | | | Encryption, firewall, pen testing | +| 3 | Accidental disclosure to wrong recipient | | | | Email security controls, DLP | +| 4 | Inaccurate PII leading to adverse outcome for individual | | | | Data quality controls, rectification mechanism | +| 5 | Excessive PII collection beyond stated purpose | | | | Data minimisation review, PbD in design | +| 6 | Retention beyond stated period | | | | Automated retention enforcement | +| 7 | PII used for undisclosed secondary purpose | | | | Purpose limitation controls, access control | +| 8 | Sub-processor breach or non-compliance | | | | Sub-processor due diligence, contract terms | +| 9 | Cross-border transfer without lawful mechanism | | | | Transfer impact assessment, SCCs | +| 10 | Failure to fulfil PII principal rights within deadline | | | | Rights fulfilment procedure, dedicated mailbox | +| 11 | [Add specific risks for this processing] | | | | | + +Risk score thresholds: 1–4 = Low, 5–9 = Medium, 10–14 = High, 15–25 = Critical + +--- + +## Section 5 — Privacy Measures Selected + +| Measure | Type | Control Reference | Responsible | Target Date | +|---------|------|-----------------|-------------|-------------| +| Role-based access control limiting PII access to [roles] | Technical | ISO 27001 A.9.1 | IT | [DATE] | +| Encryption of PII at rest (AES-256) and in transit (TLS 1.3) | Technical | ISO 27001 A.10.1 | IT | [DATE] | +| Automated retention enforcement for [PII category] | Technical | ISO 27701 7.4.7 | IT | [DATE] | +| PII fields reviewed and reduced from [X] to [Y] fields | Design | ISO 27701 7.4.1 | Product | [DATE] | +| Privacy notice updated to reflect new processing | Procedural | ISO 27701 7.3.3 | Privacy Officer | [DATE] | +| DPA executed with [processor name] | Legal | ISO 27701 7.2.6 | Legal | [DATE] | +| [Add measures specific to this PIA] | | | | | + +--- + +## Section 6 — PII Principal Rights + +Confirm mechanisms are in place for all applicable rights: + +- [ ] Right of access — SAR procedure in place; mailbox monitored; response within 30 days +- [ ] Right to rectification — inaccuracy correction procedure in place +- [ ] Right to erasure — deletion capability confirmed; exception handling documented +- [ ] Right to withdraw consent — withdrawal mechanism in product; confirmed as easy as giving consent +- [ ] Right to object — objection handling procedure; direct marketing opt-out active +- [ ] Right to data portability — machine-readable export available [if applicable] +- [ ] Rights against automated decisions — human review escalation [if applicable] + +--- + +## Section 7 — Residual Risk and Outcome + +| Item | Detail | +|------|--------| +| Overall residual risk level after treatment | [Low / Medium / High / Critical] | +| Can processing proceed? | [Yes / Yes with conditions / No — redesign required] | +| Conditions / outstanding actions | [List any conditions or actions required before go-live] | +| Supervisory authority consultation required? | [Yes — must consult before processing commences / No] | +| DPO / Privacy Officer consultation | [Name and date consulted] | +| Approved by | [Name, Role, Date] | + +--- + +## Section 8 — Review and Update Log + +| Date | Reviewed By | Changes Made | Next Review | +|------|-------------|-------------|-------------| +| [DATE] | [NAME] | Initial PIA | [DATE — at least upon significant change] | +``` + +--- + +## Template 5: Consent Record + +``` +--- +System: [System / Platform Name] +Form Version: [VERSION] +ISO 27701 Reference: Clause 7.2.4 +GDPR Reference: Article 7(1) +--- + +# Consent Record + +## What to record at the time consent is obtained: + +| Field | Example Value | Notes | +|-------|--------------|-------| +| PII Principal identifier | user_id: 12345 (do not store name alongside ID where avoidable) | Pseudonymous ID preferred | +| Consent event timestamp | 2025-03-15T14:32:11Z | ISO 8601 UTC format | +| Consent given | TRUE | Boolean | +| Consent purposes consented to | ["marketing_email", "product_updates"] | Granular per purpose | +| Consent version / notice version | privacy_notice_v3.2 | Must match the notice presented | +| Collection method | Web form — account registration page | Identifies where and how | +| IP address at time of consent | [HASH or truncated — not full IP for minimisation] | Consider minimisation | +| Withdrawal timestamp | NULL (not withdrawn) | Populated on withdrawal | +| Withdrawal method | NULL | "account_settings" / "unsubscribe_link" / etc. | + +## Consent Record Retention +Consent records must be retained for the duration of the processing relationship +plus [X] years after withdrawal or end of relationship to demonstrate consent was +valid at the time of processing. +``` + +--- + +## Template 6: PII Principal Rights Request Log + +``` +--- +Register: Data Subject / PII Principal Rights Request Log +Owner: Privacy Officer / DPO +ISO 27701 Reference: Clause 7.3.1–7.3.7 +GDPR Reference: Article 12, 15–22 +--- + +# Rights Request Log + +| Request Ref | Date Received | Requestor Type | Right Requested | Request Channel | Identity Verified (Y/N/Method) | Response Date | Status | Outcome | Extension Granted? | Notes | +|------------|--------------|----------------|----------------|----------------|-------------------------------|--------------|--------|---------|-------------------|-------| +| RR-2025-001 | 2025-01-10 | Customer | Right of Access | Email | Yes — support ticket verification | 2025-02-05 | Closed | Full disclosure provided | No | | +| RR-2025-002 | 2025-01-18 | Employee | Erasure | In-person HR | Yes — employee ID | 2025-02-10 | Closed | Partial erasure — legal hold applied to payroll records | No | Payroll retention — 7 year legal hold | +| RR-2025-003 | 2025-02-01 | Customer | Rectification | Online form | Yes — email verification | 2025-02-08 | Closed | Email address updated; downstream processors notified | No | | + +Response deadline reminders: +- Standard: 30 calendar days from verified receipt of request (GDPR Art. 12(3)) +- Extension: 60 additional days for complex/numerous requests — notify requestor within first 30 days +- Manifestly unfounded or excessive requests: may charge reasonable fee or decline — document decision +``` + +--- + +## Template 7: Privacy Incident Report + +``` +--- +Incident Reference: INC-PRIV-[YEAR]-[NUMBER] +Date Detected: [DATE] +Reported By: [Name / Role] +Privacy Officer Assigned: [Name] +ISO 27701 Reference: Clause 5.8 +GDPR Reference: Article 33–34 +--- + +# Privacy Incident Report + +## Section 1 — Incident Overview + +| Field | Detail | +|-------|--------| +| Incident type | [Unauthorised access / Accidental disclosure / Data loss / Ransomware / Theft / Insider misuse / Other] | +| Date/time detected | [DATE TIME] | +| Date/time incident occurred (if known) | [DATE TIME / Unknown] | +| Reported by | [Name and contact] | +| Brief description | [What happened — factual only] | +| Systems / departments affected | [List] | + +## Section 2 — PII Impact Assessment + +| Item | Detail | +|------|--------| +| PII involved? | Yes / No / Under investigation | +| Categories of PII affected | [e.g., Name, email, health data] | +| Special category PII affected? | Yes / No | +| Volume of PII principals affected (estimated) | [Number or range] | +| Nature of impact | Confidentiality breach / Integrity breach / Availability breach | +| Severity assessment (1-5) | [1=Negligible ... 5=Severe with likely significant harm] | + +## Section 3 — Containment and Response + +| Action | Owner | Completion Date | +|--------|-------|----------------| +| Incident contained | | | +| Affected systems isolated / secured | | | +| Evidence preserved | | | +| Forensic review initiated (if required) | | | +| Affected individuals identified | | | + +## Section 4 — Notification Assessment + +### Supervisory Authority Notification +|- Notification required (risk to rights and freedoms of individuals)? | Yes / No / Under assessment | +|- 72-hour deadline from awareness: | [DATE TIME — GDPR Art. 33(1)] | +|- Notification submitted: | [DATE TIME] / [Not required — reasoning below] | +|- Supervisory authority reference: | [SA reference number] | + +### Affected Individual Notification +|- High risk to individuals requiring direct notification? | Yes / No / Under assessment | +|- Notification method and timeline: | [Channel and date] — GDPR Art. 34(1) | + +## Section 5 — Root Cause and Corrective Action + +| Root cause | [Describe root cause once investigation complete] | +|------------|--------------------------------------------------| +| Contributing factors | [Systems, process, human error, third party, etc.] | + +| Corrective Action | Owner | Due Date | Completed | +|------------------|-------|----------|-----------| +| [Action 1] | | | | +| [Action 2] | | | | + +## Section 6 — Incident Close-out + +| Item | Detail | +|------|--------| +| Incident closure date | [DATE] | +| Closed by | [Privacy Officer name] | +| Lessons learned | [Summary for PIMS improvement] | +| Reported in management review? | Yes / No | +``` 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/iso42001/.claude-plugin/plugin.json b/plugins/iso42001/.claude-plugin/plugin.json index a6f5bd3..6c4e67d 100644 --- a/plugins/iso42001/.claude-plugin/plugin.json +++ b/plugins/iso42001/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "iso42001", - "description": "ISO 42001 AI Management System (AIMS) advisor \u2014 gap analysis, AI risk assessment, AI system impact assessment (AISIA), Annex A control guidance, SoA generation, policy writing, and certification readiness for ISO/IEC 42001:2023.", - "version": "0.3.0", + "description": "ISO 42001 AI Management System (AIMS) advisor — gap analysis, AI risk and impact assessment (AISIA), all 38 Annex A controls, EU AI Act mapping, SoA generation, policy drafting, document templates, and certification readiness for ISO/IEC 42001:2023.", + "version": "1.0.0", "author": { "name": "Hemant Naik", "email": "hemant.naik@gmail.com" @@ -17,6 +17,7 @@ "ai-governance", "ai-risk", "aisia", + "eu-ai-act", "grc" ] -} \ No newline at end of file +} diff --git a/plugins/iso42001/skills/iso42001/SKILL.md b/plugins/iso42001/skills/iso42001/SKILL.md index a26ee76..e234c39 100644 --- a/plugins/iso42001/skills/iso42001/SKILL.md +++ b/plugins/iso42001/skills/iso42001/SKILL.md @@ -5,11 +5,13 @@ description: > a user asks about ISO/IEC 42001:2023, AI governance, AI management systems, AI risk assessment, AI system impact assessment, Annex A controls for AI, Statement of Applicability for AI systems, AI policy, responsible AI, AI lifecycle management, AI incident management, - AI transparency, AI bias, AI certification readiness, or any topic related to implementing - or auditing an AI Management System. Also trigger for questions like "how do I become ISO - 42001 certified?", "what controls does ISO 42001 require?", "how do I assess AI risk under - 42001?", "what is an AIMS?", or any request involving organisational governance of AI systems, - responsible AI frameworks, or AI regulatory compliance aligned to an ISO standard. + AI transparency, AI bias, AI certification readiness, EU AI Act alignment to ISO 42001, + FRIA and AISIA crosswalk, Annex B implementation guidance, Annex C responsible AI objectives, + or any topic related to implementing or auditing an AI Management System. Also trigger for + questions like "how do I become ISO 42001 certified?", "what controls does ISO 42001 require?", + "how do I assess AI risk under 42001?", "what is an AIMS?", "how does ISO 42001 help with EU + AI Act?", or any request involving organisational governance of AI systems, responsible AI + frameworks, or AI regulatory compliance aligned to an ISO standard. --- # ISO 42001 AI Management System (AIMS) Skill @@ -25,7 +27,7 @@ Always clarify the organisation's role if not stated — **AI provider** (develo Match your output to the task type: | Task | Output Format | -|------|--------------| +|------|---------------| | Gap analysis | Table: Clause/Control ID \| Requirement \| Status 🔴/🟡/🟢 \| Evidence Needed \| Gap Notes | | AIMS scope definition | Structured narrative: boundaries, AI systems in scope, roles | | AI risk/impact assessment | Risk register table or structured narrative with likelihood × severity | @@ -33,6 +35,8 @@ Match your output to the task type: | Control implementation guidance | Purpose → Requirements → Implementation Steps → Evidence → Audit Tips | | SoA for AI | Table: Control ID \| Control Name \| Applicable? \| Justification \| Implementation Status | | Certification readiness | Stage 1 / Stage 2 checklist with RAG status | +| EU AI Act alignment | Mapping table: EU AI Act Article \| Requirement \| ISO 42001 Clause/Control \| Gap | +| Document templating | Use `references/iso42001-templates.md` as the authoritative source | | General question | Clear, concise prose with clause/control citations | Always cite the specific clause or Annex A control (e.g., Clause 6.1.2, A.4.3) in all outputs. @@ -41,41 +45,76 @@ Always cite the specific clause or Annex A control (e.g., Clause 6.1.2, A.4.3) i ## Standard Overview -**ISO/IEC 42001:2023** was published on **18 December 2023** — the world's first international standard for AI Management Systems. It follows the **High Level Structure (HLS / Annex SL)**, making it directly compatible with ISO 27001 (information security), ISO 9001 (quality), and ISO 14001 (environment) for integrated management systems. +**ISO/IEC 42001:2023** was published on **18 December 2023** by the International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC). It is the world's first international standard for AI Management Systems. The standard follows the **High Level Structure (HLS / Annex SL)**, making it directly compatible with ISO 27001, ISO 9001, and ISO 14001 for integrated management systems. + +### Publication and Ownership +- **Published:** 18 December 2023 +- **Standard number:** ISO/IEC 42001:2023 +- **Full title:** Information technology — Artificial intelligence — Management system +- **Technical committee:** ISO/IEC JTC 1/SC 42 (Artificial Intelligence) +- **Pages:** Approximately 50 pages core text + annexes ### Who It Applies To - **AI providers**: organisations that develop, train, deploy, or maintain AI systems for others or for internal use - **AI users**: organisations that integrate or use AI systems developed by third parties - **Any size**: scalable for startups through enterprises; sector-agnostic +### Document Structure + +| Section | Type | Content | +|---------|------|----------| +| Clauses 1–3 | Non-normative | Introduction, normative references, terms and definitions | +| Clauses 4–10 | **Normative** | Mandatory AIMS requirements (Plan-Do-Check-Act) | +| Annex A | **Normative** | 38 controls across 9 domains — forms the basis for the SoA | +| Annex B | Informative | Implementation guidance for each Annex A control | +| Annex C | Informative | Objectives for an AI management system (responsible AI attributes) | + +### Annex C — Responsible AI Objectives +Annex C identifies seven responsible AI attributes that AI management system objectives should address: + +| Attribute | Description | +|-----------|-------------| +| Human agency and oversight | AI systems should support human decision-making and allow human intervention | +| Technical robustness and safety | AI systems should be accurate, reliable, secure, and fail safely | +| Privacy and data governance | AI systems must protect personal data and respect data governance principles | +| Transparency | AI systems' capabilities, limitations, and decision logic should be understandable | +| Diversity, non-discrimination and fairness | AI systems must not discriminate or produce unfair outcomes for protected groups | +| Societal and environmental wellbeing | AI systems should benefit society and minimise negative environmental impacts | +| Accountability | Organisations must be accountable for their AI systems and their impacts | + +These attributes align with the OECD AI Principles (2019) and the EU High-Level Expert Group on AI Ethics guidelines, and inform how AI objectives under Clause 6.2 should be framed. + ### Key Unique Elements vs Other ISO Standards | Element | ISO 42001 Specific | -|---------|-------------------| -| AI system impact assessment (AISIA) | Required — assess societal and individual impacts | +|---------|---------| +| AI system impact assessment (AISIA) | Required — assess societal and individual impacts per Clause 6.1.2 | | AI risk assessment | Separate from general organisational risk — AI-specific likelihood × severity | -| AI objectives | Must be measurable and linked to responsible AI principles | -| Intended purpose | Must be documented for each AI system in scope | -| Human oversight | Controls required for all AI decision-making affecting individuals | -| Data quality | Specific controls for training, validation, test data quality | -| Transparency | Disclosure obligations tied to AI system impact level | +| AI objectives (Clause 6.2) | Must be measurable and linked to Annex C responsible AI attributes | +| Intended purpose | Must be documented for each AI system in scope (A.5.1) | +| Human oversight | Controls required for AI decision-making affecting individuals | +| Data quality (Annex A.7) | Specific controls for training, validation, and test data quality | +| Transparency (A.8.1) | Disclosure obligations proportionate to AI system impact level | +| Decommissioning (A.10) | Controls for retiring AI systems, data disposal, and model archival | --- ## Clause Structure (Mandatory — Clauses 4–10) | Clause | Title | Key Deliverables | -|--------|-------|-----------------| +|--------|-------|------------------| | 4 | Context of the Organisation | AIMS scope document, stakeholder register, interested party needs, AI system register | | 5 | Leadership | AI policy (signed by top management), roles and responsibilities (RACI), management commitment evidence | -| 6 | Planning | AI risk assessment, AI system impact assessment (AISIA), AIMS objectives, plan to achieve objectives | +| 6 | Planning | AI risk assessment, AI system impact assessment (AISIA), AIMS objectives, plan to achieve objectives, Statement of Applicability | | 7 | Support | Competence records, awareness programme, communication plan, documented information procedure | | 8 | Operation | Executed AI risk assessments, AI system lifecycle controls, supplier AI assessments, incident records | | 9 | Performance Evaluation | Internal audit programme, audit reports, management review minutes, metrics/KPIs | | 10 | Improvement | Nonconformity log, corrective action records, continual improvement register | -For full Annex A controls → read `references/iso42001-controls-annex-a.md` -For detailed clause requirements → read `references/iso42001-clauses-requirements.md` -For AI risk and impact assessment methodology → read `references/iso42001-ai-risk-assessment.md` +For full Annex A controls → read `references/iso42001-controls-annex-a.md` +For detailed clause requirements → read `references/iso42001-clauses-requirements.md` +For AI risk and impact assessment methodology → read `references/iso42001-ai-risk-assessment.md` +For document templates → read `references/iso42001-templates.md` +For EU AI Act alignment → read `references/iso42001-eu-ai-act-mapping.md` --- @@ -87,8 +126,8 @@ For AI risk and impact assessment methodology → read `references/iso42001-ai-r **Process:** 1. Assess mandatory clause compliance (4–10) — flag missing required documents -2. Assess Annex A control applicability and implementation status -3. Identify SoA gaps (controls applicable but not yet implemented) +2. Assess Annex A control applicability and implementation status based on organisational role +3. Identify SoA gaps (controls applicable but not yet implemented or only partially) 4. Produce prioritised remediation roadmap (30/60/90 days + strategic) **Output format:** @@ -96,72 +135,75 @@ For AI risk and impact assessment methodology → read `references/iso42001-ai-r CLAUSE/CONTROL | REQUIREMENT | STATUS | EVIDENCE NEEDED | GAP/ACTION 4.1 | Context documented | 🔴 Not started | AIMS Scope doc | Define AI system boundary and organisational context 6.1.2 | AI risk assessment | 🟡 Partial | Risk register | Expand to cover all in-scope AI systems -A.5.1 | AI policy | 🟢 Implemented | Signed policy doc | Review against 42001 requirements +A.5.1 | AI system specifications | 🟢 Implemented | Specification docs | Review against 42001 requirements ``` ### 2. AI System Impact Assessment (AISIA) -The AISIA is a **mandatory** process under Clause 6.1.2. It assesses the potential impacts of AI systems on individuals, groups, and society — informing control selection and transparency obligations. +The AISIA is a **mandatory** process under Clause 6.1.2, supported by Annex A controls A.6.1, A.6.2, and A.6.3. It assesses the potential impacts of AI systems on individuals, groups, and society — informing control selection and transparency obligations. **AISIA dimensions to assess:** -- **Intended purpose**: what the AI system is designed to do +- **Intended purpose**: what the AI system is designed to do (A.5.1) - **Output type**: decision support / autonomous decision / content generation / classification / prediction / recommendation - **Impact domain**: employment, healthcare, financial services, law enforcement, education, public safety, other -- **Affected population**: scale, vulnerability of individuals impacted +- **Affected population**: scale, vulnerability of individuals impacted (A.6.2) - **Severity**: consequence if AI system fails, produces bias, or is misused - **Reversibility**: can harms be corrected? -- **Human oversight available**: is a human in the loop? +- **Human oversight available**: is a human meaningfully in the loop? (Annex C) +- **Societal concerns**: misinformation, environmental, labour displacement (A.6.3) **AISIA impact classification:** | Level | Description | Control implication | -|-------|-------------|-------------------| +|-------|-------------|---------------------| | Low | Limited, easily reversible impact on non-vulnerable individuals | Standard controls apply | | Medium | Moderate impact, partially reversible, some vulnerable individuals | Enhanced transparency + human oversight | -| High | Significant, hard-to-reverse impact on vulnerable individuals or society | Maximum controls — ADR, human review mandatory, high disclosure | +| High | Significant, hard-to-reverse impact on vulnerable individuals or society | Maximum controls — ADR, human review mandatory, full disclosure | ### 3. AI Risk Assessment -Separate from the AISIA (which is impact-focused), the AI risk assessment evaluates **likelihood × severity** of risks specific to AI systems: +Separate from the AISIA (which is impact-focused), the AI risk assessment evaluates **likelihood × severity** of risks specific to AI systems. Both assessments are mandatory under Clause 6.1.2. **Risk categories to address:** -- **Model risks**: bias, unfairness, hallucination, model drift, adversarial attacks -- **Data risks**: training data quality, data poisoning, privacy violations in training data -- **Operational risks**: system failure, unexpected outputs, scope creep -- **Supply chain risks**: third-party AI model risks, API dependency, provider lock-in -- **Societal risks**: discriminatory outcomes, erosion of human autonomy, misinformation +- **Model risks**: bias, unfairness, hallucination, model drift, adversarial attacks, overfitting +- **Data risks**: training data quality, data poisoning, privacy violations, representativeness gaps +- **Operational risks**: system failure, unexpected outputs, scope creep, human over-reliance +- **Supply chain risks**: third-party AI model risks, API dependency, vendor lock-in +- **Regulatory/reputational risks**: non-compliance with AI law, media exposure, legal liability **Risk treatment options (aligned to Clause 6.1.3):** -- Modify the AI system (retrain, add guardrails, change architecture) -- Accept with monitoring (continuous monitoring + defined thresholds) +- Modify the AI system (retrain, add guardrails, change architecture, implement bias mitigation) +- Accept with monitoring (continuous monitoring + defined alert thresholds + documented rationale) - Avoid (do not deploy the AI system for this use case) -- Transfer (contractual obligations to AI provider via Annex A.9 controls) +- Transfer (contractual obligations to AI provider — Annex A.9.2) + +For full scoring methodology and AISIA process → read `references/iso42001-ai-risk-assessment.md` ### 4. Statement of Applicability (SoA) for AI -Generate a SoA table covering all 38 Annex A controls: +The SoA is a required output of Clause 6.1.3 risk treatment planning. It covers all 38 Annex A controls. **SoA format:** ``` Control ID | Control Name | Applicable? | Justification | Implementation Status | Evidence Reference -A.4.1 | Policies for AI systems | Yes | Required for all AIMS | Implemented | AI-POL-001 -A.5.1 | Resources for AI systems | Yes | Provider role | In progress | N/A -A.6.1 | Processes for responsible AI | Yes | Provider role | Planned | N/A +A.4.1 | Policies for AI system resources | Yes | Provider role: compute policies needed | Implemented | AI-POL-002 +A.5.1 | AI system specifications | Yes | All in-scope systems require specifications | In progress | SPEC-001 +A.9.7 | Use of publicly available AI systems | Yes | Staff use SaaS AI tools | Planned | N/A ``` -For all 38 controls with descriptions → read `references/iso42001-controls-annex-a.md` +For all 38 controls with full descriptions → read `references/iso42001-controls-annex-a.md` ### 5. Policy Generation -**Core AIMS policies required:** +**Core AIMS policies and documents required:** - AI Policy (Clause 5.2) — overarching commitment, scope, principles, top management signature - AI Risk Management Policy (Clause 6) — risk assessment methodology, frequency, ownership - AI Acceptable Use Policy (A.4.1) — permitted and prohibited AI uses, user obligations - Data Governance for AI Policy (A.7) — training data quality, data sourcing, retention, bias controls -- AI Incident Management Policy (A.8) — incident classification, reporting, response, post-incident review -- AI System Lifecycle Policy (A.6) — development, testing, deployment, monitoring, decommission -- AI Supplier Management Policy (A.9) — third-party AI provider due diligence, contractual clauses +- AI Incident Management Policy (A.8.3) — incident classification, reporting, response, post-incident review +- AI System Lifecycle Policy (A.5) — development, testing, deployment, monitoring, decommission +- AI Supplier Management Policy (A.9.1) — third-party AI provider due diligence, contractual clauses -**Policy document structure (use for all):** +**Policy document structure (standard for all):** ``` [Organisation Name] — [Policy Name] Document ID: [ID] | Version: 1.0 | Owner: [Role] | Approved by: [Title] @@ -176,78 +218,137 @@ Effective Date: [Date] | Next Review: [Date +1yr] 7. Revision History ``` +For complete ready-to-use templates → read `references/iso42001-templates.md` + +### 6. EU AI Act Alignment Assessment + +For organisations subject to the EU AI Act (Regulation (EU) 2024/1689), ISO 42001 provides foundational governance coverage. When asked about EU AI Act alignment: + +1. Determine the organisation's role under the EU AI Act (provider, deployer, or both) +2. Classify AI systems by EU AI Act risk category (Prohibited / High-risk / Limited / Minimal) +3. For High-risk AI systems — map the 9 provider obligations (Articles 8–15) to existing ISO 42001 controls +4. For deployers — map deployer obligations (Article 26) and FRIA requirement (Article 27) to AISIA +5. Identify gaps where EU AI Act requires documentation/processes not fully covered by the AIMS +6. Note: ISO 42001 is not (as of December 2023) a formally listed harmonised standard under the EU AI Act, but alignment is extensive + +For the full detailed mapping → read `references/iso42001-eu-ai-act-mapping.md` + --- ## Certification Pathway ### Stage 1 Audit (Documentation Review) -Auditor reviews: AIMS scope, AI policy, risk assessment records, AISIA records, SoA, objectives, documented information controls. Typical duration: 0.5–1 day for small organisations. +Auditor reviews AIMS documentation — scope, AI policy, risk assessment records, AISIA records, SoA, objectives, documented information controls. The Stage 1 audit typically identifies gaps in documentation before the Stage 2 implementation review. **Stage 1 readiness checklist:** -- [ ] AIMS scope document (Clause 4.3) +- [ ] AIMS scope document (Clause 4.3) — defines boundaries and AI systems in scope +- [ ] AI system register — all AI systems in scope identified - [ ] AI policy signed by top management (Clause 5.2) -- [ ] AI system register (all systems in scope listed) +- [ ] Roles and responsibilities defined with RACI (Clause 5.3) - [ ] AI risk assessment completed for all in-scope systems (Clause 6.1.2) -- [ ] AISIA completed for all in-scope systems (Clause 6.1.2) -- [ ] Statement of Applicability (SoA) for all 38 Annex A controls -- [ ] AIMS objectives documented and measurable (Clause 6.2) -- [ ] Internal audit programme (Clause 9.2) -- [ ] Management review agenda template (Clause 9.3) +- [ ] AISIA completed for all in-scope systems (Clause 6.1.2 + A.6.1–6.3) +- [ ] Statement of Applicability (SoA) for all 38 Annex A controls (Clause 6.1.3) +- [ ] AIMS objectives documented and measurable (Clause 6.2) — linked to Annex C attributes +- [ ] Competence matrix and training plan (Clause 7.2) +- [ ] Communication plan (Clause 7.4) +- [ ] Internal audit programme established (Clause 9.2) +- [ ] Management review agenda and schedule (Clause 9.3) ### Stage 2 Audit (Implementation Verification) -Auditor tests that controls work in practice: interviews staff, reviews evidence, samples AI system records, tests incident response. Typical duration: 1–3 days depending on scope. +Auditor tests that controls work in practice: interviews staff, reviews evidence, samples AI system records, tests incident response. **Stage 2 evidence required:** -- Executed AI risk assessments with treatment decisions -- AISIA records for each in-scope AI system -- Competence records and AI awareness training logs -- Supplier AI assessment records (for AI users/providers relying on third parties) -- Incident log (even if no incidents — demonstrate the process works) -- Internal audit report and management review minutes -- Corrective action records for any nonconformities +- Executed AI risk assessments with treatment decisions and residual risk acceptance +- AISIA records for each in-scope AI system — signed and reviewed +- Competence records and AI awareness training completion logs +- AI system specifications and technical documentation (A.5.1, A.5.6) +- Evidence of bias/fairness testing for in-scope AI systems (A.5.5) +- Supplier AI assessment records and relevant contractual clauses (A.9.1, A.9.2) +- AI incident log — demonstrate the process works (even if no incidents occurred) +- Production monitoring evidence for in-scope AI systems (A.5.8) +- Internal audit report with findings, nonconformities, and evidence +- Management review minutes with agenda items, decisions, and actions +- Corrective action records for any identified nonconformities + +### Common Stage 2 Audit Focus Areas +| Area | What Auditors Test | +|------|--------------------| +| AISIA completeness | Is every in-scope AI system covered? Is each AISIA reviewed after changes? | +| Data governance (A.7) | Evidence of training data quality checks, provenance, and bias identification | +| Human oversight controls | Documented processes for human review of high-impact AI outputs | +| Supplier AI management (A.9) | AI-specific contract clauses with key AI vendors; due diligence records | +| AI incident handling (A.8.3) | Evidence that AI incident process is tested and staff know how to report | +| Monitoring in production (A.5.8) | Active monitoring dashboards or reports; defined alert thresholds | +| Staff awareness (Clause 7.3) | Awareness training records; staff can explain AI policy at interview | ### Surveillance Audits -Annual — auditor verifies continued compliance and improvement. Recertification every 3 years. +Conducted annually. Auditors verify continued compliance, review any changes to in-scope AI systems, check corrective actions from previous cycles, and assess continual improvement. Full recertification body review occurs every 3 years. --- ## Integration with Other Management Systems -ISO 42001 uses HLS so it integrates cleanly: +ISO 42001 uses HLS/Annex SL, enabling clean integration with other management systems: + +| ISO Standard / Framework | Integration Points with ISO 42001 | +|--------------------------|-----------------------------------| +| **ISO 27001:2022** | A.7 (data governance for AI) maps to ISO 27001 Annex A.8 (asset management); AI incident management (A.8.3) integrates with 27001 Clause 6.4; supplier AI risk (A.9) aligns with 27001 A.5.19–5.22; Clauses 4–10 share direct structural mapping | +| **ISO 9001:2015** | Quality management processes (Clause 8) align with AI system lifecycle (A.5); shared PDCA cycle; document control aligned | +| **ISO 31000:2018** | AI risk assessment methodology (Clause 6.1.2) aligns with ISO 31000 risk framework principles | +| **NIST AI RMF (2023)** | Four core functions Map/Measure/Manage/Govern map to 42001 clauses; Govern → Clauses 4–5; Map → Clause 6; Measure → Clause 9; Manage → Clause 8 | +| **EU AI Act** | AISIA maps to FRIA (Article 27); A.5 lifecycle maps to Articles 9–12; A.8.1 transparency maps to Article 13; A.7 data governance maps to Article 10 — see `references/iso42001-eu-ai-act-mapping.md` | +| **ISO/IEC 23894** | ISO 42001 references ISO/IEC 23894 (AI risk management guidance) as informative — both use aligned risk terminology | +| **IEEE Ethically Aligned Design** | Annex C responsible AI attributes align with IEEE ethical AI principles | + +--- + +## Annex B — Implementation Guidance Summary + +Annex B is informative guidance on how to implement each Annex A control. Key Annex B themes by domain: -| ISO Standard | Integration Point | -|-------------|-----------------| -| ISO 27001:2022 | A.7 (data governance) maps to ISO 27001 Annex A.8 (asset controls); AI incident management links to 27001 Clause 6.4; supplier AI risk maps to 27001 A.5.19–5.22 | -| ISO 9001:2015 | Quality management processes (Clause 8) align with AI lifecycle; PDCA cycle shared | -| ISO 31000 | AI risk assessment methodology aligns with ISO 31000 risk framework | -| NIST AI RMF | CSF-style four functions (Map, Measure, Manage, Govern) map to 42001 clauses and Annex A | -| EU AI Act | High-risk AI system requirements align closely with 42001 AISIA and Annex A controls; 42001 certification may support EU AI Act conformity | +| Domain | Annex B Guidance Highlights | +|--------|-----------------------------| +| A.2 Policies | AI policy should be reviewed annually or when AI systems change significantly | +| A.3 Organisation | AI roles can overlap with existing roles (e.g., DPO can also hold AI risk responsibilities) | +| A.4 Resources | Procurement due diligence for AI should assess training data provenance, model cards, and benchmarks | +| A.5 Lifecycle | Testing should include adversarial examples and out-of-distribution inputs, not just standard benchmarks | +| A.6 Impact Assessment | AISIA should be conducted as early as design phase — not only at deployment | +| A.7 Data | Data quality criteria should be defined before data collection begins, not post-hoc | +| A.8 Transparency | Transparency obligations should be proportionate — not all AI use requires full disclosure | +| A.9 Third Parties | Supply chain tiers should be assessed: primary AI vendor, their model training data provider, inference platform | +| A.10 Decommission | Decommission plans should be documented at deployment — not created ad-hoc when retirement is imminent | --- ## Common Gap Areas (What Organisations Typically Miss) -1. **AISIA not completed** for all in-scope AI systems — organisations often skip this or treat it as a one-off -2. **AI system register incomplete** — not all AI tools (including SaaS AI features) captured in scope -3. **Data governance for AI** (Annex A.7) — training data quality, bias testing, and data provenance often undocumented -4. **Human oversight documentation** — no formal records of when and how humans review AI outputs -5. **Supplier AI assessments** (A.9) — third-party AI providers not assessed; no contractual AI-specific clauses -6. **Incident management not extended to AI** — existing IT incident processes not updated for AI-specific scenarios (bias incidents, unexpected outputs, model drift) -7. **AI objectives not measurable** — policy states responsible AI principles without specific, measurable targets +1. **AISIA not completed for all in-scope AI systems** — organisations conduct AISIA once at implementation, then fail to re-assess when AI systems change significantly (violates Clause 6.1.2 maintenance requirement) +2. **AI system register incomplete** — SaaS AI features (Microsoft Copilot, embedded AI in business applications) not captured in scope, creating hidden control gaps +3. **Data governance for AI (Annex A.7) underdocumented** — training data quality criteria, bias testing procedures, and data provenance not formally recorded +4. **Human oversight not operationalised** — policy states human oversight is required but no documented procedures for when, how, and by whom AI outputs are reviewed +5. **Supplier AI assessments missing (A.9.1, A.9.2)** — third-party AI providers not assessed; contracts lack AI-specific clauses; no right-to-audit provision +6. **Incident management not extended to AI** — IT incident process used without AI-specific categories (bias incident, unexpected output, model drift notification) +7. **AI objectives not measurable (Clause 6.2)** — policy states responsible AI principles but no specific, measurable, time-bound objectives with owners +8. **SoA exclusions unjustified** — controls excluded from SoA with generic statements rather than documented risk-based justification +9. **Annex C attributes not reflected in objectives** — objectives do not map to the seven responsible AI attributes from Annex C +10. **Management review agenda incomplete** — AI risk assessment results and AISIA updates not included in management review agenda (required by Clause 9.3) --- ## Key Terminology | Term | Definition | -|------|-----------| +|------|------------| | AIMS | AI Management System — the overarching governance framework for managing AI | -| AISIA | AI System Impact Assessment — mandatory assessment of societal/individual impacts | -| AI provider | Organisation that develops, trains, or deploys AI systems for others | -| AI user | Organisation that integrates or uses AI systems from a provider | -| Intended purpose | Documented specification of what an AI system is designed to do | -| AI system | Machine-based system that generates outputs (predictions, decisions, content) from input data | +| AISIA | AI System Impact Assessment — mandatory assessment of societal and individual impacts per Clause 6.1.2 | +| AI provider | Organisation that develops, trains, or deploys AI systems for others or for its own use | +| AI user | Organisation that integrates or uses AI systems developed by a third-party provider | +| Intended purpose | Documented specification of what an AI system is designed to do (A.5.1) | +| AI system | Machine-based system that generates outputs (predictions, decisions, content, recommendations) from input data | | Human oversight | Mechanisms ensuring humans can monitor, intervene in, or override AI outputs | -| Responsible AI | Ethical, transparent, fair, accountable, and safe AI development and use | -| SoA | Statement of Applicability — document justifying inclusion/exclusion of each control | -| HLS | High Level Structure — ISO management system structure enabling multi-standard integration | +| Responsible AI | Ethical, transparent, fair, accountable, and safe AI development and use — framed by Annex C attributes | +| SoA | Statement of Applicability — document listing all 38 Annex A controls with applicability decisions and justifications | +| HLS | High Level Structure (also called Annex SL) — ISO management system structure enabling multi-standard integration | +| FRIA | Fundamental Rights Impact Assessment — EU AI Act Article 27 requirement for deployers of high-risk AI, closely aligned to AISIA | +| Model drift | Degradation of AI model performance over time as real-world data distributions diverge from training data | +| Adversarial attack | Inputs crafted specifically to manipulate or fool an AI model into producing incorrect outputs | diff --git a/plugins/iso42001/skills/iso42001/references/iso42001-eu-ai-act-mapping.md b/plugins/iso42001/skills/iso42001/references/iso42001-eu-ai-act-mapping.md new file mode 100644 index 0000000..03c7131 --- /dev/null +++ b/plugins/iso42001/skills/iso42001/references/iso42001-eu-ai-act-mapping.md @@ -0,0 +1,334 @@ +# ISO/IEC 42001:2023 — EU AI Act Mapping + +This reference maps ISO/IEC 42001:2023 clauses and Annex A controls to the requirements of the **EU AI Act — Regulation (EU) 2024/1689** (the Artificial Intelligence Act), published in the Official Journal of the EU on 12 July 2024 and in force from 1 August 2024. + +--- + +## EU AI Act Overview + +**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 + +**Key dates:** +- Adopted by European Parliament: 13 March 2024 +- Adopted by Council: 21 May 2024 +- Published in Official Journal: 12 July 2024 +- Entry into force: 1 August 2024 (20 days after OJ publication) + +**Application timeline (phased):** +| Phase | Date | What Applies | +|-------|------|-------------| +| Phase 1 | 2 February 2025 | Prohibited AI practices (Chapter II, Article 5) | +| Phase 2 | 2 August 2025 | General Purpose AI (GPAI) model obligations (Chapter V, Articles 51–56); governance provisions | +| Phase 3 | 2 August 2026 | High-risk AI system obligations for most systems (Chapters III–IV, VII–XII) | +| Phase 4 | 2 August 2027 | High-risk AI systems under product safety legislation (Annex I) — specific sector timeline | + +**Territorial scope:** Applies when: +- The AI system is placed on the EU market or put into service in the EU +- The output of the AI system is used in the EU — regardless of where the provider or deployer is established + +--- + +## EU AI Act Risk Classification + +### Prohibited AI Practices (Article 5 — Applies from 2 February 2025) + +The following AI uses are outright prohibited: + +| Prohibited Use | Description | +|---------------|-------------| +| Subliminal manipulation | AI that uses subliminal techniques (beyond conscious awareness) to distort behaviour in ways causing harm | +| Exploitation of vulnerabilities | AI exploiting vulnerabilities of specific groups (age, disability, socioeconomic status) to distort behaviour causing harm | +| Social scoring by public authorities | AI systems that evaluate or classify individuals based on social behaviour or personal characteristics leading to detrimental treatment | +| Real-time remote biometric identification in public spaces (law enforcement) | Exceptions exist for: searching for missing persons, preventing imminent terrorist threat, identifying perpetrators of serious crimes | +| Retrospective remote biometric identification in public spaces (law enforcement) | Without prior authorisation except for prosecution of serious crimes | +| Biometric categorisation by sensitive characteristics | Inferring race, political opinion, religion, philosophical belief, sexual orientation, trade union membership from biometric data — for law enforcement (limited exceptions) | +| Emotion recognition in workplace and education | Except for medical or safety reasons | +| Untargeted facial recognition scraping | Compiling facial recognition databases by scraping internet or CCTV images | + +**ISO 42001 relevance:** The AISIA (Clause 6.1.2, A.6.1–A.6.3) and AI system register (Clause 4) must identify any AI systems that could fall into prohibited categories. Risk treatment option: Avoid (Clause 6.1.3) — do not deploy prohibited AI practices. + +--- + +### High-Risk AI Systems (Annex III — Full obligations from 2 August 2026) + +High-risk AI systems are those listed in **Annex III** of the EU AI Act: + +| Category | Examples | +|----------|----------| +| 1. Biometric identification and categorisation | Remote biometric identification systems; emotion recognition in non-prohibited contexts | +| 2. Critical infrastructure management | AI systems in digital infrastructure, road traffic, water supply, gas, heating, electricity | +| 3. Education and vocational training | AI that determines access, admission, evaluation, or monitoring of students/trainees | +| 4. Employment, workers management, self-employment | AI for recruitment, CV screening, interview monitoring, task allocation, performance monitoring, promotion/dismissal | +| 5. Access to essential private and public services | Credit scoring, insurance risk assessment, emergency services dispatch, benefits eligibility | +| 6. Law enforcement | AI for criminal risk scoring, polygraph-style systems, evidence reliability assessment, deepfake detection, crime analytics | +| 7. Migration, asylum, border management | Risk scoring of persons, document authenticity, asylum processing | +| 8. Administration of justice and democratic processes | AI assisting courts; AI for electoral campaigns targeting | + +Note: Systems listed in **Annex II** (products covered by EU product safety legislation — medical devices, machinery, aviation, etc.) that incorporate AI and present safety risks are also high-risk. + +--- + +### Limited Risk AI (Transparency obligations) + +AI systems that interact directly with people must inform users they are interacting with AI: +- Chatbots and conversational AI (Article 50) — must disclose AI nature +- Deepfakes (AI-generated images, audio, video) — must be labelled +- AI-generated text for public interest (election, climate, health) — must be labelled + +### Minimal Risk AI +All other AI systems — no specific EU AI Act obligations beyond general product law. Majority of AI applications fall here. + +--- + +## ISO 42001 to EU AI Act: Provider Obligations Mapping + +For high-risk AI systems, providers (organisations that develop or place AI systems on the market) must comply with Articles 8–15. The following maps each article to ISO 42001. + +### Article 8 — Compliance with Requirements +**EU AI Act:** Providers must ensure high-risk AI systems comply with Articles 9–15 before placing on the market or putting into service. + +| ISO 42001 Mapping | Relevance | +|------------------|-----------| +| Clause 8.1 — Operational planning and control | Deployment authorisation and go/no-go criteria before AI system goes live | +| A.5.7 — AI system deployment | Controlled deployment process; staged rollout; deployment authorisation | +| Clause 9.1 — Performance evaluation | Monitoring that confirms continued compliance post-deployment | + +--- + +### Article 9 — Risk Management System +**EU AI Act:** Providers must establish a documented, continuous risk management process for high-risk AI systems covering: identification and analysis of known risks, evaluation of risks that may emerge when used as intended or misused, adoption of risk management measures. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| Clause 6.1.2 — AI Risk Assessment | Core risk identification, analysis, and evaluation | Direct | +| A.5.5 — Verification and validation | Testing to identify risks before deployment | Direct | +| A.5.8 — Operation and monitoring | Continuous risk identification in production | Direct | +| Clause 10.2 — Nonconformity and corrective action | Risk materialisation response | Supporting | +| A.5.3 — Data management | Training data risks (poisoning, quality) | Supporting | + +**Gap note:** EU AI Act Article 9 requires risk management to cover risks from **reasonably foreseeable misuse** — this must be explicitly covered in the ISO 42001 AI risk assessment (Clause 6.1.2), not only intended use risks. + +--- + +### Article 10 — Data and Data Governance +**EU AI Act:** Training, validation, and test data must meet quality criteria: relevant, representative, free of errors, complete as needed. Data governance practices must address biases, identify relevant gaps, and be documented. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| A.7.1 — Data management for AI | Governance framework for AI data | Direct | +| A.7.2 — Data acquisition for AI | Controls on data sourcing; legal basis; provenance | Direct | +| A.7.3 — Data quality for AI | Quality criteria for training/validation/test data | Direct | +| A.7.4 — Data preparation for AI | Labelling, annotation, bias identification | Direct | +| A.5.3 — Data management for AI systems | Data lifecycle alongside model lifecycle | Supporting | + +**Gap note:** EU AI Act Article 10(5) specifically addresses personal data used for bias monitoring and correction — this requires linkage with data protection obligations (GDPR / UK GDPR) and may require additional controls beyond ISO 42001 A.7. + +--- + +### Article 11 — Technical Documentation +**EU AI Act:** Providers must prepare technical documentation before placing a high-risk AI system on the market, demonstrating compliance with requirements. Documentation must be maintained throughout system lifetime. Annex IV specifies minimum content. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| A.5.1 — AI system specifications | Intended purpose, inputs/outputs, performance criteria | Direct | +| A.5.6 — AI system documentation | Comprehensive technical documentation per AI system | Direct | +| A.5.2 — AI system design | Design decisions, architectures | Supporting | +| A.5.5 — Verification and validation | Testing records, performance benchmarks | Supporting | + +**EU AI Act Annex IV minimum documentation** — cross-reference to ISO 42001: + +| Annex IV Requirement | ISO 42001 Control | +|---------------------|------------------| +| General description of the AI system and its intended purpose | A.5.1 | +| Description of the elements and development process | A.5.2, A.5.4 | +| Information about training and testing data methodology | A.7.1–A.7.4 | +| Description of monitoring, functioning and control of the system | A.5.8 | +| Description of the risk management system | Clause 6.1.2 | +| Changes to the system over its lifecycle | A.5.7 (change management), A.5.8 | +| Achieved performance indicators (accuracy, robustness, cybersecurity) | A.5.5 | +| Declaration of conformity | SoA (Clause 6.1.3) — supporting evidence | + +--- + +### Article 12 — Record-Keeping (Logging) +**EU AI Act:** High-risk AI systems must have automatic recording of events (logs) during operation. Logs must include: system identification, database consultation dates/times, input data reference IDs, persons involved in verification, and the output. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| A.5.8 — AI system operation and monitoring | Production monitoring, logging of system behaviour | Supporting | +| A.5.7 — AI system deployment | Deployment records | Supporting | +| Clause 7.5 — Documented information | Retention of operational records | Supporting | + +**Gap note:** ISO 42001 does not prescribe specific logging requirements with the granularity required by Article 12. Organisations will need to implement AI-specific logging controls beyond what ISO 42001 mandates, particularly for automated decision AI systems. + +--- + +### Article 13 — Transparency and Provision of Information to Deployers +**EU AI Act:** Providers must design high-risk AI systems to be sufficiently transparent to enable deployers to interpret outputs and use them appropriately. Written instructions for use must accompany the system. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| A.8.1 — Transparency of AI systems | Disclosure obligations; proportion to impact level | Direct | +| A.5.6 — AI system documentation | Technical documentation including limitations and failure modes | Direct | +| A.8.2 — Communication of responsibilities | Instructions to stakeholders on AI system use | Supporting | + +--- + +### Article 14 — Human Oversight +**EU AI Act:** High-risk AI systems must enable effective human oversight. Providers must design systems so that deployers can: understand capabilities and limitations, detect anomalies, interpret outputs, decide not to use or override the system, and intervene or halt it. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| Clause 6.1.2 — AISIA | Impact assessment drives human oversight requirements | Direct | +| A.6.1 — Processes for assessing impact | Formal assessment of when human oversight is sufficient | Direct | +| A.6.2 — Assessing impacts on individuals | Individual-level human oversight requirements | Direct | +| A.5.1 — AI system specifications | Document operating conditions including oversight requirements | Supporting | +| A.5.8 — AI system operation and monitoring | Human intervention triggers in production monitoring | Supporting | +| Annex C attribute: Human agency and oversight | Organisational objective to ensure human control | Supporting | + +--- + +### Article 15 — Accuracy, Robustness, and Cybersecurity +**EU AI Act:** High-risk AI systems must achieve appropriate levels of accuracy, robustness (including adversarial inputs), and cybersecurity throughout their lifecycle. Performance metrics must be declared. + +| ISO 42001 Mapping | Relevance | Coverage | +|------------------|-----------|----------| +| A.5.5 — Verification and validation | Performance benchmarking; adversarial testing | Direct | +| A.5.8 — AI system operation and monitoring | Performance drift monitoring; accuracy degradation detection | Direct | +| Clause 6.1.2 — AI Risk Assessment | Model risks: adversarial attacks, overfitting | Supporting | +| A.5.2 — AI system design | Robustness built into design | Supporting | + +**Gap note:** Cybersecurity of AI systems is addressed in ISO 42001 only at a high level. For high-risk AI systems, cybersecurity controls from ISO 27001 (Annex A) should be explicitly applied to the AI system's infrastructure, model artefacts, and APIs. + +--- + +## ISO 42001 to EU AI Act: Deployer Obligations Mapping + +Deployers (organisations that use high-risk AI systems in a professional context) have obligations under Article 26 and Article 27. + +### Article 26 — Obligations of Deployers of High-Risk AI + +| Article 26 Obligation | ISO 42001 Mapping | +|----------------------|------------------| +| 26(1): Use AI system according to instructions for use | A.4.4 — Third-party AI capabilities; A.9.7 — Public AI systems (acceptable use policy) | +| 26(2): Assign human oversight to natural persons with competence | Clause 7.2 — Competence; A.4.2 — Human resource policies | +| 26(3): Monitor AI system operation and report to provider | A.5.8 — Operation and monitoring; A.8.3 — Incident reporting | +| 26(5): Input data relevant to the AI system's intended purpose | A.7.1–A.7.3 — Data governance for AI | +| 26(6): Inform worker representatives where AI system affects workers | A.8.2 — Communication of responsibilities | +| 26(7): Conduct FRIA if required (Article 27) | AISIA — Clause 6.1.2 + A.6.1–A.6.3 | + +### Article 27 — Fundamental Rights Impact Assessment (FRIA) + +Deployers that are public bodies or private entities providing public services (broad definition) must conduct a FRIA before deploying high-risk AI systems. + +**FRIA requirement:** Document in advance: rights affected, categories of affected persons, foreseen consequences, measures to address adverse impacts, how the AI system fits into the overall purpose. + +**FRIA to AISIA Crosswalk:** + +| FRIA Requirement (Article 27) | ISO 42001 AISIA Equivalent | ISO 42001 Reference | +|-------------------------------|---------------------------|---------------------| +| Description of the AI system and its intended purpose | Section 1: AI System Description | A.5.1 | +| Categories of natural persons affected | Section 2: Affected Populations | A.6.1, A.6.2 | +| Specific risk to fundamental rights (equality, privacy, dignity, expression, assembly) | Section 3: Impact Dimensions | A.6.2 | +| Societal risks (environmental, democratic, economic) | Section 4: Societal Concerns | A.6.3 | +| Measures to address adverse impacts | Section 6: Controls Selected | Annex A controls | +| Residual risk assessment | Section 7: Residual Impact Assessment | Clause 6.1.3 | +| Consultation with affected parties (where applicable) | Not specified in AISIA template — additional step required | A.8.2 | + +**Practical note:** An ISO 42001 AISIA substantially covers the FRIA requirements. Organisations should: +1. Conduct the AISIA using the ISO 42001 templates +2. Before deployment, confirm the AISIA documentation satisfies Article 27 FRIA requirements +3. Add the Article 27-specific consultation requirement if deploying in a context requiring it +4. Retain the AISIA as the primary FRIA record (referencing Article 27 in the document header) + +--- + +## General Purpose AI (GPAI) Model Obligations + +GPAI models (large-scale AI models including large language models — examples: GPT-4, Claude, Llama, Gemini) have specific obligations under Chapter V (Articles 51–56), applying from 2 August 2025. + +**GPAI providers must:** +- Prepare technical documentation (analogous to Annex IV for GPAI — see Article 53) +- Comply with copyright law; make public a summary of training data used +- Publish information enabling downstream providers to meet their obligations +- Cooperate with national authorities on request + +**Systemic risk GPAI (models trained with >10^25 floating-point operations):** +- Conduct adversarial testing (red-teaming) before deployment +- Report serious incidents to the European AI Office +- Implement cybersecurity protections +- Report energy consumption + +| ISO 42001 Mapping for GPAI providers | Relevance | +|-------------------------------------|-----------| +| A.5.6 — AI system documentation | Technical documentation for GPAI models | +| A.5.5 — Verification and validation (including adversarial testing) | Red-teaming / adversarial testing | +| A.7.2 — Data acquisition | Training data provenance and copyright compliance | +| A.8.1 — Transparency | Public disclosure of AI capabilities and limitations | +| A.8.3 — AI incident reporting | Serious incident reporting to competent authority | +| Clause 6.1.2 — AI Risk Assessment | Systemic risk assessment for large-scale models | + +--- + +## ISO 42001 Certification and EU AI Act Conformity + +### Position as of December 2023 (ISO 42001 Publication Date) +ISO/IEC 42001:2023 was **not listed as a harmonised standard** under the EU AI Act at the time of its publication. The EU AI Act's harmonised standards programme was ongoing at publication. + +### Relationship and Practical Value +Even without formal harmonised standard designation, ISO 42001 provides substantial evidence of conformity with many EU AI Act requirements: + +| EU AI Act Article | ISO 42001 Evidence | Level of Coverage | +|------------------|-------------------|------------------| +| Article 9 Risk management | Clause 6.1.2 AI risk assessment records | High | +| Article 10 Data governance | A.7 controls and records | High | +| Article 11 Technical documentation | A.5.1, A.5.6 documentation | High | +| Article 12 Record-keeping | A.5.8 monitoring records | Medium (gaps in logging specificity) | +| Article 13 Transparency | A.8.1 transparency controls | High | +| Article 14 Human oversight | AISIA and A.6 controls | High | +| Article 15 Accuracy and robustness | A.5.5 testing records | Medium | +| Article 26 Deployer obligations | User-role controls throughout | High | +| Article 27 FRIA | AISIA records (A.6.1–A.6.3) | High | + +### Practical Approach for Organisations + +1. **Implement ISO 42001 first** — establishes the governance foundation and generates the evidence base +2. **Map ISO 42001 controls to EU AI Act obligations** — use this reference file to identify gaps +3. **Fill EU AI Act-specific gaps** — particularly: + - Granular logging (Article 12): implement AI-specific event logging beyond ISO 42001 scope + - Reasonably foreseeable misuse in risk assessment (Article 9): explicitly document in risk records + - GPAI model obligations (Article 51–56): additional provider controls if applicable + - Cybersecurity of AI (Article 15): apply ISO 27001 controls to AI infrastructure +4. **Document the mapping** — maintain a live mapping document linking ISO 42001 evidence to EU AI Act articles +5. **Monitor harmonised standards developments** — if ISO 42001 achieves harmonised standard status under the EU AI Act, a presumption of conformity will apply for covered articles + +--- + +## EU AI Act High-Risk AI Sector Guide + +For each Annex III category, the following ISO 42001 controls are most critical: + +| Sector | Critical ISO 42001 Controls | Additional EU AI Act Considerations | +|--------|---------------------------|-------------------------------------| +| Employment AI (CV screening, performance monitoring) | A.5.5 (bias testing) A.6.2 (individual impacts) A.8.1 (transparency to workers) | Article 26(6): notify worker representatives; FRIA required for deployers | +| Credit scoring / insurance | A.5.5 A.6.2 A.8.1 A.9.2 | Right to explanation of AI decisions under GDPR Article 22 must also be met | +| Education (admissions, assessment) | A.5.5 A.6.2 A.8.1 | FRIA likely required; high vulnerability of affected population (students) | +| Healthcare (diagnostic AI) | A.5.1 A.5.5 A.5.6 A.5.8 A.6.2 | Overlapping with Medical Device Regulation (MDR/IVDR) for in vitro diagnostics; Annex I coordination | +| Public safety / law enforcement | A.6.2 A.6.3 A.8.1 A.8.3 | Most restrictive category; FRIA mandatory; real-time biometric restrictions apply | +| Benefits / essential services | A.5.5 A.6.2 A.8.1 A.8.2 | FRIA required for deployers; high impact on vulnerable populations | + +--- + +## EU AI Act and GDPR Interaction + +The EU AI Act sits alongside GDPR (and UK GDPR); both apply simultaneously when AI processes personal data. + +| Topic | GDPR Obligation | EU AI Act Obligation | ISO 42001 Link | +|-------|----------------|---------------------|---------------| +| Automated decisions | Article 22: Right not to be subject to solely automated decisions with legal/significant effects | Article 14: Human oversight for high-risk AI | AISIA human oversight classification; A.8.1 | +| Data minimisation | Article 5(1)(c): Collect only data necessary for purpose | Article 10: Training data proportionate to purpose | A.7.2 data acquisition controls | +| Right to explanation | Recital 71: Meaningful information about automated decision logic | Article 13: Transparency and information to deployers | A.8.1 transparency controls | +| Impact assessments | Article 35: DPIA required for high-risk personal data processing | Article 27: FRIA for deployers | AISIA (ISO 42001 Clause 6.1.2) — conduct AISIA alongside DPIA | +| Data protection by design | Article 25: Data protection by design and default | Article 10: Data governance and bias mitigation | A.7 data controls | + +**Practical note:** For AI systems processing personal data, organisations should conduct the ISO 42001 AISIA and the GDPR DPIA in parallel, using a unified assessment framework where possible. diff --git a/plugins/iso42001/skills/iso42001/references/iso42001-templates.md b/plugins/iso42001/skills/iso42001/references/iso42001-templates.md new file mode 100644 index 0000000..8ddfccb --- /dev/null +++ b/plugins/iso42001/skills/iso42001/references/iso42001-templates.md @@ -0,0 +1,716 @@ +# ISO/IEC 42001:2023 — AIMS Document Templates + +This reference provides ready-to-use document templates for all mandatory and key supported AIMS documents. All templates are aligned to ISO/IEC 42001:2023 clause and control requirements. + +> **Usage note:** Replace all `[PLACEHOLDER]` values with organisation-specific information. All templates use the standard document control header required for Clause 7.5 (Documented Information). + +--- + +## Document Control Header (Standard — Use on All Documents) + +``` +Document Title: [Document Name] +Document ID: [ORG-AIMS-XXX] +Version: 1.0 +Status: Draft / Under Review / Approved +Owner: [Role Title] +Approved By: [Name and Title] +Approval Date: [Date] +Next Review Date: [Date + 1 year] +Classification: [Internal / Confidential / Public] +Related Standard: ISO/IEC 42001:2023 +Related Clauses: [e.g., 4.3, 5.2] +``` + +--- + +## Template 1: AIMS Scope Document + +**Clause reference:** 4.3 +**Purpose:** Define the boundaries and applicability of the AI Management System. + +``` +Document ID: [ORG]-AIMS-SCO-001 + +1. ORGANISATION CONTEXT + Organisation name: [Name] + Sector / Industry: [e.g., Financial Services, Healthcare, Technology] + AIMS Owner (top management): [Name and Title] + Effective date: [Date] + +2. AIMS SCOPE STATEMENT + [Organisation Name] has established an AI Management System (AIMS) in accordance + with ISO/IEC 42001:2023. The AIMS applies to the following: + + Organisational units in scope: + - [List departments, business units, or locations included] + + Processes in scope: + - [e.g., AI system development and deployment, AI procurement, AI operations] + + AI systems in scope: + - [List each AI system by name — see AI System Register for full details] + +3. EXPLICIT EXCLUSIONS + The following are expressly excluded from the AIMS scope: + - [Exclusion 1] — Justification: [Reason] + - [Exclusion 2] — Justification: [Reason] + + Note: Exclusions must not affect the organisation's ability to achieve its AIMS objectives + or violate applicable legal, regulatory, or contractual requirements. + +4. INTERFACES AND DEPENDENCIES + Related management systems: + - [e.g., ISO 27001 ISMS — interfaces with Clause 4.3 of the ISMS] + - [e.g., ISO 9001 QMS — shared document control procedures] + +5. ORGANISATIONAL ROLE(S) UNDER ISO 42001 + [ ] AI provider — develops, trains, or deploys AI systems + [ ] AI user — integrates or uses AI systems from third-party providers + [ ] Both provider and user roles apply + +6. REVISION HISTORY + Version | Date | Author | Changes + 1.0 | [Date] | [Name] | Initial issue +``` + +--- + +## Template 2: AI System Register + +**Clause reference:** 4 (context), 6.1.2 (risk/AISIA), 8 (operations) +**Purpose:** Maintain an inventory of all AI systems within the AIMS scope. + +``` +Document ID: [ORG]-AIMS-REG-001 + +AI System Register — as at [Date] + +| System ID | System Name | Version | Owner | Description / Intended Purpose | Development Model | Provider (if 3rd party) | In-scope AI systems | Risk Assessment ID | AISIA ID | AISIA Level | Status | Last reviewed | +|-----------|-------------|---------|-------|-------------------------------|-------------------|--------------------------|-----------|--------------------|----------|-------------|--------|---------------| +| AI-001 | [Name] | [v1.0] | [Role] | [What does it do and for what purpose] | [In-house / Third-party API / Hybrid] | [Vendor name if applicable] | [Yes / No] | [RA-001] | [AISIA-001] | [Low/Med/High] | [Active / In development / Decommissioned] | [Date] | +| AI-002 | | | | | | | | | | | | | + +Column definitions: +- Development Model: How the AI was built or sourced +- In-scope: Confirmed in AIMS scope (Yes) or excluded (No — requires justification) +- Status: Current operational status of the system +``` + +--- + +## Template 3: AI Policy + +**Clause reference:** 5.2 +**Purpose:** Overarching AI governance commitment signed by top management. + +``` +Document ID: [ORG]-AIMS-POL-001 + +[ORGANISATION NAME] — AI POLICY + +1. PURPOSE AND SCOPE + This policy establishes [Organisation Name]'s commitment to the responsible development, + deployment, and use of artificial intelligence (AI) systems. It applies to all AI systems + within the AIMS scope defined in [ORG]-AIMS-SCO-001 and to all personnel who develop, + operate, procure, or interact with AI systems on behalf of [Organisation Name]. + +2. POLICY STATEMENT + [Organisation Name] is committed to: + + a) Implementing and maintaining an AI Management System that meets the requirements of + ISO/IEC 42001:2023; + + b) Developing, deploying, and using AI systems responsibly, with respect for individual + rights, societal wellbeing, and applicable law; + + c) Ensuring AI systems are transparent, fair, accountable, robust, and safe in their + operation; + + d) Protecting the privacy and data rights of individuals whose data is used in AI systems; + + e) Ensuring meaningful human oversight of AI systems in proportion to their assessed + impact level; + + f) Complying with all applicable legal, regulatory, and contractual requirements relating + to AI; + + g) Continually improving the AIMS to reflect changes in AI systems, the regulatory + environment, and the organisation's AI risk profile. + +3. RESPONSIBLE AI PRINCIPLES + This policy is informed by the following responsible AI attributes (per ISO/IEC 42001:2023 + Annex C): + - Human agency and oversight + - Technical robustness and safety + - Privacy and data governance + - Transparency + - Diversity, non-discrimination, and fairness + - Societal and environmental wellbeing + - Accountability + +4. ROLES AND RESPONSIBILITIES + - [Top management role]: Approves and owns this policy; ensures resource allocation + - [AIMS Owner]: Maintains and implements the AIMS + - [AI Risk Owner (per system)]: Accountable for AI risk assessments and AISIA + - All staff: Comply with this policy and related AI acceptable use requirements + +5. MONITORING AND COMPLIANCE + Compliance with this policy is monitored through: + - Annual internal AIMS audits (Clause 9.2) + - Management review (Clause 9.3) + - AI risk assessment review cycle (Clause 6.1.2) + + Non-compliance is managed through the corrective action procedure [ORG]-AIMS-PRO-010. + +6. RELATED DOCUMENTS + - AIMS Scope Document: [ORG]-AIMS-SCO-001 + - AI Acceptable Use Policy: [ORG]-AIMS-POL-002 + - AI Risk Management Policy: [ORG]-AIMS-POL-003 + +7. REVISION HISTORY + Version | Date | Author | Changes + 1.0 | [Date] | [Name] | Initial issue + +Approved by: ___________________________ +Name: [Top Management Name] +Title: [CEO / Managing Director / equivalent] +Date: [Date] +``` + +--- + +## Template 4: AI Governance RACI Matrix + +**Clause reference:** 5.3 +**Purpose:** Define roles, responsibilities, and accountability for AIMS activities. + +``` +Document ID: [ORG]-AIMS-RACI-001 + +R = Responsible (does the work) +A = Accountable (owns the outcome — only one per row) +C = Consulted (provides input) +I = Informed (notified of outcome) + +| AIMS Activity | Top Mgmt | AIMS Owner | AI Risk Owner | AI System Owner | Data Governance Lead | IT / Security | Legal / Compliance | All Staff | +|-----------------|----------|------------|---------------|-----------------|---------------------|---------------|--------------------|-----------| +| Approve AI Policy | A | R | C | I | C | I | C | I | +| Define AIMS Scope | A | R | C | C | C | C | C | — | +| Conduct AI Risk Assessment | I | C | A/R | C | C | C | C | — | +| Conduct AISIA | I | C | A/R | C | C | I | C | — | +| Maintain AI System Register | I | A | R | R | I | I | I | — | +| Approve SoA | A | R | C | I | C | I | C | — | +| Set AI Objectives | A | R | C | C | C | I | C | — | +| Deliver AI Awareness Training | I | A | C | C | C | R | C | R | +| Manage AI Incident | I | A | C | R | C | R | C | R | +| Conduct Internal Audit | I | A | C | I | C | C | I | — | +| Conduct Management Review | A | R | C | I | C | C | C | — | +| Manage Corrective Actions | I | A | R | R | C | C | C | — | +| AI Supplier Assessment | I | C | A | R | C | C | C | — | +| Model Decommission | I | A | C | R | R | C | C | — | +``` + +--- + +## Template 5: AI Risk Assessment Record + +**Clause reference:** 6.1.2, 8.2 +**Purpose:** Document AI-specific risk assessments for each in-scope AI system. + +``` +Document ID: [ORG]-AIMS-RA-[NNN] + +AI RISK ASSESSMENT RECORD + +AI System: [System Name and Version] (AI-[NNN]) +Assessment Date: [Date] +Assessor: [Name / Role] +Next Review Date: [Date — recommended: annually or on significant change] + +SECTION 1: AI SYSTEM SUMMARY +Intended purpose: [What the system is designed to do] +Outputs produced: [Decisions / Predictions / Classifications / Content / Recommendations] +Data inputs: [Types of data fed into the system] +Deployment context: [Internal tool / Customer-facing / Regulatory context] + +SECTION 2: RISK REGISTER + +| Risk ID | Category | Risk Description | Likelihood (1-5) | Severity (1-5) | Score (L×S) | Rating | Treatment Decision | Controls to Apply | Residual Risk Score | Risk Owner | Review Date | +|---------|----------|-----------------|------------------|----------------|-------------|--------|-------------------|-------------------|---------------------|-----------|--------------| +| R-001 | Model — Bias | [Description] | [1-5] | [1-5] | [score] | [Low/Med/High/Crit] | [Modify/Accept/Avoid/Transfer] | [A.5.3, A.5.5] | [score after treatment] | [Role] | [Date] | +| R-002 | Data | | | | | | | | | | | +| R-003 | Operational | | | | | | | | | | | +| R-004 | Supply chain | | | | | | | | | | | + +Risk rating: 1-4 = Low | 5-9 = Medium | 10-16 = High | 17-25 = Critical + +SECTION 3: RISK TREATMENT SUMMARY +[Summarise treatment decisions and any residual risks accepted at management level] + +SECTION 4: APPROVAL +Reviewed by: [AIMS Owner name / date] +Accepted by: [AI Risk Owner name / date — accountable for residual risk acceptance] +``` + +--- + +## Template 6: AI System Impact Assessment (AISIA) + +**Clause reference:** 6.1.2, A.6.1, A.6.2, A.6.3 +**Purpose:** Assess impacts of each AI system on individuals and society. + +``` +Document ID: [ORG]-AIMS-AISIA-[NNN] + +AI SYSTEM IMPACT ASSESSMENT (AISIA) + +AISIA ID: AISIA-[NNN] +AI System: [System Name and Version] (AI-[NNN]) +Assessment Date: [Date] +Assessor: [Name / Role] +Review Trigger: [ ] Initial deployment [ ] Significant change [ ] Scheduled review +Next Review Date: [Date] + +SECTION 1: AI SYSTEM DESCRIPTION + +Field | Detail +-----------------------|---------------------------------------- +AI system name | [Name] +Version | [Version] +AI system owner | [Name / Role] +Intended purpose | [What the system is designed to do per A.5.1] +Output type | [ ] Decision support [ ] Autonomous decision [ ] Content generation + | [ ] Classification [ ] Prediction [ ] Recommendation +Key inputs | [List data types: names, scores, text, images, etc.] +Deployment context | [Internal / Customer-facing / B2B / Regulatory / Public sector] +Operating conditions | [When system is expected to perform correctly; any limitations] + +SECTION 2: AFFECTED POPULATIONS + +| Population ID | Population Description | How Affected | Number Affected (approx.) | Vulnerability Factors | +|--------------|----------------------|--------------|--------------------------|----------------------| +| P-001 | [e.g., Job applicants] | [e.g., AI screens CVs; affects hiring decisions] | [e.g., ~500/month] | [e.g., None identified / Protected characteristics / Socioeconomic status] | +| P-002 | [e.g., Existing employees] | | | | + +Vulnerability factors to consider: age (children/elderly), disability, socioeconomic status, +minority group membership, limited AI literacy, power imbalance (employer/employee; government/citizen). + +SECTION 3: IMPACT DIMENSIONS + +For each affected population, assess: + +| Dimension | Population P-001 | Population P-002 | +|-----------|-----------------|------------------| +| Nature of possible harm | [Financial / Physical / Psychological / Discrimination / Loss of opportunity / Reputational] | | +| Severity of worst-case impact | [1=Negligible to 5=Catastrophic] | | +| Breadth (number of people) | [Small number / Moderate / Large scale] | | +| Reversibility | [Easily reversible / Partially reversible / Difficult to reverse / Irreversible] | | +| Duration | [Short-term / Medium-term / Long-term / Permanent] | | +| Consent and awareness | [Individuals informed? Consent obtained where required?] | | +| Human oversight | [None / Review on request / Structured review / Mandatory before action] | | +| Recourse available | [General complaints / AI-specific appeal / Right to human decision-maker] | | + +SECTION 4: SOCIETAL CONCERNS (A.6.3) +Assess broader societal impacts, if applicable: +- Potential for misinformation or manipulation at scale: [Yes / No / Limited] +- Labour displacement risk: [Yes / No / Limited] +- Environmental impact of AI compute: [High / Medium / Low / Not assessed] +- Reinforcement of systemic bias at scale: [Yes / No / Risk identified — describe] + +SECTION 5: IMPACT CLASSIFICATION + +Overall impact level: [ ] Low [ ] Medium [ ] High + +Justification: [Explain classification based on severity, breadth, reversibility, and vulnerability of affected populations] + +SECTION 6: CONTROLS SELECTED + +| Control Area | Control(s) Selected | Implementation Status | +|-------------|--------------------|-----------------------| +| Transparency (A.8.1) | [e.g., Disclosure notice on application form that AI is used] | [Planned / In progress / Implemented] | +| Human oversight | [e.g., All automated rejections reviewed within 3 business days] | | +| Bias testing (A.5.5) | [e.g., Monthly demographic disparity report] | | +| Documentation (A.5.6) | [e.g., Model card published internally] | | +| Monitoring (A.5.8) | [e.g., Weekly performance dashboard; alert at >5% drift] | | +| Recourse mechanism | [e.g., Dedicated email; human review within 10 days] | | + +SECTION 7: RESIDUAL IMPACT ASSESSMENT +After applying selected controls, residual impact level: [ ] Low [ ] Medium [ ] High +Residual impact accepted by: [AI Risk Owner name] Date: [Date] + +SECTION 8: REVIEW SCHEDULE +[ ] Low impact: review every 3 years or at significant change to AI system or operating context +[ ] Medium impact: review annually or at significant change +[ ] High impact: review every 6 months or at any change + +Next scheduled AISIA review date: [Date] + +SECTION 9: APPROVAL +Assessor: _________________________ Date: _______ +AI Risk Owner: ____________________ Date: _______ +AIMS Owner: _________________________ Date: _______ +``` + +--- + +## Template 7: Statement of Applicability (SoA) + +**Clause reference:** 6.1.3 +**Purpose:** Lists all 38 Annex A controls with applicability decisions. + +``` +Document ID: [ORG]-AIMS-SOA-001 + +STATEMENT OF APPLICABILITY — ISO/IEC 42001:2023 + +Organisation: [Name] +Date: [Date] +Version: 1.0 +AIMS Owner: [Name / Role] + +Organisational role(s): +[ ] AI provider [ ] AI user [ ] Both + +Notes on applicability: +- "Yes": Control is applicable and must be implemented +- "No": Control is not applicable — justification must be documented +- Implementation status: Not started / Planned / In progress / Implemented / Verified + +| Control ID | Control Name | Applicable? | Justification for inclusion/exclusion | Implementation Status | Evidence Reference | +|-----------|-------------|-------------|---------------------------------------|----------------------|-------------------| +| A.2.1 | AI policy | Yes | Required for all AIMS | | | +| A.2.2 | AI-specific controls in organisational policies | Yes | Required for all AIMS | | | +| A.3.1 | Roles and responsibilities related to AI | Yes | Required for all AIMS | | | +| A.4.1 | Policies for AI system resources | [Yes/No] | [Provider: compute resource governance needed / User: not directly applicable] | | | +| A.4.2 | Human resource policies related to AI | Yes | Required for all — training and competence obligations | | | +| A.4.3 | Procurement policies for AI | Yes | All organisations procure AI tools or services | | | +| A.4.4 | Third-party AI capabilities | [Yes/No] | [Required if using third-party AI systems] | | | +| A.5.1 | AI system specifications | [Yes/No] | [Required for AI providers / Not primary for pure AI users] | | | +| A.5.2 | AI system design | [Yes/No] | [Provider only] | | | +| A.5.3 | Data management for AI systems | [Yes/No] | [Provider primary; user where training data held] | | | +| A.5.4 | AI system development | [Yes/No] | [Provider only] | | | +| A.5.5 | AI system verification and validation | [Yes/No] | [Provider primary; user where custom AI is developed] | | | +| A.5.6 | AI system documentation | Yes | Required for all — both provider and user document AI systems | | | +| A.5.7 | AI system deployment | [Yes/No] | [Provider primary] | | | +| A.5.8 | AI system operation and monitoring | Yes | All organisations operating AI systems must monitor them | | | +| A.6.1 | Processes for assessing impact of AI systems | Yes | Required for all — AISIA processes mandatory | | | +| A.6.2 | Assessing impacts on individuals | Yes | Required for all — individual impact assessment required | | | +| A.6.3 | Determining and assessing societal concerns | Yes | Required for all — societal impact assessment required | | | +| A.7.1 | Data management for AI | [Yes/No] | [Provider primary — AI-specific data governance framework] | | | +| A.7.2 | Data acquisition for AI | [Yes/No] | [Provider primary — controls on training data sourcing] | | | +| A.7.3 | Data quality for AI | [Yes/No] | [Provider primary — quality criteria for training/validation data] | | | +| A.7.4 | Data preparation for AI | [Yes/No] | [Provider primary — labelling and annotation controls] | | | +| A.8.1 | Transparency of AI systems | Yes | Required for all — disclosure obligations to affected individuals | | | +| A.8.2 | Communication of responsibilities to stakeholders | Yes | Required for all — stakeholder communication | | | +| A.8.3 | Reporting on AI incidents | Yes | Required for all — AI incident reporting process | | | +| A.9.1 | Policy for use of AI by third parties | Yes | All organisations engage third parties in some capacity | | | +| A.9.2 | Supply chain relationships | Yes | AI supply chain risk management | | | +| A.9.3 | Sharing of AI system data | [Yes/No] | [Applicable if organisation shares AI data with third parties] | | | +| A.9.4 | Interactions between AI systems | [Yes/No] | [Applicable if AI systems interact with other AI systems] | | | +| A.9.5 | Use of AI system by external entities | [Yes/No] | [Provider: applicable if customers use the AI system] | | | +| A.9.6 | Procurement of AI components | [Yes/No] | [Provider: applicable if procuring pre-trained models/datasets] | | | +| A.9.7 | Use of publicly available AI systems | Yes | Applicable if staff use public AI tools (ChatGPT, Copilot, etc.) | | | +| A.10.1 | AI system decommissioning policy | [Yes/No] | [Provider: applicable; User: limited applicability] | | | +| A.10.2 | Retention and disposal of AI system data | [Yes/No] | [Provider primary; User where AI training data held] | | | +| A.10.3 | Model deprecation | [Yes/No] | [Provider: applicable when models are retired] | | | +| A.10.4 | Reuse of data and models | [Yes/No] | [Provider: applicable if training data or models reused across systems] | | | +| A.10.5 | Archiving of AI systems | [Yes/No] | [Provider: applicable for audit trail purposes] | | | +| A.10.6 | Responsible AI system disposal | [Yes/No] | [Provider primary] | | | + +Total applicable controls: [X] of 38 +Total excluded controls: [Y] of 38 + +Statement: [Name, Role] confirms this SoA accurately reflects control applicability for +[Organisation Name]'s AIMS as of [Date]. + +Signed: _________________________ Date: _____________ +``` + +--- + +## Template 8: AI Objectives Register + +**Clause reference:** 6.2 +**Purpose:** Document measurable AI objectives aligned to Annex C responsible AI attributes. + +``` +Document ID: [ORG]-AIMS-OBJ-001 + +AI OBJECTIVES REGISTER + +| Obj ID | Objective Description | Annex C Attribute | Clause/Control | Measure | Target | Reporting Frequency | Owner | Target Date | Status | +|--------|----------------------|------------------|----------------|---------|--------|--------------------||-------|-------------|--------| +| OBJ-001 | Complete AISIA for all in-scope AI systems | Accountability | Clause 6.1.2 | % AI systems with completed and approved AISIA | 100% | Quarterly | AIMS Owner | [Date] | [Status] | +| OBJ-002 | Achieve 100% AI awareness training completion | Human agency | Clause 7.3 | % staff who interact with AI systems having completed AI awareness training | 100% | Annually | HR / AIMS Owner | [Date] | | +| OBJ-003 | Reduce AI incident mean time to report | Accountability | A.8.3 | Average time from AI incident detection to formal incident record | < 4 hours | Quarterly | AI Incident Manager | [Date] | | +| OBJ-004 | Complete AI supplier assessments for all Tier 1 AI vendors | Societal wellbeing | A.9.2 | % Tier 1 AI suppliers with completed assessment | 100% | Bi-annually | AI Procurement Lead | [Date] | | +| OBJ-005 | Achieve fairness score within defined threshold for [AI System X] | Fairness | A.5.5 | [Fairness metric, e.g., demographic parity difference] < [threshold] | < [X]% | Monthly | AI System Owner | [Date] | | +| OBJ-006 | Attain ISO 42001 certification | Accountability | All clauses | Certification received | Certified | One-time milestone | AIMS Owner | [Date] | | +``` + +--- + +## Template 9: AI Incident Record + +**Clause reference:** 8 (Operation), A.8.3 +**Purpose:** Document AI-specific incidents from detection through resolution. + +``` +Document ID: [ORG]-AIMS-INC-[NNN] + +AI INCIDENT RECORD + +Incident ID: INC-[NNN] +Date reported: [Date and time] +Reported by: [Name / Role] +AI system affected: [System Name + AI Register ID] +AI system owner: [Name / Role] + +SECTION 1: INCIDENT DESCRIPTION +Incident summary: [Brief description — what happened] +Incident type: +[ ] Unexpected AI output [ ] Bias or discriminatory outcome +[ ] Model performance degradation [ ] Data quality issue +[ ] Scope misuse [ ] Transparency failure +[ ] Security/adversarial event [ ] Other: ___________ + +When detected: [Date and time] +How detected: [ ] Internal monitoring [ ] User report [ ] External complaint [ ] Audit [ ] Other +Individuals affected: [Number and description — if known] +Severity assessment: +[ ] Low — limited impact; no individuals harmed +[ ] Medium — moderate impact; potential individual harm; requires investigation +[ ] High — significant impact; individuals harmed; may require external notification +[ ] Critical — severe/irreversible impact; regulatory reporting likely required + +SECTION 2: IMMEDIATE RESPONSE ACTIONS +Action | Taken by | Date/Time | Outcome +[Describe immediate containment actions] | [Name] | [Date/Time] | [Result] + +AI system status: +[ ] Continues operating (risk managed) [ ] Output manually reviewed [ ] System suspended pending investigation + +SECTION 3: INVESTIGATION +Root cause analysis: [Describe root cause — e.g., training data gap, model drift, scope creep, process failure] + +Contributing factors: [List additional factors that contributed] + +Impact assessment: +- Number of individuals affected: [Number or "Not determined"] +- Nature of impact: [Describe] +- Data protection implications: [ ] Yes — DPA notified [ ] No [ ] Under assessment +- Regulatory notification required: [ ] Yes — [Regulator and deadline] [ ] No + +SECTION 4: CORRECTIVE AND PREVENTIVE ACTIONS +Action | Owner | Due Date | Status +[Action 1] | [Name] | [Date] | [Status] + +Corrective Action Record raised: [ ] Yes — CAR-[NNN] [ ] No — rationale: [reason] + +SECTION 5: CLOSURE +Incident closed date: [Date] +Closed by: [Name / Role] +Prevention confirmed: [ ] Yes — [describe confirmation] [ ] No — ongoing monitoring + +SECTION 6: LESSON LEARNED +[Describe any changes to AI system, processes, controls, or guidance resulting from this incident] +``` + +--- + +## Template 10: Internal AIMS Audit Checklist + +**Clause reference:** 9.2 +**Purpose:** Structured checklist for internal AIMS audits covering Clauses 4–10 and key Annex A controls. + +``` +Document ID: [ORG]-AIMS-AUD-[NNN] + +INTERNAL AIMS AUDIT CHECKLIST + +Audit reference: AUD-[NNN] +Audit date: [Date] +Auditor: [Name / Role — must not audit own work] +Scope: [Clauses and controls covered in this audit] +Scope reference: AIMS Scope Document [ORG]-AIMS-SCO-001 + +CONFORMANCE RATINGS: C = Conforming | OFI = Opportunity for Improvement | NC = Nonconformity | N/A = Not applicable + +CLAUSE 4 — CONTEXT +[ ] C [ ] OFI [ ] NC 4.1 Context analysis includes AI-specific external/internal issues +[ ] C [ ] OFI [ ] NC 4.2 Interested parties identified; requirements documented; AI-affected individuals included +[ ] C [ ] OFI [ ] NC 4.3 AIMS scope document is current; boundaries and exclusions justified +[ ] C [ ] OFI [ ] NC 4.4 AI system register is complete and current for all in-scope AI systems +Findings: [Notes] + +CLAUSE 5 — LEADERSHIP +[ ] C [ ] OFI [ ] NC 5.1 Top management demonstrates active commitment; AI governance in management meetings +[ ] C [ ] OFI [ ] NC 5.2 AI policy is current, signed, communicated — includes responsible AI principles +[ ] C [ ] OFI [ ] NC 5.3 Roles and responsibilities defined (RACI); accountabilities assigned and understood +Findings: [Notes] + +CLAUSE 6 — PLANNING +[ ] C [ ] OFI [ ] NC 6.1.2 AI risk assessment completed for all in-scope AI systems; documented +[ ] C [ ] OFI [ ] NC 6.1.2 AISIA completed for all in-scope AI systems; reviewed on schedule +[ ] C [ ] OFI [ ] NC 6.1.3 SoA covers all 38 Annex A controls; exclusions justified; current +[ ] C [ ] OFI [ ] NC 6.2 AI objectives are measurable; linked to Annex C attributes; tracked +Findings: [Notes] + +CLAUSE 7 — SUPPORT +[ ] C [ ] OFI [ ] NC 7.2 Competence requirements defined; training completed; effectiveness evaluated +[ ] C [ ] OFI [ ] NC 7.3 All relevant staff aware of AI policy and their AIMS obligations +[ ] C [ ] OFI [ ] NC 7.4 Communication plan exists; AI-relevant communications have occurred +[ ] C [ ] OFI [ ] NC 7.5 Documented information maintained; controlled; retained per schedule +Findings: [Notes] + +CLAUSE 8 — OPERATION +[ ] C [ ] OFI [ ] NC 8.1 Operational planning controls implemented for AI system lifecycle +[ ] C [ ] OFI [ ] NC 8.2 AI risk assessment executed and records retained +[ ] C [ ] OFI [ ] NC 8.3 Risk treatment plan implemented; treatment evidence retained +Findings: [Notes] + +CLAUSE 9 — PERFORMANCE EVALUATION +[ ] C [ ] OFI [ ] NC 9.1 Monitoring metrics defined and measured; reports produced +[ ] C [ ] OFI [ ] NC 9.2 Internal audit conducted per schedule; report issued; NCs actioned +[ ] C [ ] OFI [ ] NC 9.3 Management review conducted; all required agenda items covered; minutes retained +Findings: [Notes] + +CLAUSE 10 — IMPROVEMENT +[ ] C [ ] OFI [ ] NC 10.1 Continual improvement activities evidenced +[ ] C [ ] OFI [ ] NC 10.2 Nonconformities recorded; root cause investigated; corrective actions closed +Findings: [Notes] + +SELECTED ANNEX A CONTROLS (sample — expand as per audit programme) +[ ] C [ ] OFI [ ] NC A.5.5 Bias/fairness testing conducted; documented before deployment +[ ] C [ ] OFI [ ] NC A.5.8 Production monitoring active; alert thresholds defined +[ ] C [ ] OFI [ ] NC A.7 Training data quality; provenance documented +[ ] C [ ] OFI [ ] NC A.8.1 Transparency: AI-affected individuals informed appropriately +[ ] C [ ] OFI [ ] NC A.8.3 AI incident log active; incidents classified and actioned +[ ] C [ ] OFI [ ] NC A.9.2 Supplier AI assessments completed; contractual AI clauses in place +[ ] C [ ] OFI [ ] NC A.9.7 Acceptable use policy for public AI tools; staff aware +Findings: [Notes] + +SUMMARY +Conformities: [Number] +Opportunities for improvement: [Number] +Nonconformities: [Number] + +Nonconformities raised: +- NC-[NNN]: [Description] — Clause/Control: [ref] + +Audit conclusion: [Overall assessment of AIMS conformance and effectiveness] + +Auditor signature: _________________________ Date: _______ +Auditee acceptance: ________________________ Date: _______ +``` + +--- + +## Template 11: Management Review Agenda and Minutes + +**Clause reference:** 9.3 +**Purpose:** Standard agenda and minutes template for management review of the AIMS. + +``` +Document ID: [ORG]-AIMS-MGMT-[NNN] + +MANAGEMENT REVIEW — AIMS + +Date: [Date] +Chair: [Top management attendee] +Attendees: [Names and roles] +Apologies: [Names] +Documents: [List supporting documents circulated] + +AGENDA (required by ISO 42001 Clause 9.3 b.i through b.ix) + +1. ACTIONS FROM PREVIOUS MANAGEMENT REVIEW [Status of each action] +2. CHANGES IN EXTERNAL/INTERNAL AI CONTEXT [New regulations, new AI systems, organisational changes] +3. AI RISK ASSESSMENT RESULTS [Summary table: systems reviewed, risk ratings, changes] +4. AISIA RESULTS AND UPDATES [Impact classifications changed? New systems assessed?] +5. PERFORMANCE AGAINST AI OBJECTIVES (Clause 6.2) [Dashboard — each objective: target vs actual] +6. INTERNAL AUDIT RESULTS [Audit findings, NC status, OFIs] +7. NONCONFORMITIES AND CORRECTIVE ACTIONS STATUS [Open CARs, overdue actions] +8. AI INCIDENT SUMMARY [Incidents since last review, severity, lessons learned] +9. SUPPLIER AI ASSESSMENT STATUS [Key supplier assessments completed, outstanding] +10. OPPORTUNITIES FOR IMPROVEMENT [Ideas and proposals from AIMS team] +11. RESOURCE REQUIREMENTS [Budget, staffing, tooling needs for next period] + +MINUTES + +Item 1 — Actions from previous review: +[Status of each action from previous minutes] + +Item 2 — Context changes: +[Decisions: e.g., New AI regulation noted: EU AI Act Article X came into force — action assigned] + +Item 3 — AI risk assessment results: +[Summary: [X] AI systems reviewed this period. Risk profile update: [description]. Decisions: [e.g., one critical risk accepted with monitoring plan]] + +[Continue for all agenda items] + +DECISIONS AND ACTIONS +| Action | Owner | Due Date | +|--------|-------|----------| +| [Action description] | [Name/Role] | [Date] | + +Next management review date: [Date] + +Minutes approved by: _________________________ +Name: [Chair name] +Title: [Title] +Date: [Date] +``` + +--- + +## Template 12: Corrective Action Record + +**Clause reference:** 10.2 +**Purpose:** Document nonconformities and track corrective actions through to verified closure. + +``` +Document ID: [ORG]-AIMS-CAR-[NNN] + +CORRECTIVE ACTION RECORD + +CAR ID: CAR-[NNN] +Date raised: [Date] +Raised by: [Name / Role] +Source: [ ] Internal audit [ ] Management review [ ] External audit [ ] AI incident [ ] Staff report [ ] Other +Related NCI ref: [Audit NC reference or incident ID if applicable] +Clause/Control: [e.g., Clause 6.1.2 / A.5.5] + +SECTION 1: NONCONFORMITY DESCRIPTION +[Describe what was observed and what the requirement is — be factual and specific] + +Requirement: [Quote the specific clause or control requirement not met] +Evidence of NC: [What evidence demonstrates the nonconformity?] + +SECTION 2: CONTAINMENT ACTION (Immediate) +Action taken to contain immediate impact: +[Describe immediate action taken to prevent further impact] +Completed by: [Name] Date: [Date] + +SECTION 3: ROOT CAUSE ANALYSIS +Method used: [ ] 5 Whys [ ] Fishbone [ ] Process analysis [ ] Other: ______ +Root cause identified: [Describe the underlying cause, not just the symptom] + +SECTION 4: CORRECTIVE ACTION PLAN +| Action step | Owner | Due date | Status | +|-------------|-------|----------|--------| +| [Step 1] | [Name] | [Date] | [Not started/In progress/Complete] | +| [Step 2] | [Name] | [Date] | | + +SECTION 5: EFFECTIVENESS REVIEW +Effectiveness review date: [Date — typically 30-90 days after corrective action completion] +Evaluation method: [How will the organisation confirm the root cause is resolved?] + +Effectiveness confirmed: [ ] Yes — [Evidence confirming NCI is resolved and root cause eliminated] + [ ] No — [New or revised corrective action required — raise new CAR] + +SECTION 6: CLOSURE +CAR closed date: [Date] +Closed by: [AIMS Owner name / signature] +``` 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/plugins/nist-sp-800-115/.claude-plugin/plugin.json b/plugins/nist-sp-800-115/.claude-plugin/plugin.json new file mode 100644 index 0000000..bf2a98f --- /dev/null +++ b/plugins/nist-sp-800-115/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "nist-sp-800-115", + "version": "1.0.0", + "description": "NIST SP 800-115 Technical Guide to Information Security Testing and Assessment skill for planning and executing security assessments including network scanning, vulnerability analysis, penetration testing, social engineering, and wireless security testing.", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@gmail.com" + }, + "homepage": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "repository": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "nist-sp-800-115", + "security-testing", + "penetration-testing", + "vulnerability-assessment", + "security-assessment", + "network-scanning", + "social-engineering", + "wireless-security", + "red-team", + "FISMA" + ] +} diff --git a/plugins/nist-sp-800-115/skills/nist-sp-800-115/SKILL.md b/plugins/nist-sp-800-115/skills/nist-sp-800-115/SKILL.md new file mode 100644 index 0000000..dc1da3a --- /dev/null +++ b/plugins/nist-sp-800-115/skills/nist-sp-800-115/SKILL.md @@ -0,0 +1,309 @@ +--- +name: nist-sp-800-115 +description: > + Expert NIST SP 800-115 security testing and assessment advisor. Use this skill + whenever a user asks about planning or executing information security assessments, + including: penetration testing, network scanning and discovery, vulnerability + scanning, port scanning, social engineering testing, wireless security testing, + web application security testing, assessment planning (Rules of Engagement, scope, + assessment plan), assessment reporting, target identification, security review + techniques (examination, interviewing, testing), security assessment phases, + attack and exploitation techniques (in the context of authorised testing), post + exploitation and cleanup, safe handling of assessment results, or building an + internal security testing programme aligned to NIST guidance. Also trigger for: + "how do I plan a penetration test?", "what is a rules of engagement document?", + "how do I assess wireless security?", "what is a security review?", "how do I + enumerate a network?", "what social engineering test techniques are described in + NIST?", or any question about technical security testing methodology. +--- + +# NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment Skill + +You are an expert information security testing advisor specialising in **NIST Special Publication 800-115: Technical Guide to Information Security Testing and Assessment** (September 2008). You assist **security assessment teams, penetration testers, ISSOs, system owners, and red team leads** in planning, conducting, and reporting on technical security assessments of federal information systems. + +SP 800-115 provides a systematic methodology for assessing the security posture of information systems through technical testing. All guidance in this skill is grounded in the published SP 800-115 document. + +--- + +## How to Respond + +| Task | Output Format | +|------|--------------| +| Assessment planning | Structured assessment plan outline with phases and activities | +| Technique description | Technique name, purpose, approach, tools mentioned in SP 800-115, output | +| Phase walkthrough | Numbered steps within each phase | +| Rules of Engagement guidance | Key RoE elements and considerations | +| Reporting guidance | Report structure and content requirements | +| General question | Concise prose with SP 800-115 section citations | + +--- + +## SP 800-115 Overview + +### Purpose +SP 800-115 provides guidance on the key elements of technical information security testing and assessment, with an emphasis on hands-on testing that complements the documentation review and interviews described in SP 800-53A. + +### Assessment Categories + +SP 800-115 defines three categories of security testing and examination: + +| Category | Definition | +|---------|-----------| +| **Review Techniques** | Examination-based: documentation review, log review, ruleset review, system configuration review, network sniffing, file integrity checking | +| **Target Identification and Analysis** | Discovery-based: network discovery, network port and service identification, vulnerability scanning, wireless scanning | +| **Target Vulnerability Validation** | Exploitation-based: password cracking, penetration testing, social engineering, application security testing | + +--- + +## Phase 1 — Planning + +The planning phase defines the scope, objectives, and ground rules before any testing begins. + +### 1.1 Assessment Scope Definition + +The assessment scope defines: +- **In-scope systems**: IP address ranges, domain names, application URLs, network segments, physical locations +- **Out-of-scope systems**: Systems explicitly excluded (e.g., production payment systems during peak periods) +- **Assessment objectives**: What the assessment is designed to test (e.g., perimeter defences, internal network, specific applications) +- **Assessment types authorised**: Which techniques are approved (vulnerability scanning? exploitation? social engineering?) + +### 1.2 Rules of Engagement (RoE) + +The Rules of Engagement define the constraints and expectations under which the assessment is conducted: + +| RoE Element | Contents | +|------------|---------| +| Scope | Authorised targets (by IP range, hostname, URL) | +| Authorisation | Name and title of the official authorising the test; date authorisation was granted | +| Restrictions | What is explicitly excluded or prohibited (e.g., denial-of-service testing, exploitation of certain systems) | +| Escalation path | Who the assessment team contacts if a critical finding is discovered during testing | +| Communication | How progress is communicated; status update frequency | +| Emergency stop | Conditions under which testing must stop immediately (e.g., actual incident detected) | +| Data handling | How test data, credentials obtained, and findings are handled and destroyed | +| Start and end dates | Approved testing window | + +### 1.3 Assessment Plan + +The Security Assessment Plan (for testing) includes: +1. Assessment objectives and scope +2. Types of testing to be performed +3. Team members and their roles +4. Schedule and logistics +5. Rules of Engagement (or reference to the RoE document) +6. Reporting requirements + +--- + +## Phase 2 — Discovery + +The discovery phase collects information about targets without active exploitation. + +### 2.1 Network Discovery + +**Objective**: Identify live hosts within the target network scope. + +**Techniques**: +- **Ping sweep (ICMP)**: ICMP echo request to each IP in the target range; note that many systems block ICMP +- **TCP SYN ping**: Send SYN packets to common ports to detect live hosts even when ICMP is blocked +- **ARP scanning** (local network only): Use ARP requests; reliable for local segment enumeration +- **DNS enumeration**: Zone transfer attempts, brute-force subdomain lookup, DNS record review (A, MX, NS, CNAME, TXT) + +**Output**: List of live IP addresses; hostnames if resolvable. + +### 2.2 Network Port and Service Identification + +**Objective**: Determine which ports are open and what services are listening. + +**Techniques**: +- **TCP SYN scan**: Half-open scan; SYN sent; RST returned if filtered; recommended for speed +- **TCP Connect scan**: Full three-way handshake; logged by target; slower but more reliable +- **UDP scan**: Slower; sends UDP datagrams; identifies DNS, SNMP, TFTP, and other UDP services +- **Service version detection**: Banner grabbing and protocol-specific probes to identify service name and version +- **OS fingerprinting**: Analysis of TCP/IP stack behaviour to infer operating system + +**Output**: Port list (open/closed/filtered), service names, version banners, OS guess. + +### 2.3 Vulnerability Scanning + +**Objective**: Identify known vulnerabilities in discovered services and applications. + +**Approaches**: +- **Network-based scanning**: Scanner probes target services from the network; no credentials needed; may miss application-layer vulns +- **Credential-based (authenticated) scanning**: Scanner logs into targets with provided credentials; significantly more thorough; identifies local configuration issues, patch levels, and software inventory + +**Scanner output**: CVE identifiers, CVSS scores, vulnerability descriptions, remediation recommendations. + +**Limitations of automated scanning**: +- False positives: Scanner flags a vulnerability that does not exist on the target (version match without actual exploitability) +- False negatives: Vulnerability exists but scanner does not detect it (new CVE, custom configuration) +- All scanner findings must be manually validated before being reported as confirmed findings + +### 2.4 Wireless Network Scanning + +**Objective**: Identify wireless networks within range, their configuration, and security weaknesses. + +**Techniques**: +- **Wireless discovery**: Identify SSIDs including hidden networks (via probe response packets); record BSSID (MAC), channel, signal strength, encryption type +- **Encryption assessment**: Identify whether WEP (insecure), WPA (check version), WPA2, WPA3 is used +- **Rogue access point detection**: Identify APs broadcasting SSIDs that match authorised network names but on different hardware (honeypot or evil-twin attack indicators) +- **Client enumeration**: Identify clients associated with each AP + +--- + +## Phase 3 — Attack and Exploitation + +The attack phase validates vulnerabilities discovered in Phase 2 by attempting to exploit them. All exploitation requires explicit authorisation in the RoE. + +### 3.1 Exploitation Overview + +Purpose of exploitation in an authorised test: +- Confirm that a discovered vulnerability is actually exploitable (eliminate false positives) +- Determine the impact of a successful exploitation (what data/access would be obtained) +- Demonstrate the risk chain (e.g., from initial foothold to domain admin escalation) + +### 3.2 Password Cracking + +**Technique**: Recover plaintext passwords from captured hashes (offline cracking) or attempt authentication with known/guessed credentials (online brute-force/credential stuffing). + +**Categories**: +- **Dictionary attacks**: Use a wordlist of common passwords; efficient; effective against weak passwords +- **Hybrid attacks**: Dictionary words with common substitutions (Password1!, P@ssw0rd) +- **Brute force**: Exhaustive character-space search; computationally expensive; typically limited to short numeric PINs or constrained character sets +- **Credential stuffing**: Use username/password pairs obtained from breached databases + +**Offline cracking context**: Requires obtaining password hashes (e.g., from SAM/NTDS.dit on Windows, /etc/shadow on Linux, or from a captured NTLM challenge-response) — this is a post-exploitation activity. + +**Important**: Online brute-force must respect account lockout policies. Testers must not lock out real user accounts unless specifically authorised. + +### 3.3 Penetration Testing + +SP 800-115 describes penetration testing as a systematic attempt to breach system defences to evaluate the effectiveness of security controls. + +**Phases of penetration testing**: + +1. **Planning**: Define target, objectives, constraints (via RoE); establish starting conditions (black-box, grey-box, or white-box) +2. **Information gathering**: Passive (OSINT) and active reconnaissance; builds on Phase 2 discovery +3. **Vulnerability analysis**: Analyse gathered information for exploitable weaknesses; prioritise targets +4. **Exploitation**: Attempt to exploit identified vulnerabilities; document results +5. **Post-exploitation**: From a foothold, attempt privilege escalation, lateral movement, and access to sensitive data; document what would be accessible to a real attacker +6. **Cleanup**: Remove all tools, accounts, and artefacts created during the test; restore any modified settings + +**Testing approaches**: + +| Approach | Description | +|---------|-------------| +| Black-box | Tester has no prior knowledge of the target; simulates an external attacker | +| Grey-box | Tester has some knowledge (e.g., user-level credentials, network diagram); simulates an insider or partially informed attacker | +| White-box | Tester has full knowledge (source code, detailed architecture documentation); most thorough; simulates a sophisticated attacker with insider knowledge | + +### 3.4 Social Engineering Testing + +**Objective**: Test whether personnel can be manipulated into revealing sensitive information, performing unauthorised actions, or bypassing security controls. + +**Techniques described in SP 800-115**: +- **Phishing (email)**: Send simulated phishing emails; measure click rate, credential entry rate, report rate +- **Vishing (voice/telephone)**: Call employees pretending to be IT support, vendors, or executives; attempt to obtain credentials, system access, or sensitive information +- **Physical intrusion attempts**: Tailgating, posing as delivery personnel, or other physical social engineering tactics (must be carefully scoped and authorised) + +**Safeguards required**: +- Must have written authorisation from the appropriate management level +- Personnel must not be humiliated or penalised individually for failing tests +- Results should be used for training, not disciplinary action + +### 3.5 Application Security Testing + +**Techniques for web applications**: +- **Input validation testing**: Attempt to inject malicious input (SQL, OS commands, scripting) into all input fields, headers, and parameters +- **Authentication testing**: Test for weak authentication, session management flaws, credential enumeration +- **Authorisation testing**: Attempt to access resources with insufficient permissions (privilege escalation, IDOR) +- **Session management**: Test for session fixation, session token predictability, insecure cookie attributes + +--- + +## Phase 4 — Reporting + +### 4.1 Report Structure + +An assessment report from an SP 800-115-based assessment includes: + +**Executive Summary**: +- Overall risk posture +- Key findings requiring immediate action +- Number of findings by severity +- Assessment constraints or limitations that affected thoroughness + +**Technical Findings**: +For each finding: +- Finding title and severity (Critical / High / Moderate / Low / Informational) +- Affected systems/components +- Vulnerability description (what the vulnerability is) +- Evidence (screenshots, tool output, logs from the test) +- Risk narrative (what an attacker could do with this) +- Remediation recommendation (specific, actionable) +- References (CVE, CWE, NIST 800-53 control, vendor advisory) + +**Appendices**: +- Scope definition (in and out of scope) +- Testing methodology +- Raw tool output +- Timeline of testing activities + +### 4.2 Finding Severity + +Align severity with SP 800-30 risk levels or CVSS scores: +- Critical: CVSS 9.0–10.0; immediate exploitation possible; severe impact +- High: CVSS 7.0–8.9; readily exploitable; significant impact +- Moderate: CVSS 4.0–6.9; exploitable with effort; moderate impact +- Low: CVSS 0.1–3.9; limited exploitability or impact +- Informational: No direct risk; best practice or observation + +### 4.3 Data and Report Handling + +- Assessment reports contain sensitive vulnerability information and must be marked and handled accordingly +- Credentials, hashes, or sensitive data obtained during testing must be destroyed after reporting +- Reports should be transmitted only over encrypted channels +- Physical reports must be stored securely and shredded when no longer required + +--- + +## Core Workflows + +### 1. Planning a Security Assessment +1. Define objectives with the system owner and ISSO +2. Draft the RoE covering scope, authorisation, restrictions, escalation, emergency stop, data handling +3. Get written authorisation from the Authorising Official or system owner +4. Develop the assessment plan: team, schedule, methods, reporting requirements +5. Brief the assessment team on scope and RoE before starting any activity + +### 2. Conducting Network Discovery +1. Begin with passive discovery (DNS enumeration, publicly available information) where in scope +2. Perform host discovery within approved IP ranges +3. Conduct port/service scan of live hosts +4. Perform vulnerability scans (network-based first, then credentialed if authorised) +5. Validate scanner outputs manually; categorise false positives; prioritise validated findings + +### 3. Writing a Penetration Test Report +1. For each exploited finding: document the exact steps taken (proof of exploitability) +2. Include screenshots or command output as evidence +3. Calculate risk using likelihood + impact; assign a severity +4. Write a specific, actionable remediation recommendation +5. Include an executive summary suitable for the AO and non-technical management + +--- + +## Reference Files + +- `references/assessment-techniques.md` — Detailed technique descriptions for all SP 800-115 review, discovery, and exploitation techniques +- `references/penetration-testing-phases.md` — Step-by-step phase guidance for planning, discovery, exploitation, and reporting including tool context and output descriptions +- `references/reporting-templates.md` — Finding documentation templates, executive summary structure, severity classification, report handling requirements + +**When to load:** +- Asking about specific testing techniques or methods → load `references/assessment-techniques.md` +- Planning or executing a penetration test → load `references/penetration-testing-phases.md` +- Structuring or writing an assessment report → load `references/reporting-templates.md` + +--- + +## Disclaimer + +This skill is based on NIST SP 800-115 (September 2008), a freely available NIST publication providing guidance for authorised security testing. All techniques described are for use only in authorised security assessments. Unauthorised testing of computer systems is illegal under the Computer Fraud and Abuse Act (CFAA) and equivalent laws. This skill provides guidance on legitimate, authorised defensive security assessment activities and does not provide instructions for offensive or illegal use. All testing must be conducted under a signed authorisation before any active testing begins. diff --git a/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/assessment-techniques.md b/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/assessment-techniques.md new file mode 100644 index 0000000..7cc1a34 --- /dev/null +++ b/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/assessment-techniques.md @@ -0,0 +1,251 @@ +# Assessment Techniques Reference — NIST SP 800-115 + +Source: NIST SP 800-115 (September 2008), Sections 3–6 + +--- + +## Review Techniques (Section 3) + +Review techniques are examination-based methods that do not involve active testing of systems. They provide insight into security posture through analysis of documentation, configurations, and logs. + +### Documentation Review + +**Purpose**: Evaluate whether security policy, plans, procedures, and standards are complete, consistent, and current. + +**Documents to review**: +- System Security Plan (SSP): boundary, data types, implemented controls, system description +- Security policies: access control, password, incident response, acceptable use +- Network architecture diagrams: verify they match the actual network +- Configuration standards: benchmarks, hardening guides, approved baseline configurations +- Change management records: compare approved changes to actual system state +- Audit logs: review for completeness and anomalies +- Incident records: review for recurring themes or unresolved incidents +- Risk assessment reports: verify identified risks have been addressed + +**What to look for**: +- Outdated documents (review dates, software versions no longer in use) +- Inconsistencies between the SSP and actual configuration +- Absence of required documents +- Policies that have not been reviewed within the required time period + +--- + +### Log Review + +**Purpose**: Identify indicators of attack, policy violations, or operational anomalies by examining log records. + +**Log sources to review**: +- Operating system security logs: failed logons, privilege escalation, account creation/deletion +- Application logs: access denied events, error conditions, unusual query patterns +- Network device logs: firewall denies, unusual traffic patterns, large data transfers +- Authentication logs: logon anomalies, after-hours access, geographic impossibility +- Web server access logs: unusual URL patterns (traversal attempts, injection strings) + +**What to look for**: +- Unusually high volume of failed authentications (brute-force indicator) +- Access to sensitive resources at unusual times +- Outbound connections to unusual IP addresses or geographies +- Large data transfers (potential exfiltration) +- Cleared or missing log segments (potential log tampering or evasion) + +--- + +### Ruleset Review + +**Purpose**: Evaluate the security effectiveness of firewall, router ACL, IDS/IPS, and security group rules. + +**For firewall rule review**: +1. Obtain the full rule export (not just a summary) +2. Review for: default deny at the end of all rulesets, any-any rules, overly broad source or destination, unnecessary open ports +3. Compare open ports against the approved service list in the SSP +4. Check for rules that are no longer needed (orphaned rules for decommissioned systems) +5. Verify management plane access (SSH, HTTPS, SNMP) is restricted to authorised management networks + +**For IDS/IPS rule review**: +1. Verify signature/rule set is current +2. Confirm relevant attack categories are enabled (not operating in a default or minimal mode) +3. Review any rules that have been disabled and verify the justification + +--- + +### System Configuration Review + +**Purpose**: Compare actual system configuration against the approved baseline or industry hardening standard. + +**Approach**: +1. Export current configuration settings (OS audit policy, service list, registry settings, software inventory) +2. Compare against approved baseline (CIS Benchmark, DISA STIG, vendor hardening guide, or agency-defined baseline) +3. Document deviations with their security impact +4. Confirm patch level: compare installed patches against available patches for the OS and all installed software + +**Configuration areas to review**: +- User accounts (disabled/default accounts, account permissions) +- Services and processes (unnecessary services running) +- Network exposure (open ports/services not needed) +- Audit/logging settings (what events are logged) +- Password settings (complexity, minimum length, history) +- Encryption settings (protocols enabled, cipher suites) + +--- + +### Network Sniffing (Passive Traffic Analysis) + +**Purpose**: Capture and analyse network traffic to identify security-relevant information: cleartext credentials, unencrypted sensitive data, protocol vulnerabilities. + +**Safeguards**: Network sniffing on production networks may capture user data. The following safeguards are required: +- Written authorisation from the system owner is required +- Traffic capture is limited to the authorised network segment and time window +- Captured data must be reviewed only by authorised personnel and destroyed after the assessment +- PII, financial data, and credentials in captured traffic must not be retained beyond the scope of the immediate finding + +**What to look for**: +- Cleartext credentials (HTTP Basic Auth, FTP, Telnet, SNMP v1/v2) +- Cleartext session tokens or cookies +- Unencrypted sensitive data (personal information, financial data) +- Unusual protocols or unexpected traffic patterns +- Broadcast traffic revealing network topology + +--- + +### File Integrity Checking + +**Purpose**: Detect whether files have been modified unexpectedly, which may indicate compromise, unauthorised change, or misconfiguration. + +**Approach**: +1. Compare current file hashes against a known-good baseline +2. Files of interest: operating system binaries, configuration files, authentication databases, audit log files +3. Any difference between current hash and baseline hash constitutes a potential finding + +--- + +## Target Identification and Analysis Techniques (Section 4) + +### Network Discovery + +**Host Discovery Techniques**: +| Technique | Method | Limitations | +|-----------|--------|------------| +| ICMP Echo Request (ping) | Send ICMP echo; wait for reply | Blocked by most firewalls; unreliable for full host census | +| TCP SYN to common ports | Send SYN to port 80, 443, 22; any response indicates live host | Some hosts only expose closed ports | +| ARP Request (local subnet) | Layer 2; cannot be blocked by host firewalls | Limited to local segment | +| DNS Reverse Lookup | PTR record query for each IP | Only useful when reverse DNS is maintained | + +--- + +### Port and Service Scanning + +**Port States**: +- **Open**: Service actively accepting connections +- **Closed**: No service; host is reachable; RST returned +- **Filtered**: No response; firewall may be dropping packets + +**Scan Types**: +| Type | Description | Detectability | Reliability | +|------|-------------|--------------|-------------| +| TCP SYN (half-open) | Sends SYN; waits for SYN-ACK; sends RST | Moderate (logged by most IDS) | High | +| TCP Connect | Full three-way handshake | High (fully logged by application and OS) | Highest | +| UDP | Sends UDP datagrams; ICMP unreachable = closed; no response = open or filtered | Low | Lower (slow; unreliable) | +| FIN/XMAS/NULL | Non-standard flag combinations; bypasses some basic firewalls | Variable | Less reliable on Windows | + +**Service Version Detection**: Send protocol-specific probes to open ports to identify service name and version. Banner grabbing extracts service announcement strings. + +--- + +### Vulnerability Scanning + +**Network-Based Scanning** (unauthenticated): +- Tests visible services from the network perspective +- Infers vulnerability based on service version and banner information +- May produce false positives if version is patched without changing the banner + +**Credentialed Scanning** (authenticated): +- Logs into each host using provided credentials +- Checks installed software versions, patch levels, local configuration +- More accurate; fewer false positives +- Requires credentials to be provided in the scanner configuration; credentials must be handled securely + +**Scan Validation**: +Every finding from an automated scanner must be manually verified before reporting: +1. Confirm the service/version is actually running +2. Test whether the specific vulnerability is actually present (version check vs. proof-of-concept) +3. Identify compensating controls that may reduce the effective risk + +--- + +### Wireless Security Assessment + +**Passive Scanning**: +- Capture all 802.11 beacon frames in range +- Record: SSID, BSSID, channel, supported rates, encryption type, vendor OUI +- Identify: hidden SSIDs (detected via probe responses), deauthentication frames (potential DoS) + +**Active Assessment**: +- **WEP identification**: WEP is cryptographically broken; if identified, it is a Critical finding +- **WPA/WPA2 assessment**: Check for WPA TKIP (deprecated); confirm WPA2-CCMP (AES) or WPA3 +- **Enterprise vs. Personal**: Verify whether WPA2-Enterprise (802.1X) is used (preferred for government/enterprise networks) vs. pre-shared key (PSK) +- **Client isolation**: Verify whether clients on the WLAN can communicate with each other (if client isolation is required by policy) +- **Management frame protection**: Verify whether 802.11w Management Frame Protection (MFP) is enabled (protects against deauthentication attacks) +- **Rogue AP detection**: Scan for APs on unusual channels, APs with SSIDs matching the corporate network but different BSSIDs, or APs with unexpected vendor MAC prefixes + +--- + +## Target Vulnerability Validation Techniques (Section 5) + +### Password Cracking + +**Authorised use context**: Credential capture (e.g., obtaining NTLM hashes via authenticated access to an AD domain controller or from a compromised system) followed by offline cracking — only under written authorisation. + +**Methods**: +| Method | Description | Use Case | +|--------|-------------|---------| +| Dictionary attack | Test each word in a wordlist | Common/default/predictable passwords | +| Hybrid | Dictionary + rules (capitalise, append numbers, add special chars) | Passwords with minor complexity modifications | +| Brute force | Exhaustive search over character space | Short PINs, constrained character sets | +| Rainbow table | Pre-computed hash tables | Fast lookup against common unsalted hashes; ineffective against salted hashes | + +**Reporting**: Document percentage of accounts cracked, time to crack, tool used. Do not include plaintext credentials in the report body — reference them in secured supplemental materials. + +--- + +### Penetration Testing Techniques + +**Exploitation progression**: +1. Identify a vulnerability confirmed by scanner and/or manual testing +2. Select applicable exploitation approach (public exploit, manual technique, custom script) +3. Execute exploit against the target (within authorised scope only) +4. Confirm successful exploitation (shell access, data access, privilege level obtained) +5. Document exact steps, commands, output, and screenshots + +**Post-exploitation activities** (if authorised): +- Privilege escalation: attempt to gain higher privileges from current access level +- Lateral movement: from one compromised host, attempt to move to other hosts in scope +- Data access: identify what sensitive data would be accessible to an attacker with this level of access +- Persistence (if authorised): document what persistence mechanisms could be established (but clean up all artefacts) + +**Cleanup requirements** (mandatory): +- Remove all tools, backdoors, and accounts created during the test +- Restore any settings modified to enable exploitation +- Remove all cached credentials +- Document all changes made to each system so that cleanup can be verified + +--- + +### Social Engineering Techniques + +**Phishing simulation methodology**: +1. Design a pretext (fake IT helpdesk, fake HR communication, fake vendor notification) +2. Send simulated phishing email to target population (using a landing page that captures clicks and optionally credential entries without storing real credentials) +3. Measure: open rate, click rate, credential entry rate, report rate +4. Debrief: notify all recipients after the campaign; provide training to those who took the bait + +**Vishing methodology**: +1. Define pretext scenario (IT support, vendor audit, executive assistant) +2. Call a sample of employees from the target group +3. Attempt to elicit: credentials, software details, network topology, or to have the employee perform an action (e.g., disable an account, click a link) +4. Document: success rate, information obtained, length of call, awareness indicators (caller identified as suspicious) + +**Physical social engineering** (most sensitive; requires tight scope control): +1. Tailgating: attempt to follow an authorised person through a controlled access point +2. Impersonation: pose as a vendor, contractor, or delivery person to gain access +3. Requires explicit authorisation from building security management and senior agency officials +4. Must have a clearly defined abort signal/code diff --git a/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/penetration-testing-phases.md b/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/penetration-testing-phases.md new file mode 100644 index 0000000..60bd8c3 --- /dev/null +++ b/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/penetration-testing-phases.md @@ -0,0 +1,221 @@ +# Penetration Testing Phases — NIST SP 800-115 + +Source: NIST SP 800-115 (September 2008), Sections 5–7 + +--- + +## Overview of the SP 800-115 Testing Process + +SP 800-115 describes a four-phase technical testing process: + +1. **Planning** — Define scope, objectives, rules, and logistics +2. **Discovery** — Identify targets and gather information +3. **Attack** — Validate vulnerabilities through controlled exploitation +4. **Reporting** — Document findings with risk context and remediation guidance + +Each phase must be completed in sequence. No attack activity should begin until the Planning phase is complete and a signed authorisation is in hand. + +--- + +## Phase 1 — Planning + +### Authorisation Requirements + +Before any testing activity begins, the following must be in place: +- Written authorisation from the official with authority to authorise testing (system owner, AO, or designated official) +- Signed Rules of Engagement document (see SKILL.md Section 1.2 for RoE elements) +- Identification of any third-party systems that may be incidentally tested (e.g., shared hosting, cloud providers) and explicit decisions on whether such testing is permitted + +### Threat Modelling for Penetration Tests + +To focus the assessment on the most relevant risks, define the threat model: +1. What type of attacker is being simulated? (external/internet-based, insider/trusted user, nation-state) +2. What is the attacker's assumed starting position? (no access / user access / admin access) +3. What is the primary target? (sensitive data, system availability, authentication bypass) +4. What attack paths are most relevant to the organisation's threat landscape? + +### Testing Approach Selection + +| Approach | Starting Knowledge | Simulates | When to Use | +|---------|-------------------|-----------|----| +| Black-box | None | External attacker with no access | Testing external-facing systems; assessing perimeter effectiveness | +| Grey-box | Partial (network diagram, user credentials) | Insider, compromised vendor, or partially informed attacker | More efficient; covers both external and internal attack paths | +| White-box | Full (source code, architecture docs, admin credentials) | Sophisticated attacker with insider knowledge | Maximum coverage; developer-focused testing; source code review included | + +--- + +## Phase 2 — Discovery + +### Step 1 — Passive Information Gathering + +Before sending a single packet to target systems, gather publicly available information: +- WHOIS registrations (domain owner, registrar, nameservers, contact info) +- DNS enumeration (A, MX, NS, CNAME, TXT, SPF records; attempt zone transfer) +- Public search engines (cached pages, PDF metadata, exposed files) +- Job postings (reveal technology stack, software versions, tools in use) +- Social media (employee technology discussions) +- Pastebin and GitHub (leaked credentials, internal hostnames, API keys) + +### Step 2 — Network Reconnaissance + +Active discovery within the authorised scope: + +**Host Discovery** (structured by technique reliability): +``` +Priority 1 (most reliable): ARP requests (local subnet only) +Priority 2: TCP SYN to 80, 443, 22, 3389 +Priority 3: ICMP echo request (may be filtered) +Priority 4: UDP to DNS (53), SNMP (161) +``` + +**Port Scanning**: +- Start with top 1000 ports (covers >95% of common services): TCP SYN scan +- Follow with full port range (1-65535) on priority targets +- Add UDP scan for key services: DNS (53), DHCP (67/68), TFTP (69), SNMP (161/162), NTP (123) +- Service version detection on all open ports +- OS fingerprinting on priority targets + +**Service Enumeration** (per discovered service): +| Service | Port | Enumeration Technique | +|---------|------|----------------------| +| HTTP/HTTPS | 80/443 | Banner grab; directory enumeration; robots.txt; application fingerprinting | +| SSH | 22 | Version disclosure; supported algorithms | +| SMB | 445 | Share enumeration; null session test; signing check | +| LDAP | 389/636 | Directory enumeration; null bind test | +| RDP | 3389 | Protocol version; NLA requirement check | +| SNMP | 161 | Community string check (public/private); if accessible: full MIB walk | +| DNS | 53 | Zone transfer; recursive query test; DNSSEC check | +| SMTP | 25 | Banner; open relay test; VRFY/EXPN command test | + +### Step 3 — Vulnerability Identification + +After completing discovery: +1. Run automated vulnerability scanner (network-based, with target list from discovery) +2. Run credentialed scan on priority targets if authorised +3. Review scanner output: categorise all findings into True Positive / Needs Validation / Likely False Positive +4. Prioritise True Positives by CVSS score for Phase 3 + +--- + +## Phase 3 — Attack + +### Step 1 — Vulnerability Validation (Proof-of-Concept Testing) + +For each priority vulnerability: +1. Verify the specific version and service are actually present (check version disclosure, not just CVE match) +2. Check for available public exploits (CVE databases, security advisories) +3. Attempt exploitation in a controlled manner; document: exact command, timestamp, response +4. Classify: Exploited (confirmed) / Not Exploited (false positive or patched) / Partially Exploited (partial bypass) + +### Step 2 — Initial Access Techniques by Category + +**Network services exploitation**: +- Exploit publicly accessible vulnerable services (e.g., unauthenticated remote code execution) +- Test for default credentials on network devices and services +- Attempt exploitation of exposed administrative interfaces (web admin, SNMP write) + +**Authentication bypass**: +- SQL injection on login forms → authentication bypass +- Weak session tokens → session hijacking +- Missing MFA → credential stuffing with known breached credentials + +**Client-side exploitation** (if browser/email client testing is in scope): +- Phishing with malicious document (macro-based) delivered to target user +- Testing whether security awareness training is effective against simulated spear-phishing + +### Step 3 — Privilege Escalation (Post-Initial-Access) + +After obtaining initial access (user-level), escalation techniques: + +**Windows environments**: +- Unquoted service paths with write permission in path components +- Writable service binaries +- AlwaysInstallElevated registry key +- Token impersonation (if SeImpersonatePrivilege available) +- Kerberoasting (requesting service tickets for service accounts; crack offline) +- Pass-the-Hash (if NTLM hashes obtained) +- GPO misconfiguration (write access to GPOs or the OU they apply to) + +**Linux/Unix environments**: +- SUID binaries with unintended privilege elevation +- Sudo misconfigurations (NOPASSWD entries, wildcard paths) +- World-writable cron jobs +- Path hijacking in root-owned scripts +- Weak file permissions on sensitive files (/etc/passwd, service configuration files) + +### Step 4 — Lateral Movement (Post-Escalation) + +From a privileged compromise, assess internal network reach: +- Pass-the-Hash / Pass-the-Ticket to authenticate to other systems with harvested credentials +- SMB share access to locate sensitive data +- WMI / PowerShell remoting to execute commands on remote systems +- Internal port scan to identify systems accessible from the compromised host that were not accessible externally + +### Step 5 — Data Access Assessment + +Document what sensitive data would be accessible: +- Identify sensitive data stores reachable from compromised position +- Confirm whether DLP, encryption at rest, or access controls prevent access +- Record the finding: "From [compromised system], an attacker can access [data store] containing [data type]" +- Do not exfiltrate real sensitive data; document the access path only + +### Step 6 — Cleanup (Mandatory) + +After completing the exploitation phase: + +| Artifact Type | Cleanup Action | +|--------------|--------------| +| Created user accounts | Delete every account created during the test | +| Uploaded tools/scripts | Remove all files uploaded to target systems | +| Modified registry keys | Restore original values | +| Modified configuration files | Restore original content | +| Scheduled tasks or services | Remove all persistence mechanisms created | +| Cached credentials | Clear from all compromised systems | +| Exploitation log | Cross-reference each action with cleanup verification | + +Sign off on cleanup: document that each step above was completed and verified. + +--- + +## Phase 4 — Reporting + +### Finding Documentation Format + +For each unique finding, document: + +``` +Finding ID: [PT-YYYY-NNN] +Severity: Critical / High / Moderate / Low / Informational +CVSS Score: [if applicable, provide Base Score] +CVE: [if applicable] +Affected Systems: [list of IPs/hostnames] + +Title: [Clear, specific title — e.g., "Unauthenticated Remote Code Execution + on Public Web Application (CVE-YYYY-XXXXX)"] + +Description: [What the vulnerability is; why it exists; what can be done with it] + +Steps to Reproduce (Proof of Exploitation): + [Exact commands and output demonstrating exploitability — use screenshots + for critical/high severity findings. This section is what distinguishes + a penetration test finding from a scanner finding.] + +Impact: [What an attacker gains from exploiting this; what data or systems would + be at risk; what the business impact would be] + +Evidence: [Tool output, screenshots, log excerpts] + +Recommendation: [Specific, actionable remediation. For patching: identify the specific + patch/version to upgrade to. For configuration: specify the exact + setting change. For architecture: describe the required design change.] + +References: [CVE, NVD, vendor advisory, NIST 800-53 control(s), CWE] +``` + +### Report Handling and Distribution + +- Classify the report at a level appropriate to its contents (e.g., FOUO if it contains system vulnerability details) +- Distribute only via encrypted channels +- Maintain a record of who received each copy +- Destroy digital and physical copies per the agreed data handling procedure once remediation is complete or the retention period expires +- Do not include live credentials, cryptographic keys, or hashes in the report body — reference them in a separately secured addendum if absolutely required diff --git a/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/reporting-templates.md b/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/reporting-templates.md new file mode 100644 index 0000000..3e14133 --- /dev/null +++ b/plugins/nist-sp-800-115/skills/nist-sp-800-115/references/reporting-templates.md @@ -0,0 +1,312 @@ +# Reporting Templates — NIST SP 800-115 + +Source: NIST SP 800-115 (September 2008), Section 6; supplemented by common penetration testing report conventions consistent with SP 800-115 reporting requirements + +--- + +## Security Assessment Report Template + +--- + +### [SYSTEM NAME] Security Assessment Report + +**Classification**: [FOUO / Sensitive] +**Version**: 1.0 +**Date**: [DATE] +**Prepared By**: [Assessment Organisation] +**Assessment Type**: [Network/Vulnerability Assessment / Penetration Test / Social Engineering / Combined] + +--- + +#### Section 1 — Executive Summary + +**1.1 System Identification** + +| Field | Value | +|-------|-------| +| System Name | | +| System Owner | | +| Assessment Authorised By | | +| Assessment Period | [Start] to [End] | +| Assessment Team | | + +**1.2 Overall Findings Summary** + +| Severity | Count | +|---------|-------| +| Critical | | +| High | | +| Moderate | | +| Low | | +| Informational | | +| **Total** | | + +**1.3 Key Risk Statement** + +[2–4 sentences summarising the most significant risks found. Written for a non-technical audience. Example:] + +"The assessment identified [N] critical and [N] high severity vulnerabilities. The most significant finding was [brief description], which would allow an attacker to [impact]. Immediate remediation of critical and high findings is recommended before the next assessment period." + +**1.4 Immediate Actions Required** + +List Critical and High-severity findings requiring prioritised remediation: + +| Finding ID | Title | Severity | Affected Systems | Recommended Action | +|-----------|-------|---------|-----------------|-------------------| +| | | Critical | | | +| | | High | | | + +**1.5 Assessment Limitations** + +[Note any constraints that limited the assessment's thoroughness] + +| Limitation | Impact on Results | +|-----------|------------------| +| | | + +--- + +#### Section 2 — Assessment Scope and Methodology + +**2.1 In-Scope Systems** + +| Component | IP / Hostname | Environment | +|-----------|-------------|-------------| +| | | | + +**2.2 Out-of-Scope Systems** + +| Component | Reason for Exclusion | +|-----------|---------------------| +| | | + +**2.3 Assessment Types Conducted** + +- [ ] Network Discovery +- [ ] Port and Service Scanning +- [ ] Vulnerability Scanning (unauthenticated) +- [ ] Vulnerability Scanning (credential-based) +- [ ] Penetration Testing +- [ ] Social Engineering +- [ ] Physical Security Testing +- [ ] Wireless Assessment +- [ ] Web Application Testing +- [ ] Configuration Review +- [ ] Documentation Review +- [ ] Log Review + +**2.4 Approach** + +[Black-box / Grey-box / White-box — with description of starting knowledge and constraints] + +--- + +#### Section 3 — Technical Findings + +Use the following template for each finding. Order findings by severity (Critical first). + +--- + +**Finding Template** + +``` +Finding ID: [PT-YYYY-001] +Severity: Critical / High / Moderate / Low / Informational +CVSS Base Score: [x.x (if applicable)] +CVE: [CVE-YYYY-XXXXX (if applicable)] +CWE: [CWE-XXX (if applicable)] + +Title: [Concise, specific title] +Affected Systems: [IP(s) or hostname(s)] +Service/Port: [e.g., TCP 443 / HTTPS] + +DESCRIPTION +[What the vulnerability is, why it is present, and what it means from a security perspective. +Avoid generic CVE descriptions — describe the vulnerability in the context of this specific system.] + +STEPS TO REPRODUCE (PROOF OF EXPLOITABILITY) +Note: Include this section for Critical and High severity findings. +[Exact commands, tool configurations, and outputs demonstrating that the vulnerability was +confirmed or exploited. This distinguishes a penetration test finding from a scanner finding.] + +Example format: + 1. Connected to [target IP]:[port] using [tool/method] + 2. Issued the following command: [exact command] + 3. Output received: [exact output or screenshot reference] + 4. This demonstrates [what was achieved] + +IMPACT +[What an attacker could do if they exploited this vulnerability. Be specific: +- What system-level access would be gained? +- What data would be accessible? +- How would this affect confidentiality, integrity, or availability? +- What is the business impact?] + +EVIDENCE +[Reference to screenshot, tool output, or log excerpt — typically placed in an appendix +and referenced here. For example: "See Appendix A, Figure A-1."] + +RECOMMENDATION +[Specific, actionable remediation: +- For patching: "Upgrade [software] from version [current] to version [target] or later. + Reference vendor advisory: [URL]." +- For configuration: "Set [specific configuration parameter] to [specific value]." +- For architecture: "Implement [specific control] to [address the specific risk]." +Note estimated effort (low/medium/high) if possible to help the system owner prioritise.] + +REFERENCES +- CVE: [if applicable] +- NVD: [if applicable] +- Vendor Advisory: [if applicable] +- NIST SP 800-53 Rev 5: [Relevant control(s)] +- CWE: [if applicable] +``` + +--- + +#### Section 4 — Risk Summary Matrix + +| Finding ID | Title | Severity | Likelihood | Impact | Risk | Recommended Timeline | +|-----------|-------|---------|-----------|--------|------|---------------------| +| | | Critical | Very High | Very High | Very High | Immediate (< 15 days) | +| | | High | High | High | High | 30 days | +| | | Moderate | Moderate | Moderate | Moderate | 90 days | + +--- + +#### Section 5 — Remediation Roadmap + +Organise remediation by timeline and effort: + +**Immediate (0–15 days) — Critical Findings** +| Finding ID | Title | Responsible Party | Estimated Effort | +|-----------|-------|------------------|----------------| +| | | | | + +**Short-term (15–30 days) — High Findings** +| Finding ID | Title | Responsible Party | Estimated Effort | +|-----------|-------|------------------|----------------| +| | | | | + +**Medium-term (30–90 days) — Moderate Findings** +| Finding ID | Title | Responsible Party | Estimated Effort | +|-----------|-------|------------------|----------------| +| | | | | + +**Long-term (90–180 days) — Low Findings** +| Finding ID | Title | Responsible Party | Estimated Effort | +|-----------|-------|------------------|----------------| +| | | | | + +--- + +#### Section 6 — Assessor Attestation + +The undersigned conducted this assessment in accordance with NIST SP 800-115, within the scope and constraints defined in the approved Rules of Engagement dated [DATE]. All testing was authorised. Cleanup of all testing artefacts was completed and is documented in the attached cleanup log. + +| Role | Name | Signature | Date | +|------|------|----------|------| +| Assessment Lead | | | | +| Technical Assessor | | | | + +--- + +#### Appendices + +**Appendix A — Evidence Collection** +[Screenshots, tool output, logs — one appendix section per finding] + +**Appendix B — Raw Scan Output** +[Full output of automated scanners, annotated with findings extracted] + +**Appendix C — Testing Timeline** +[Chronological log of testing activities by date and time, useful for incident investigation and demonstrating clean activity] + +| Date/Time | Activity | Target | Tool | Result | +|-----------|---------|--------|------|--------| +| | | | | | + +**Appendix D — Cleanup Log** +[Record of every artefact created during the test and confirmation of removal] + +| System | Artifact Created | Cleanup Action | Verified By | Date | +|--------|----------------|---------------|------------|------| +| | | | | | + +--- + +## Severity Classification Summary + +| Severity | CVSS Range | Remediation Timeframe | POA&M Required | +|---------|-----------|----------------------|---------------| +| Critical | 9.0–10.0 | Immediate (< 15 days) | Yes — immediate AO notification | +| High | 7.0–8.9 | 30 days | Yes | +| Moderate | 4.0–6.9 | 90 days | Yes | +| Low | 0.1–3.9 | 180 days | Yes | +| Informational | N/A | Best effort | No (SAR observation only) | + +**Note**: Where CVSS is not applicable (e.g., for configuration findings without a CVE), use the SP 800-30 likelihood x impact matrix to determine severity (see finding-severity.md in nist-sp-800-53a references). + +--- + +## Rules of Engagement Template + +Use this template to create the RoE document before testing begins. + +--- + +### Rules of Engagement — [SYSTEM NAME] Security Assessment + +**Date**: [DATE] +**Assessment Organisation**: [Name] +**Authorising Official**: [Name, Title, Organisation] + +#### Authorisation Statement + +[Authorising Official name and title] of [organisation] hereby authorises [assessment organisation] to conduct a security assessment of the systems and network segments defined below. This authorisation is valid for the period [START DATE] through [END DATE]. + +#### In-Scope Systems + +| Component | IP Range / Hostname | Assessment Types Permitted | +|-----------|--------------------|-----------------------------| +| | | Discovery, Scanning, Exploitation | +| | | Discovery, Scanning only (no exploitation) | + +#### Explicitly Out-of-Scope + +| System | Reason | +|--------|--------| +| Production payment processing environment | Risk of service disruption | +| Third-party hosted services | No authorisation from third party | + +#### Prohibited Actions + +The assessment team must not: +- [ ] Conduct denial-of-service testing against in-scope systems +- [ ] Exploit vulnerabilities in out-of-scope systems, even if discovered +- [ ] Access, copy, or retain any real user data (PII, PHI, financial) +- [ ] Share assessment findings or credentials outside the defined distribution list +- [ ] Test during [any restricted hours] + +#### Emergency Escalation + +If the assessment team discovers evidence of an ongoing attack or compromise unrelated to their testing: +1. Immediately stop all testing activity +2. Contact [POC Name, Phone] within 30 minutes +3. Preserve evidence of the finding +4. Do not attempt to remediate or remove the external attacker activity + +#### Data Handling + +All data collected during the assessment (tool output, captured credentials, screenshots) must be: +- Stored on encrypted media during the assessment +- Transmitted only over encrypted channels (no unencrypted email) +- Destroyed within [X days] after delivery of the final report + +#### Signatures + +| Role | Name | Signature | Date | +|------|------|----------|------| +| Authorising Official | | | | +| Assessment Team Lead | | | | +| System Owner | | | | diff --git a/plugins/nist-sp-800-137/.claude-plugin/plugin.json b/plugins/nist-sp-800-137/.claude-plugin/plugin.json new file mode 100644 index 0000000..51808d7 --- /dev/null +++ b/plugins/nist-sp-800-137/.claude-plugin/plugin.json @@ -0,0 +1,22 @@ +{ + "name": "nist-sp-800-137", + "version": "1.0.0", + "description": "NIST SP 800-137 Information Security Continuous Monitoring (ISCM) skill for defining, establishing, implementing, analyzing, responding to, and reviewing ISCM strategies and programmes across the three-tier organisation, mission/business process, and information system hierarchy.", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@gmail.com" + }, + "homepage": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "repository": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "ISCM", + "continuous-monitoring", + "information-security", + "risk-management", + "SCAP", + "security-metrics", + "ongoing-authorization", + "NIST" + ] +} diff --git a/plugins/nist-sp-800-137/skills/nist-sp-800-137/SKILL.md b/plugins/nist-sp-800-137/skills/nist-sp-800-137/SKILL.md new file mode 100644 index 0000000..a7a171f --- /dev/null +++ b/plugins/nist-sp-800-137/skills/nist-sp-800-137/SKILL.md @@ -0,0 +1,351 @@ +--- +name: nist-sp-800-137 +description: > + NIST SP 800-137 Information Security Continuous Monitoring (ISCM) skill. Answers questions about + designing and implementing ISCM strategies, defining monitoring frequencies, selecting security + metrics, establishing ISCM programmes, automating assessments using SCAP, ARF, and XCCDF, reporting + security status to authorizing officials, integrating ISCM with the Risk Management Framework Step 6, + defining roles and responsibilities for ISCM, analysing findings and responding to identified risks, + reviewing and updating ISCM strategies, three-tier ISCM architecture (organisation, mission/business + process, information system), ongoing authorization decisions, continuous diagnostics and mitigation, + and federal information system monitoring requirements under FISMA. +--- + +# NIST SP 800-137 — Information Security Continuous Monitoring (ISCM) + +**Source**: NIST Special Publication 800-137, September 2011 +**Full Title**: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations +**CSRC URL**: https://csrc.nist.gov/publications/detail/sp/800-137/final + +--- + +## Purpose and Scope + +NIST SP 800-137 provides guidance for the development and implementation of an organisation-wide Information Security Continuous Monitoring (ISCM) strategy and programme. The goal is to maintain ongoing awareness of information security, vulnerabilities, and threats to support organisational risk management decisions. + +ISCM gives officials the information they need to maintain awareness of information security risk, apply security controls to address that risk, and take appropriate corrective action. ISCM is not a replacement for periodic assessments; it supplements them with near-real-time status information. + +--- + +## Definition of ISCM + +ISCM is defined as: **maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions**. + +Three ISCM requirements: +1. **Situational awareness** — what assets exist, what controls are deployed, and the operational status of those controls +2. **Visibility** — current security state relative to threats, vulnerabilities, and organisational risk tolerance +3. **Traceability** — ability to track security state changes over time to support trend analysis + +--- + +## Three-Tier ISCM Architecture + +ISCM operates across three hierarchical tiers defined in NIST SP 800-39: + +### Tier 1 — Organisation Level +- Establishes the ISCM strategy +- Sets organisational risk tolerance and metrics +- Assigns roles and responsibilities +- Defines monitoring frequencies and aggregation approach +- Responsible officials: CIO, SAISO, Risk Executive (Function) + +### Tier 2 — Mission/Business Process Level +- Implements ISCM in support of mission/business functions +- Ensures security of information flows between systems +- Monitors common controls not assigned to individual systems +- Responsible officials: Mission/Business Process Owner, Common Control Provider + +### Tier 3 — Information System Level +- Implements system-level monitoring +- Monitors system-specific controls +- Reports status upward to Tier 2 and Tier 1 as required +- Responsible officials: Information System Owner (ISO), ISSO, System Security Engineer + +**Information flow**: Security status information flows from Tier 3 upward through Tier 2 to Tier 1. Risk decisions and guidance flow downward from Tier 1 through Tier 2 to Tier 3. + +--- + +## Six-Step ISCM Process + +### Step 1 — Define ISCM Strategy + +Define the ISCM strategy at the organisation level, specifying: +- Organisational risk tolerance +- Metrics to be monitored +- Monitoring frequencies +- Methods for data collection +- Analytical procedures +- Reporting requirements and formats + +The strategy must address all three tiers and be approved by senior leadership (CIO and/or Risk Executive Function). + +**Key outputs**: +- ISCM strategy document +- Risk tolerance statement +- Approved metrics catalogue + +### Step 2 — Establish ISCM Programme + +Establish the programme by: +- Selecting security metrics (implementation metrics, operational effectiveness metrics, risk management metrics) +- Assigning monitoring frequencies per control or metric +- Identifying automated and manual collection mechanisms +- Establishing reporting thresholds and escalation paths +- Selecting ISCM supporting tools and technologies + +**Key outputs**: +- Security metrics baseline +- Monitoring frequency schedule +- Tool inventory + +### Step 3 — Implement ISCM Programme + +Implement the programme by: +- Deploying tools and technologies (e.g., SCAP-validated scanners, log aggregators, SIEM) +- Executing automated collection processes +- Collecting manual assessment data not amenable to automation +- Establishing the data repository (security information repository) + +**Key outputs**: +- Operational ISCM tool set +- Security data feeds +- Data repository + +### Step 4 — Analyse and Report Findings + +Analyse collected data and report to appropriate officials: +- Compare results to established metrics and baselines +- Aggregate findings from Tier 3 through Tier 2 to Tier 1 +- Produce status reports at each tier +- Report to Authorizing Official (AO) for authorization decisions +- Provide trend analysis when historical data is available + +**Key outputs**: +- Security status reports (system, mission/business, organisational) +- Trend reports +- Updated system security plans (SSPs) reflecting current security status + +### Step 5 — Respond to Findings + +Respond to identified deficiencies and vulnerabilities: +- Update Plan of Action and Milestones (POA&M) for identified weaknesses +- Implement corrective actions within established remediation timeframes +- Apply risk responses: accept, avoid, mitigate, share/transfer +- Report significant changes to AO for authorization re-evaluation +- Document residual risk accepted by officials with authorisation authority + +**Key outputs**: +- Updated POA&M +- Corrective action documentation +- Risk acceptance decisions + +### Step 6 — Review and Update ISCM Strategy and Programme + +Periodically review and update the ISCM strategy and programme: +- Re-evaluate metrics against current threat landscape +- Adjust monitoring frequencies based on observed risk changes +- Update tools and technologies as needed +- Review effectiveness of the ISCM programme +- Revise the strategy document at the organisation level + +**Review triggers**: +- Significant changes to mission, organisation, or environment +- Significant system changes (major modifications) +- Identified deficiencies in the ISCM programme's effectiveness +- Changes in threat landscape or risk tolerance +- Periodic review (typically annual at a minimum) + +--- + +## Monitoring Frequencies + +Monitoring frequency is determined by the volatility of the information, the speed at which an adversary can exploit a vulnerability, and the CIA impact of the information or system. + +| Frequency | Definition | Example Use Cases | +|---|---|---| +| Ongoing (continuous) | Automated, near-real-time collection | Network traffic, event logs, IDS/IPS alerts, patch status | +| Daily | Collected and reviewed every business day | Vulnerability scan results, authentication failures, AV update status | +| Weekly | Collected and reviewed weekly | Configuration deviation reports, user access reviews for high-risk roles | +| Monthly | Collected and reviewed monthly | Configuration management baseline comparisons, account reviews | +| Quarterly | Collected and reviewed quarterly | Access control reviews, security training completion status | +| Annually | Collected and reviewed annually | Full security assessment, policy reviews, disaster recovery tests | + +**Frequency selection criteria**: +1. **Volatility**: How quickly does the security-relevant information change? +2. **Adversary speed**: How quickly can an adversary exploit a discovered vulnerability? +3. **CIA impact**: What is the potential loss if the control fails or the vulnerability is exploited? +4. **Automation feasibility**: Can the collection be automated or must it be manual? + +--- + +## Security Metrics + +Metrics must be measurable, actionable, and tied to risk management decisions. + +### Implementation Status Metrics +Measure whether security controls are deployed as planned: +- Percentage of systems with current patch levels (by criticality) +- Percentage of accounts with MFA enabled +- Percentage of systems with AV definitions current +- Percentage of configurations meeting approved baseline (configuration compliance rate) +- Percentage of users with current security awareness training (by role) + +### Operational Effectiveness Metrics +Measure whether deployed controls are operating as intended: +- Mean time to detect (MTTD) security events +- Mean time to respond (MTTR) to security incidents +- False positive and false negative rates for automated security tools +- Percentage of security events escalated vs. dismissed automatically +- Scan coverage rate (percentage of in-scope assets scanned) + +### Risk Management Metrics +Measure current risk posture: +- Number of open critical/high/medium/low vulnerabilities (by system, by mission) +- POA&M age distribution (time open by severity) +- Number of systems with current Authorization to Operate (ATO) +- Number of systems operating under Interim ATOs or expired ATOs +- Percentage of controls assessed in the last authorisation cycle + +**Metric attributes (for each metric)**: +- **Name**: Short descriptive name +- **Description**: What is being measured +- **Rationale**: Why is this important +- **Method**: How is data collected (automated tool, manual review) +- **Frequency**: How often collected +- **Threshold**: At what value is a finding triggered +- **Reporting level**: Tier 1/2/3 or all + +--- + +## Roles and Responsibilities + +### Chief Information Officer (CIO) +- Develops and maintains the organisation-wide ISCM strategy +- Ensures the ISCM programme is resourced +- Reports ISCM results to the head of agency as required + +### Senior Agency Information Security Officer (SAISO) +- Implements the ISCM strategy under CIO direction +- Manages the ISCM programme day-to-day +- Provides ISCM guidance to system owners and ISSOs + +### Risk Executive (Function) +- Establishes organisational risk tolerance +- Reviews aggregated ISCM findings at the organisation level +- Supports AO decisions based on ISCM data + +### Authorizing Official (AO) +- Uses ISCM data to make ongoing authorisation decisions +- Determines if residual risk is acceptable based on current security status +- Takes action when risk exceeds acceptable threshold (e.g., suspend authorisation) + +### Information System Owner (ISO) +- Ensures Tier 3 ISCM is implemented for assigned systems +- Reviews system-level ISCM results +- Initiates response actions for system-level findings +- Reports system-level security status to mission/business process owner + +### Information System Security Officer (ISSO) +- Executes day-to-day ISCM activities for assigned systems +- Operates and maintains ISCM tools at the system level +- Produces and transmits system-level security status reports +- Updates SSP and POA&M based on ISCM findings + +### Common Control Provider +- Monitors common (inherited) controls +- Reports common control status to all systems that inherit those controls +- Included in Tier 2 ISCM reporting + +--- + +## ISCM Tools and Technologies + +### Security Content Automation Protocol (SCAP) +SCAP is a set of specifications for automating security measurements and compliance checking: + +| SCAP Component | Function | +|---|---| +| CVE (Common Vulnerabilities and Exposures) | Standard vulnerability identifiers | +| CCE (Common Configuration Enumeration) | Standard configuration issue identifiers | +| CPE (Common Platform Enumeration) | Standard product/platform identifiers | +| CVSS (Common Vulnerability Scoring System) | Severity scoring for vulnerabilities | +| OVAL (Open Vulnerability and Assessment Language) | Machine-readable system state descriptions | +| XCCDF (Extensible Configuration Checklist Description Format) | Machine-readable security checklists | + +### Asset Reporting Format (ARF) +ARF (NISTIR 7694) provides a standard format for expressing information about assets and reporting the relationship between assets and security-relevant information. ARF enables aggregation of results from multiple SCAP tools. + +### Automation Capability Levels +| Level | Description | Use | +|---|---|---| +| Fully automated | No human intervention; tool collects and reports data | Patch status, AV definitions, port scanning | +| Semi-automated | Tools collect data; human analysis required | Log review, vulnerability scan triage | +| Fully manual | Human must perform all collection and analysis | Social engineering tests, physical security reviews | + +--- + +## Integration with RMF + +ISCM implements RMF Step 6 (Monitor) from NIST SP 800-37 Rev 2: + +| RMF Step 6 Task | ISCM Corresponding Action | +|---|---| +| TASK M-1: System and Environment Changes | ISCM monitors for significant changes triggering re-authorisation | +| TASK M-2: Ongoing Assessments | ISCM provides continuous assessment of selected controls | +| TASK M-3: Ongoing Risk Response | ISCM Step 5 (Respond) provides corrective action and POA&M update | +| TASK M-4: Authorisation Package Updates | ISCM findings update SSP and SAR | +| TASK M-5: Security and Privacy Reporting | ISCM Step 4 (Analyse/Report) provides Tier 1, 2, 3 reporting | +| TASK M-6: Ongoing Authorisation | AO uses ISCM data for ongoing authorisation decisions | +| TASK M-7: System Disposal | ISCM terminates when system is decommissioned | + +**Ongoing Authorisation**: ISCM enables an AO to grant an ongoing authorisation (previously "continuous ATO") rather than a time-bound authorisation. The AO establishes a maximum acceptable risk threshold; ISCM monitors whether current risk stays within that threshold. If risk exceeds the threshold, the AO takes action. + +--- + +## ISCM Strategy Document + +An ISCM strategy document at the organisation level must address: + +1. **Scope**: Systems, assets, and environments covered +2. **Risk tolerance**: Organisational acceptable risk level +3. **Metrics catalogue**: Approved set of metrics with attributes +4. **Monitoring frequency assignments**: Frequency per metric or control +5. **Data collection mechanisms**: Tool inventory and methods per metric +6. **Aggregation procedures**: How Tier 3 data rolls up to Tier 2 and Tier 1 +7. **Analysis procedures**: How findings are evaluated against thresholds +8. **Reporting formats and frequencies**: Standard report formats and distribution +9. **Roles and responsibilities**: Per SP 800-137 Table 1 +10. **Review and update cycle**: How often the strategy itself is reviewed + +--- + +## Significant Changes Requiring Re-evaluation + +The following changes trigger re-evaluation of authorisation or ISCM strategy: +- Installation of new or replacement hardware, software, or firmware +- Changes to mission, business functions, or organisational priorities +- Change in authorising official +- Changes to applicable laws, regulations, or policy +- Changes to the operational environment (e.g., new threat disclosures, new vulnerabilities) +- Changes to the security plan (e.g., changes to common controls) +- Deficiencies found through ISCM (findings that exceed accepted risk thresholds) + +--- + +## ISCM and FISMA Compliance + +FISMA (Federal Information Security Modernization Act) requires federal agencies to implement a programme of continuous monitoring. NIST SP 800-137 provides the guidance to fulfil this requirement. + +Key FISMA connections: +- OMB Circular A-130 requires ISCM programmes for federal agencies +- OMB memoranda (e.g., M-14-03) require CDM (Continuous Diagnostics and Mitigation) programme participation +- Annual reporting to OMB and Congress uses ISCM data (CyberStat, FISMA metrics) +- DHS CDM programme provides tools and dashboards for ISCM capabilities + +--- + +## Reference Files + +- `references/iscm-process.md` — Detailed six-step ISCM process with task checklists, input/output tables, and step-by-step procedures +- `references/monitoring-strategy.md` — ISCM strategy structure, frequency assignment guidance, control selection rationale, and programme establishment procedures +- `references/metrics-reporting.md` — Security metrics catalogue format, reporting templates, aggregation procedures, and AO reporting formats diff --git a/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/iscm-process.md b/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/iscm-process.md new file mode 100644 index 0000000..5d04f1c --- /dev/null +++ b/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/iscm-process.md @@ -0,0 +1,321 @@ +# NIST SP 800-137 — ISCM Six-Step Process Detail + +**Source**: NIST SP 800-137, September 2011, Sections 3–8 + +--- + +## Overview + +The ISCM process is a six-step cycle. It is not a one-time activity but an ongoing programme that is continually refined. The cycle operates simultaneously at Tier 1 (Organisation), Tier 2 (Mission/Business Process), and Tier 3 (Information System), with information flowing upward and guidance flowing downward across tiers. + +--- + +## Step 1 — Define ISCM Strategy + +### Inputs +- Organisational mission and business objectives +- Applicable laws, regulations, and policies (FISMA, NIST publications, OMB circulars) +- Existing risk management programme documentation +- Inventory of information systems (from SP 800-37 RMF Step 1) + +### Tasks + +**Task 1.1 — Establish Organisational Risk Tolerance** +- Define quantitative or qualitative acceptable risk thresholds +- Document risk tolerance by system impact level (Low, Moderate, High) +- Obtain approval from head of agency or designated official (Risk Executive Function) + +**Task 1.2 — Define ISCM Metrics** +- Identify metrics aligned with organisational risk priorities +- Include implementation metrics, operational effectiveness metrics, and risk management metrics +- Define attributes per metric (name, description, rationale, method, frequency, threshold, reporting level) +- Document approved metrics in an ISCM metrics catalogue + +**Task 1.3 — Define Monitoring Frequencies** +- Assign frequency (ongoing/continuous, daily, weekly, monthly, quarterly, annual) per metric or SP 800-53 control +- Base frequency on volatility, adversary speed, and CIA impact (see frequency criteria) +- Prioritise automation for high-frequency metrics + +**Task 1.4 — Define Collection, Analysis, and Reporting Procedures** +- Identify data collection mechanisms per metric (tool, manual procedure) +- Define aggregation procedures for rolling Tier 3 data to Tier 2 and Tier 1 +- Define report formats, distribution lists, and escalation paths +- Define threshold-based alerting for out-of-compliance conditions + +**Task 1.5 — Define Roles and Responsibilities** +- Assign ISCM roles to named positions (CIO, SAISO, Risk Executive Function, AO, ISO, ISSO, Common Control Provider) +- Document accountability for each ISCM task +- Define escalation procedures + +### Outputs +- Approved ISCM strategy document +- Metrics catalogue +- Monitoring frequency schedule +- Roles and responsibilities matrix + +--- + +## Step 2 — Establish ISCM Programme + +### Inputs +- Approved ISCM strategy (Step 1) +- System security plans and current security assessment results +- System and common control inventory + +### Tasks + +**Task 2.1 — Select and Implement ISCM Tools** +- Identify tools capable of automated data collection per approved metrics +- Validate tools against SCAP specifications where applicable (OVAL, XCCDF, ARF) +- Ensure tools support the monitoring frequencies defined in the strategy +- Address tool coverage gaps with manual procedures + +**Task 2.2 — Establish Security Data Repository** +- Deploy or designate a repository for ISCM-collected data +- Ensure data integrity, availability, and appropriate access controls +- Define retention periods aligned to reporting and trend analysis requirements +- Implement data normalisation if aggregating from multiple tools + +**Task 2.3 — Establish Baselines** +- Define approved configuration baselines (using NIST SP 800-70 National Checklists where applicable) +- Document approved software lists per system +- Document approved network topology and trust boundaries +- Establish patch compliance baseline (current approved patch state) + +**Task 2.4 — Establish Reporting Thresholds** +- Define numeric thresholds per metric (e.g., patch compliance below 95% triggers finding) +- Define escalation thresholds (e.g., critical vulnerability unpatched > 30 days requires AO notification) +- Document exception and risk acceptance procedures + +### Outputs +- ISCM tool inventory with coverage mapping +- Security data repository operational +- Documented baselines +- Reporting thresholds and escalation procedures + +--- + +## Step 3 — Implement ISCM Programme + +### Inputs +- Established ISCM programme (Step 2) +- System security plans and authorisation packages + +### Tasks + +**Task 3.1 — Execute Automated Collections** +- Run scheduled automated scans and collections per frequency schedule +- Collect data across all in-scope systems (Tier 3) and aggregation points (Tier 2) +- Archive raw collection results in the security data repository + +**Task 3.2 — Execute Manual Collections** +- Execute manual assessment procedures for controls not amenable to automation +- Document manual collection results in standardised format +- Ensure manual collection is performed at the approved frequency + +**Task 3.3 — Collect Common Control Status** +- Common Control Providers collect and report status for inherited controls +- Data feeds into Tier 2 and Tier 1 aggregation + +**Task 3.4 — Maintain ISCM Tool Set** +- Update tool signatures, definitions, and configurations +- Validate tool outputs periodically to ensure accuracy (no false positives, no missed assets) +- Maintain tool inventory currency + +### Outputs +- Security data repository populated with current collections +- Raw assessment results archived +- Common control status feeds operational + +--- + +## Step 4 — Analyse and Report Findings + +### Inputs +- Security data from Step 3 +- Approved baselines and thresholds from Step 2 +- Prior reporting cycle data (for trend analysis) + +### Tasks + +**Task 4.1 — Analyse Collected Data** +- Compare results to baselines and detection thresholds +- Identify findings (deviations from baseline; unpatched vulnerabilities; misconfigurations) +- Classify findings by severity (Critical, High, Medium, Low) using CVSS and SP 800-30 risk approach +- Correlate findings across metrics (e.g., unpatched critical CVE on an internet-facing system) + +**Task 4.2 — Produce System-Level Reports (Tier 3)** +- Document findings per system +- Include metric status (compliant/non-compliant), finding details, trend delta from prior cycle +- Transmit to ISO and ISSO; copy to Tier 2 aggregation + +**Standard Tier 3 Security Status Report Contents**: +| Section | Content | +|---|---| +| System identification | Name, system identifier, FIPS 199 impact level, AO | +| Reporting period | Start and end dates; collection timestamps | +| Metric status summary | Table of all metrics: metric name, threshold, current value, status (pass/fail) | +| Findings | New findings; sustained findings; resolved findings | +| Trend analysis | Delta from prior period per metric | +| POA&M status | Open items, closed this period, newly opened | +| Significant changes | Any Tier 3 significant changes since last report | + +**Task 4.3 — Aggregate to Mission/Business Process Level (Tier 2)** +- Aggregate Tier 3 reports for all systems supporting the mission/business process +- Identify cross-system trends or common vulnerabilities across the portfolio +- Report to Mission/Business Process Owner and Common Control Provider + +**Task 4.4 — Aggregate to Organisation Level (Tier 1)** +- CIO/SAISO aggregates Tier 2 reports +- Produce organisation-wide security status dashboard +- Present to Risk Executive Function and AO +- Update OMB FISMA reporting data (CyberStat/FISMA metrics) + +**Task 4.5 — AO Reporting** +- Provide AO with current system risk posture based on ISCM data +- Highlight any findings that may affect the authorisation decision +- AO determines if residual risk remains within accepted threshold + +### Outputs +- Tier 3 security status reports (system level) +- Tier 2 aggregated reports (mission/business process level) +- Tier 1 organisation-level security status dashboard +- AO notification where findings exceed threshold +- Updated FISMA reporting data + +--- + +## Step 5 — Respond to Findings + +### Inputs +- Findings from Step 4 +- Current POA&M +- Risk acceptance decisions + +### Tasks + +**Task 5.1 — Update POA&M** +- Open new POA&M items for newly identified findings +- Track findings by: weakness description, affected system, responsible party, estimated completion date, current status +- Close POA&M items for findings resolved in current cycle +- Escalate overdue high/critical items to ISSO and ISO + +**Remediation Timeframe Guidance**: +| Severity | Maximum Time to Remediate | +|---|---| +| Critical | 15 days (or immediate AO notification and risk acceptance) | +| High | 30 days | +| Medium | 90 days | +| Low | 180 days or accepted as residual risk | + +**Task 5.2 — Apply Risk Responses** +- Mitigate: apply patches, correct configuration, implement additional controls +- Accept: document risk acceptance by authorised official with rationale and re-evaluation date +- Avoid: retire system component or capability generating the risk +- Transfer/Share: use shared services or transfer responsibility where permitted + +**Task 5.3 — Report Significant Changes to AO** +- Report any finding that introduces risk outside the accepted threshold to the AO immediately +- AO reviews and determines action (continue authorisation, accept additional risk, suspend or revoke authorisation) + +**Task 5.4 — Update SSP and Authorisation Package** +- Reflect current security state, open findings, and risk acceptance decisions in SSP +- Update SAR findings if formal reassessment occurred +- Update POA&M and transmit updated authorisation package to AO repository + +### Outputs +- Updated POA&M +- Remediation action documentation +- Risk acceptance records +- Updated SSP and authorisation package + +--- + +## Step 6 — Review and Update ISCM Strategy and Programme + +### Inputs +- ISCM strategy and programme documentation +- Findings from prior cycles +- Changes in mission, threats, or organisational risk tolerance + +### Tasks + +**Task 6.1 — Review ISCM Programme Effectiveness** +- Assess whether current metrics are capturing meaningful security information +- Review whether monitoring frequencies are appropriate given observed threat activity +- Identify controls or metrics with persistent findings (indicates systemic issue, not monitoring gap) +- Review tool coverage gaps and automation opportunities + +**Task 6.2 — Review Organisational Risk Tolerance** +- Confirm with Risk Executive Function whether risk tolerance has changed +- Update strategy document if tolerance thresholds have changed + +**Task 6.3 — Update the ISCM Strategy** +- Revise metrics catalogue (add, remove, modify metrics) +- Revise frequency assignments +- Revise reporting formats and distribution +- Obtain re-approval from CIO and Risk Executive Function + +**Task 6.4 — Update the ISCM Programme** +- Update tool configurations and baselines +- Update data collection procedures and thresholds +- Re-train ISCM personnel on changed procedures + +### Review Triggers (event-driven, in addition to periodic review) +| Trigger | Action | +|---|---| +| New threat intelligence (e.g., new CVE campaign) | Review frequency for affected controls; increase if warranted | +| Significant system change (major modification) | Re-evaluate Tier 3 monitoring for changed system | +| New organisational mission | Review Tier 2 metrics for new mission/business process | +| Persistent POA&M findings | Review whether monitoring is detecting root cause | +| FISMA reporting gap | Review if ISCM data is satisfying federal reporting requirements | +| Annual review (minimum) | Full periodic review of strategy and programme | + +### Outputs +- Updated and re-approved ISCM strategy +- Updated ISCM programme documentation +- Updated tool configurations and baselines + +--- + +## ISCM Process Checklist + +### Step 1 — Define Strategy +- [ ] Risk tolerance documented and approved +- [ ] Metrics catalogue defined with all required attributes +- [ ] Monitoring frequencies assigned per metric +- [ ] Collection, analysis, and reporting procedures documented +- [ ] Roles and responsibilities matrix complete and approved +- [ ] ISCM strategy document approved by CIO/Risk Executive Function + +### Step 2 — Establish Programme +- [ ] ISCM tools selected and validated (SCAP where applicable) +- [ ] Security data repository established with access controls +- [ ] Configuration and software baselines documented +- [ ] Reporting thresholds and escalation procedures defined +- [ ] Coverage gaps identified and manual procedures established + +### Step 3 — Implement Programme +- [ ] Automated collections executing on schedule +- [ ] Manual collections being performed per frequency +- [ ] Common control feeds operational +- [ ] Tool maintenance procedures in place + +### Step 4 — Analyse and Report +- [ ] Tier 3 reports produced per reporting cycle +- [ ] Tier 2 aggregation completed +- [ ] Tier 1 dashboard updated +- [ ] AO notified of threshold-exceeding findings +- [ ] FISMA reporting data updated + +### Step 5 — Respond +- [ ] POA&M updated with new and resolved findings +- [ ] Remediation actions tracked within timeframes +- [ ] Risk acceptances documented with authorised signatures +- [ ] SSP and authorisation package updated + +### Step 6 — Review +- [ ] ISCM programme effectiveness reviewed +- [ ] Risk tolerance confirmed with Risk Executive Function +- [ ] Strategy and programme updated as needed +- [ ] Updates approved by CIO/Risk Executive Function diff --git a/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/metrics-reporting.md b/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/metrics-reporting.md new file mode 100644 index 0000000..50b9a58 --- /dev/null +++ b/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/metrics-reporting.md @@ -0,0 +1,418 @@ +# NIST SP 800-137 — Security Metrics, Reporting Templates, and Aggregation Procedures + +**Source**: NIST SP 800-137, September 2011, Sections 2.4, 4 (Analyse/Report), Appendix A + +--- + +## Security Metrics + +### Metric Attribute Set + +Every ISCM metric must be documented with the following attributes: + +| Attribute | Description | +|---|---| +| Metric ID | Unique identifier (e.g., ISCM-CM-001) | +| Name | Short descriptive name | +| Control Mapping | SP 800-53 Rev 5 control ID (e.g., CM-6) | +| Description | What is being measured and why it matters | +| Measurement | How the metric value is calculated (formula or procedure) | +| Data Source | Tool or procedure that collects the data | +| Collection Frequency | How often data is collected (continuous/daily/weekly/monthly/quarterly/annual) | +| Reporting Frequency | How often metric appears in reports | +| Threshold | Value at which a finding is triggered (e.g., < 95% compliance = finding) | +| Reporting Level | Tier 1 only, Tier 2+, or all tiers | +| Owner | Role responsible for this metric (e.g., ISSO) | + +--- + +## ISCM Metrics Catalogue + +### Implementation Status Metrics + +**ISCM-SI-001 — Patch Compliance Rate (Critical)** +- Control: SI-2 +- Description: Percentage of systems with critical vulnerabilities (CVSS >= 9.0) patched within 15 calendar days of patch release +- Measurement: (Systems with critical CVEs remediated within SLA / Total systems with critical CVEs) x 100 +- Data Source: Authenticated vulnerability scanner +- Frequency: Daily +- Threshold: >= 95% compliant; < 95% = finding; < 80% = escalation to AO + +**ISCM-SI-002 — Patch Compliance Rate (High)** +- Control: SI-2 +- Description: Percentage of systems with high vulnerabilities (CVSS 7.0–8.9) patched within 30 calendar days +- Measurement: (Systems with high CVEs remediated within SLA / Total systems with high CVEs) x 100 +- Data Source: Authenticated vulnerability scanner +- Frequency: Weekly +- Threshold: >= 90% compliant; < 90% = finding + +**ISCM-SI-003 — Anti-Virus Definition Currency** +- Control: SI-3 +- Description: Percentage of managed endpoints with AV definitions current (within 24 hours of latest release) +- Measurement: (Endpoints with current AV definitions / Total managed endpoints) x 100 +- Data Source: Endpoint management platform / AV management console +- Frequency: Daily +- Threshold: >= 98% compliant; < 98% = finding + +**ISCM-CM-001 — Configuration Compliance Rate** +- Control: CM-6 +- Description: Percentage of scanned systems in compliance with approved SCAP/XCCDF configuration baseline +- Measurement: (Systems with passing XCCDF results / Total scanned systems) x 100 +- Data Source: SCAP-validated configuration scanner +- Frequency: Weekly +- Threshold: >= 90% compliant; < 90% = finding; < 80% = escalation + +**ISCM-CM-002 — Unauthorised Software Detected** +- Control: CM-7 +- Description: Number of systems with software detected that is not on the approved software list +- Measurement: Count of systems with one or more unapproved software packages +- Data Source: Software inventory scanner / Endpoint management +- Frequency: Weekly +- Threshold: 0 systems; any = finding + +**ISCM-AC-001 — Inactive Account Rate** +- Control: AC-2 +- Description: Percentage of active accounts with no logon activity in past 30 days +- Measurement: (Accounts with zero logins in 30 days / Total active accounts) x 100 +- Data Source: Directory service (AD/LDAP) query +- Frequency: Weekly +- Threshold: <= 2%; > 2% = finding (inactive accounts should be disabled or deleted) + +**ISCM-AC-002 — Multi-Factor Authentication Coverage** +- Control: IA-2(1) +- Description: Percentage of privileged accounts enrolled in MFA +- Measurement: (Privileged accounts with MFA enabled / Total privileged accounts) x 100 +- Data Source: Identity provider / MFA platform +- Frequency: Weekly +- Threshold: 100% required; any gap = critical finding + +**ISCM-AT-001 — Security Awareness Training Completion** +- Control: AT-2 +- Description: Percentage of personnel who have completed required annual security awareness training +- Measurement: (Personnel with current training completion / Total required personnel) x 100 +- Data Source: Learning Management System (LMS) +- Frequency: Monthly +- Threshold: >= 95%; < 95% = finding + +**ISCM-AT-002 — Role-Based Training Completion** +- Control: AT-3 +- Description: Percentage of personnel in security-relevant roles with current role-based training +- Measurement: (Security-role personnel with current role training / Total security-role personnel) x 100 +- Data Source: LMS +- Frequency: Quarterly +- Threshold: 100%; any gap = finding + +**ISCM-AU-001 — Audit Log Coverage** +- Control: AU-2 +- Description: Percentage of in-scope systems with audit logging operational and forwarding to central log management +- Measurement: (Systems forwarding logs to SIEM / Total in-scope systems) x 100 +- Data Source: SIEM log reception status +- Frequency: Daily +- Threshold: 100%; any gap = finding + +### Operational Effectiveness Metrics + +**ISCM-IR-001 — Mean Time to Detect (MTTD)** +- Control: IR-4, SI-4 +- Description: Average time (hours) from security event occurrence to detection by monitoring tools or personnel +- Measurement: Sum of (detection time - occurrence time) for all detected events / count of events +- Data Source: Incident tracking system +- Frequency: Monthly +- Threshold: Organisationally defined; typically < 24 hours for High/Critical events + +**ISCM-IR-002 — Mean Time to Respond (MTTR)** +- Control: IR-4 +- Description: Average time (hours) from incident detection to containment +- Measurement: Sum of (containment time - detection time) for all incidents / count of incidents +- Data Source: Incident tracking system +- Frequency: Monthly +- Threshold: Organisationally defined; typically < 1 hour for Critical, < 4 hours for High + +**ISCM-RA-001 — Vulnerability Scan Coverage** +- Control: RA-5 +- Description: Percentage of in-scope systems scanned in the current reporting period +- Measurement: (Systems scanned / Total in-scope systems) x 100 +- Data Source: Vulnerability scanner scan history +- Frequency: Weekly +- Threshold: 100%; any gap = finding + +### Risk Management Metrics + +**ISCM-CA-001 — Systems with Current ATO** +- Control: CA-6 +- Description: Percentage of operational systems with a current, non-expired Authorization to Operate +- Measurement: (Systems with current ATO / Total operational systems) x 100 +- Data Source: ATO tracking register +- Frequency: Monthly +- Threshold: 100%; expired ATOs = finding; operating without ATO = critical finding + +**ISCM-CA-002 — Open Critical/High POA&M Items** +- Control: CA-5 +- Description: Number of open POA&M items at Critical or High severity beyond their scheduled completion date +- Measurement: Count of overdue Critical/High POA&M items +- Data Source: POA&M tracking system +- Frequency: Weekly +- Threshold: 0; any = finding; >5 or any >90 days overdue = escalation to AO + +--- + +## Reporting Templates + +### Tier 3 — System-Level Security Status Report + +``` +================================================== +INFORMATION SECURITY CONTINUOUS MONITORING +SYSTEM-LEVEL SECURITY STATUS REPORT +================================================== + +SYSTEM IDENTIFICATION +--------------------- +System Name: [Name] +System ID: [Unique identifier / FISMA system inventory ID] +FIPS 199 Impact Level: [Low | Moderate | High] +Authorizing Official: [Name, title] +System Owner: [Name, title] +ISSO: [Name, contact] +Report Period: [Start date] to [End date] +Collection Date: [Date of data collection] + +EXECUTIVE SUMMARY +----------------- +Overall Compliance Status: [ COMPLIANT | NON-COMPLIANT | AT RISK ] +Metrics in Scope: [n] +Metrics Passing: [n] +Metrics Failing: [n] +New Findings This Period: [n] +Resolved Findings: [n] +Open POA&M Items: [n Critical | n High | n Medium | n Low] +ATO Status: [Current; Expiration: YYYY-MM-DD | Expired | Ongoing] + +METRIC STATUS SUMMARY +--------------------- +| Metric ID | Metric Name | Threshold | Current Value | Status | +|---|---|---|---|---| +| ISCM-SI-001 | Critical Patch Compliance | >= 95% | [value]% | PASS/FAIL | +| ISCM-SI-002 | High Patch Compliance | >= 90% | [value]% | PASS/FAIL | +| ISCM-SI-003 | AV Definition Currency | >= 98% | [value]% | PASS/FAIL | +| ISCM-CM-001 | Configuration Compliance | >= 90% | [value]% | PASS/FAIL | +| ISCM-CM-002 | Unauthorised Software | 0 systems | [count] | PASS/FAIL | +| ISCM-AC-001 | Inactive Accounts | <= 2% | [value]% | PASS/FAIL | +| ISCM-AC-002 | MFA Coverage (Privileged) | 100% | [value]% | PASS/FAIL | +| ISCM-AU-001 | Audit Log Coverage | 100% | [value]% | PASS/FAIL | +| ISCM-RA-001 | Vulnerability Scan Coverage | 100% | [value]% | PASS/FAIL | +| ISCM-CA-001 | Current ATO | 100% | [value]% | PASS/FAIL | + +FINDINGS +-------- +New Findings This Period: + +Finding ID: [System ID]-ISCM-[YYYY-MM-DD]-[NN] +Title: [Short description] +Metric: [Metric ID] +Severity: [Critical | High | Medium | Low] +Description: [Detailed description of the finding] +Evidence: [Tool, scan ID, or manual procedure reference] +Risk: [Risk description — potential impact if not remediated] +Recommended Action: [Specific remediation step] +Scheduled Completion: [Date] +POA&M Reference: [POA&M item ID if opened] + +Sustained Findings (carried from prior period): +[List with original date, current status, and delta] + +Resolved Findings: +[List with original date and resolution description] + +TREND ANALYSIS +-------------- +| Metric ID | Prior Period | Current Period | Delta | Trend | +|---|---|---|---|---| +| ISCM-SI-001 | [value]% | [value]% | [+/-]% | UP/DOWN/STABLE | +[...repeat for each metric...] + +POA&M STATUS SUMMARY +-------------------- +| POA&M ID | Weakness | Severity | Scheduled Completion | Status | +|---|---|---|---|---| +| [ID] | [Description] | [Sev] | [Date] | Open / Overdue / Closed | + +SIGNIFICANT CHANGES +------------------- +[Description of any significant changes to the system, environment, or controls since last report; +if none, state: No significant changes this reporting period.] + +ATTESTATION +----------- +I certify that the information in this report accurately reflects the current security status +of the system based on ISCM data collected during the reporting period. + +ISSO Signature: _________________________ Date: ___________ +ISO Signature: _________________________ Date: ___________ +``` + +--- + +### Tier 2 — Mission/Business Process Aggregated Report + +``` +================================================== +INFORMATION SECURITY CONTINUOUS MONITORING +MISSION/BUSINESS PROCESS SECURITY STATUS REPORT +================================================== + +PROGRAMME IDENTIFICATION +------------------------ +Mission/Business Process: [Name] +Process Owner: [Name, title] +Systems in Scope: [List of system names/IDs] +Report Period: [Start date] to [End date] +Prepared By: [Name, role] + +PORTFOLIO SUMMARY +----------------- +Total Systems in Portfolio: [n] +Systems Compliant (all metrics pass): [n] ([%]) +Systems Non-Compliant (1+ failures): [n] ([%]) +Systems At Risk (critical/escalation): [n] ([%]) + +METRIC COMPLIANCE BY SYSTEM +---------------------------- +| System | ATO Status | Patch(Crit) | Patch(High) | Config | AV | MFA | Scan Cov | Overall | +|---|---|---|---|---|---|---|---|---| +| [Sys1] | Current | PASS | PASS | FAIL | PASS | PASS | PASS | MIXED | +[...repeat for each system...] + +CROSS-SYSTEM FINDINGS +--------------------- +[Findings that appear across multiple systems — may indicate shared service issue, +common vulnerability, or systemic gap. List finding category and affected systems.] + +COMMON CONTROL STATUS +--------------------- +| Common Control Provider | Control ID | Status | Notes | +|---|---|---|---| +| [Provider] | AC-2 (Account management) | PASS | [Notes] | +[...repeat for each common control...] + +OPEN POA&M ITEMS (CRITICAL AND HIGH) +-------------------------------------- +| POA&M ID | System | Weakness | Severity | Due Date | Status | +|---|---|---|---|---|---| +| [ID] | [System] | [Description] | [Sev] | [Date] | Open/Overdue | + +TREND SUMMARY +------------- +[Qualitative summary of security posture trends across the portfolio this period] + +RISK SUMMARY FOR AUTHORIZING OFFICIAL +-------------------------------------- +[Narrative summary of current risk posture. Identify whether aggregate risk is within +accepted threshold. Identify any systems or findings requiring AO attention.] +``` + +--- + +### Tier 1 — Organisation-Level Dashboard Summary + +``` +================================================== +INFORMATION SECURITY CONTINUOUS MONITORING +ORGANISATION-LEVEL SECURITY STATUS DASHBOARD +================================================== + +REPORTING PERIOD: [Start date] to [End date] +PREPARED BY: [SAISO / CIO designee] +DISTRIBUTION: CIO, Risk Executive Function, Authorizing Officials + +PORTFOLIO OVERVIEW +------------------ +Total Federal Information Systems: [n] +Systems with Current ATO: [n] ([%]) +Systems with Expired ATO: [n] ([%]) +Systems with Ongoing Authorisation: [n] ([%]) + +KEY ISCM METRICS — ORGANISATION AVERAGE +----------------------------------------- +| Metric | Prior Period | Current Period | Threshold | Status | +|---|---|---|---|---| +| Critical Patch Compliance | [%] | [%] | >= 95% | PASS/FAIL | +| High Patch Compliance | [%] | [%] | >= 90% | PASS/FAIL | +| Config Compliance | [%] | [%] | >= 90% | PASS/FAIL | +| MFA Coverage (Priv) | [%] | [%] | 100% | PASS/FAIL | +| Scan Coverage | [%] | [%] | 100% | PASS/FAIL | +| AT Completion | [%] | [%] | >= 95% | PASS/FAIL | + +OPEN POA&M ITEMS +---------------- +Critical (overdue): [n] +High (overdue): [n] +Total Open: [n] + +RISK POSTURE SUMMARY +-------------------- +[Concise narrative. Is the organisation within accepted risk tolerance? +Any systemic issues? Any items requiring head-of-agency attention?] + +ITEMS REQUIRING CIO/RISK EXECUTIVE FUNCTION ACTION +---------------------------------------------------- +[List of items requiring decision or action at Tier 1] + +FISMA REPORTING DATA +-------------------- +[Current values for OMB FISMA metrics as required by OMB memorandum] +``` + +--- + +## AO Security Status Notification + +When findings exceed the accepted risk threshold, the ISSO or SAISO notifies the AO: + +``` +TO: [Authorizing Official Name, Title] +FROM: [ISSO / SAISO Name, Title] +DATE: [Date] +RE: ISCM Risk Threshold Exceeded — System [System Name/ID] + +This notification is being provided pursuant to the ISCM strategy requirement to notify the +Authorizing Official when current risk exceeds the accepted threshold. + +SYSTEM: [Name / System ID] +FINDING SUMMARY: [Brief description of finding] +METRIC EXCEEDED: [Metric ID and Name] +CURRENT VALUE: [Value] — Threshold: [Threshold] +SEVERITY: [Critical | High] +RISK DESCRIPTION: [Nature of the risk, potential impact] +CURRENT CONTROLS: [What is in place; why the gap exists] +PROPOSED RESPONSE: + - Option 1: [Remediation — description, estimated completion date] + - Option 2: [Risk acceptance — specific risk accepted, compensating controls] + - Option 3: [Avoid/Transfer if applicable] + +RECOMMENDED ACTION: [ISSO/SAISO recommendation] +DEADLINE FOR AO DECISION: [Date — based on risk severity] + +Attachments: [Tier 3 report, scan evidence, POA&M extract] +``` + +--- + +## POA&M Format + +``` +| Field | Content | +|---|---| +| POA&M ID | [System ID]-POA-[YYYY]-[NN] | +| Weakness Description | [Specific finding description — measurable and actionable] | +| Affected System | [System name / ID] | +| Point of Contact | [ISSO name and contact] | +| Resources Required | [Personnel time, tools, budget estimate if applicable] | +| Scheduled Completion Date | [YYYY-MM-DD — based on severity SLA] | +| Actual Completion Date | [YYYY-MM-DD when completed; blank if open] | +| Milestone Changes | [Log of any date changes with justification] | +| Source | [ISCM finding ID, assessment finding ID, or self-identified] | +| Status | Open | In Remediation | Completed | Risk Accepted | +| Risk Acceptance Justification | [Required if Status = Risk Accepted; includes approving official and date] | +| Compensating Control | [If any; description and expected effectiveness] | +``` diff --git a/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/monitoring-strategy.md b/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/monitoring-strategy.md new file mode 100644 index 0000000..d7e1035 --- /dev/null +++ b/plugins/nist-sp-800-137/skills/nist-sp-800-137/references/monitoring-strategy.md @@ -0,0 +1,228 @@ +# NIST SP 800-137 — ISCM Strategy and Monitoring Programme Establishment + +**Source**: NIST SP 800-137, September 2011, Sections 2.3, 3, 4, Appendix B + +--- + +## ISCM Strategy Document Structure + +The ISCM strategy is an organisation-level document approved by the CIO and/or Risk Executive Function. It governs the entire ISCM programme across all three tiers. + +### Required Sections + +**Section 1 — Introduction and Purpose** +- Organisation name and information system scope +- ISCM programme purpose and alignment to FISMA, OMB A-130, and applicable policies +- Relationship to the organisation's RMF and risk management programme + +**Section 2 — Governance and Roles** +- Named roles per SP 800-137 Table 1 (CIO, SAISO, Risk Executive Function, AOs, ISOs, ISSOs, Common Control Providers) +- Accountability mapping (who is responsible for each ISCM task at each tier) +- Escalation chain + +**Section 3 — Risk Tolerance** +- Organisational acceptable risk threshold (qualitative: Low/Moderate/High, or quantitative where defined) +- Risk tolerance by system impact level (FIPS 199 Low, Moderate, High) +- Conditions under which the AO will revoke or suspend authorisation + +**Section 4 — Metrics Catalogue (by reference or included)** +- All approved ISCM metrics with full attribute sets +- Traceability to SP 800-53 Rev 5 control families + +**Section 5 — Monitoring Frequency Schedule** +- Complete table mapping each metric to its assigned frequency +- Frequency basis (automation-driven, schedule-driven, event-driven) + +**Section 6 — Data Collection Architecture** +- Tool inventory (name, type, SCAP validation status, coverage) +- Collection schedule +- Security data repository location and access controls +- Data retention periods + +**Section 7 — Aggregation and Reporting** +- Tier 3 → Tier 2 → Tier 1 data flow description +- Report formats and templates (by reference to templates) +- Report distribution (who receives what level of report) +- Reporting frequency per tier + +**Section 8 — Response Procedures** +- Remediation timeframe table (Critical/High/Medium/Low) +- Risk acceptance authority at each tier +- POA&M management procedures +- AO notification triggers + +**Section 9 — Review and Update Cycle** +- Periodic review frequency (minimum annual) +- Event-driven review triggers +- Approval process for strategy updates + +**Section 10 — Document Control** +- Version number, approval date, approving official, next review date + +--- + +## Monitoring Frequency Assignment + +### Criteria for Frequency Selection + +Four factors govern frequency selection: + +**1. Information Volatility** +How rapidly does the monitored condition change on its own? +- Software versions and patch state: changes with vendor releases (can be daily to quarterly) +- Configuration settings: can change at any time (human or automated) +- Vulnerability exposure: changes as CVEs are published (daily) +- Access control lists: change with personnel actions (event-driven) + +**2. Adversary Speed of Exploitation** +How quickly can an adversary exploit a discovered vulnerability? +- Known exploited vulnerabilities (KEV, CISA): hours to days +- Public proof-of-concept exploits: days +- High-complexity exploits: weeks to months +- Low-value targets, no public exploit: months + +**3. CIA Impact** +What is the potential impact if the control fails? +- High impact systems: require more frequent monitoring to reduce risk exposure window +- Low impact systems: less frequent monitoring may be acceptable + +**4. Automation Feasibility** +- If monitoring can be fully automated, continuous or daily monitoring is achievable at low cost +- If monitoring requires manual effort, frequency must be balanced against resources + +### Frequency Assignment Table Template + +| Control Family | Control ID | Metric | Frequency | Automation | +|---|---|---|---|---| +| Access Control | AC-2 | Inactive accounts (>30 days) | Weekly | Semi-automated | +| Access Control | AC-7 | Failed login threshold per policy | Continuous | Automated | +| Configuration Management | CM-6 | Configuration compliance vs. baseline | Daily | Automated | +| Configuration Management | CM-7 | Non-whitelisted software detected | Daily | Automated | +| Incident Response | IR-6 | Incidents reported within required timeframe | Weekly | Semi-automated | +| Maintenance | MA-2 | Scheduled maintenance records current | Monthly | Manual | +| Media Protection | MP-6 | Sanitization records current | Quarterly | Manual | +| Risk Assessment | RA-5 | Vulnerability scan age | Weekly (High+); Monthly (Mod/Low) | Automated | +| System and Communications | SC-28 | Encryption-at-rest compliance | Monthly | Semi-automated | +| System and Information Integrity | SI-2 | Critical/High patches applied within SLA | Daily | Automated | +| System and Information Integrity | SI-3 | AV definition currency | Continuous | Automated | +| System and Information Integrity | SI-4 | IDS/IPS alert processing within SLA | Continuous | Automated | + +**Note**: This table is illustrative. Each organisation must define the complete frequency mapping for all controls in scope based on the four criteria above. + +--- + +## Control Selection for ISCM + +Not all SP 800-53 controls are equally suited to automated continuous monitoring. Controls are classified by their amenability to automation: + +### Tier A — Highly Amenable to Automation (Continuous or Daily Monitoring) + +These controls produce machine-readable, quantifiable outputs that scanners and SCAP tools can assess: +- SI-2 (Flaw Remediation / Patch Management) +- SI-3 (Malicious Code Protection — AV currency) +- SI-4 (Information System Monitoring — IDS/IPS alert status) +- CM-6 (Configuration Settings — SCAP/XCCDF checklist compliance) +- CM-7 (Least Functionality — software whitelist compliance) +- AC-7 (Unsuccessful Logon Attempts — log-based) +- AU-2/AU-3 (Audit Events/Content — log completeness and current) +- IA-5 (Authenticator Management — password age, MFA status) + +### Tier B — Amenable to Semi-Automated or Periodic Monitoring (Weekly to Monthly) + +These controls require some human triage or configuration to monitor: +- AC-2 (Account Management — account review against HR records) +- AC-17 (Remote Access — VPN session and configuration review) +- RA-5 (Vulnerability Scanning — scan results reviewed and triaged) +- SC-28 (Protection of Information at Rest — cryptographic status) +- CP-9 (Information System Backup — backup job status review) +- PE-3 (Physical Access Control — access log review) + +### Tier C — Primarily Manual Assessment (Quarterly to Annual) + +These controls require human assessment and cannot be effectively automated: +- AT-2/AT-3 (Security Training Awareness/Role-Based Training — completion records) +- PL-2 (System Security Plan — currency review) +- PS-3/PS-4/PS-5 (Personnel Screening, Termination, Transfer) +- CP-4 (Contingency Plan Testing — tabletop or test results) +- CA-2 (Security Assessments — formal assessment activities) +- IR-3 (Incident Response Testing) + +--- + +## ISCM Programme Establishment Procedures + +### Step A — Tool Selection Criteria + +For each Tier A metric, identify a candidate tool: + +| Criterion | Requirement | +|---|---| +| SCAP validation | Required for Tier A controls (CVE, CCE, CPE, CVSS, OVAL, XCCDF support) | +| Coverage | Must scan all in-scope assets within the monitoring cycle | +| Authentication | Credentialed scanning required for configuration and patch assessment | +| Reporting | Must produce output in ARF or otherwise importable to security data repository | +| Access control | Tool must enforce least privilege; credentials stored securely | +| Logging | Tool operations must be logged for audit | + +### Step B — Baseline Establishment + +**Configuration Baseline**: +1. Identify applicable NIST SP 800-70 National Checklist Program (NCP) baseline for each platform +2. Customise baseline where organisational policy deviates (document rationale for every deviation) +3. Encode baseline in XCCDF checklist for automated scanning +4. Obtain ISO approval of the final baseline document +5. Import baseline into ISCM tool as the authorised configuration profile + +**Software Baseline**: +1. Inventory all authorised software on each system (name, version, publisher) +2. Create approved software list (whitelist) per system category or role +3. Configure CM tool to alert on deviations from approved list + +**Patch Baseline**: +1. Define patching SLAs per severity (Critical: 15 days; High: 30 days; Medium: 90 days; Low: 180 days) +2. Document approved exceptions (compensating controls for systems that cannot be patched) +3. Configure vulnerability scanner to alert on CVEs that exceed the SLA window + +### Step C — Data Repository Architecture + +**Minimum security controls for the ISCM data repository**: +- Access limited to ISCM personnel and AOs (least privilege) +- Data encrypted at rest and in transit +- Audit log of all access and query activity +- Backup and availability controls to ensure historical data is retained for trend analysis +- Data integrity controls (signed exports, hash validation for archived data) + +**Data retention**: +- Raw scan results: minimum 12 months for trend analysis +- Aggregated reports: minimum 3 years (consistent with FISMA reporting cycles) +- POA&M history: life of the system + +--- + +## Organisational ISCM Maturity + +ISCM programmes mature over time. A notional maturity progression: + +| Level | Description | Characteristics | +|---|---|---| +| Level 1 — Ad hoc | No formal ISCM programme | Manual periodic assessments only; no defined metrics or frequencies | +| Level 2 — Defined | ISCM strategy documented | Metrics defined; frequencies assigned; tools identified but not fully deployed | +| Level 3 — Consistently implemented | Programme operational | Automated collections running; Tier 3 reporting in place; POA&M managed | +| Level 4 — Managed | Aggregated and reported | Tier 2 and Tier 1 aggregation functional; AO receives ISCM-based status reports | +| Level 5 — Optimised | Continuous improvement | Ongoing authorisation in use; metrics refined based on threat intelligence; programme drives risk decisions | + +--- + +## CDM Programme Integration + +The DHS Continuous Diagnostics and Mitigation (CDM) programme provides federal civilian agencies with ISCM capabilities aligned to SP 800-137. CDM capability layers: + +| CDM Capability Layer | What It Monitors | SP 800-137 Tier | +|---|---|---| +| Layer 1 — What is on the network | Hardware and software asset management (HWAM/SWAM) | Tier 3 | +| Layer 2 — Who is on the network | Configuration management, vulnerability management | Tier 3 | +| Layer 3 — What is happening on the network | Identity and access management | Tier 3 | +| Layer 4 — How data is protected | Data protection management | Tier 3 / Tier 2 | +| Dashboard | Agency-wide security status | Tier 1 / Tier 2 | + +CDM tools deployed at agencies map to ISCM Tier A controls and feed the agency ISCM data repository and the CDM Agency Dashboard. The CDM Federal Dashboard provides DHS/CISA with aggregated federal ISCM data for Tier 1 government-wide reporting. diff --git a/plugins/nist-sp-800-161/.claude-plugin/plugin.json b/plugins/nist-sp-800-161/.claude-plugin/plugin.json new file mode 100644 index 0000000..a072c6e --- /dev/null +++ b/plugins/nist-sp-800-161/.claude-plugin/plugin.json @@ -0,0 +1,22 @@ +{ + "name": "nist-sp-800-161", + "version": "1.0.0", + "description": "NIST SP 800-161 Rev 1 Cybersecurity Supply Chain Risk Management (C-SCRM) skill for identifying, assessing, and mitigating ICT supply chain risks across the enterprise, mission/business, and system levels through integrated C-SCRM programmes, supplier assessments, acquisition lifecycle controls, and SP 800-53 SR control family implementation.", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@gmail.com" + }, + "homepage": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "repository": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "C-SCRM", + "supply-chain", + "ICT-risk", + "SR-controls", + "SBOM", + "supplier-assessment", + "acquisition", + "NIST" + ] +} diff --git a/plugins/nist-sp-800-161/skills/nist-sp-800-161/SKILL.md b/plugins/nist-sp-800-161/skills/nist-sp-800-161/SKILL.md new file mode 100644 index 0000000..1c3f2ca --- /dev/null +++ b/plugins/nist-sp-800-161/skills/nist-sp-800-161/SKILL.md @@ -0,0 +1,295 @@ +--- +name: nist-sp-800-161 +description: > + NIST SP 800-161 Rev 1 Cybersecurity Supply Chain Risk Management (C-SCRM) skill. Answers questions + about establishing enterprise C-SCRM programmes, implementing the SR control family from SP 800-53 + Rev 5, supplier vetting and assessments, SBOM (Software Bill of Materials) requirements, provenance + documentation, acquiring secure ICT products and services, identifying and protecting critical + components, integrating C-SCRM into the acquisition lifecycle, prime and sub-tier supplier + management, C-SCRM policies and plans, hardware and software supply chain threats, counterfeit + component detection, third-party risk management for federal information systems, and aligning + supply chain security with the NIST Cybersecurity Framework. +--- + +# NIST SP 800-161 Rev 1 — Cybersecurity Supply Chain Risk Management (C-SCRM) + +**Source**: NIST Special Publication 800-161 Revision 1, May 2022 +**Full Title**: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations +**CSRC URL**: https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final + +--- + +## Purpose and Scope + +NIST SP 800-161 Rev 1 provides guidance to federal agencies and other organisations for identifying, assessing, and mitigating cybersecurity risks throughout the supply chain of information and communications technology (ICT) products and services. The guidance helps organisations manage risks introduced by suppliers, developers, system integrators, external system service providers, and other ICT related service providers. + +**C-SCRM** addresses the entire lifecycle of ICT products and services: design, development, distribution, deployment, acquisition, maintenance, and end-of-life/disposal. + +--- + +## C-SCRM Foundation + +### Key Concepts + +**Supply Chain**: The linked set of resources and processes between multiple tiers of developers, integrators, and maintainers that transforms raw inputs into a finished product or service that is delivered to the end user. + +**ICT Supply Chain Risk**: The susceptibility of an organisation's ICT supply chain to disruption, compromise, or failure resulting from vulnerabilities, threat events, and/or hazards affecting the ICT products and services it uses. + +**C-SCRM**: The process of identifying, assessing, and mitigating the risks associated with the distributed and interconnected nature of ICT product and service supply chains. + +### Supply Chain Threats + +| Category | Description | Examples | +|---|---|---| +| Counterfeit components | Non-genuine hardware or software falsely represented as meeting specifications | Fake memory chips, cloned microprocessors, pirated software | +| Tampered products | Genuine products modified to introduce vulnerabilities or backdoors | Hardware trojans in ICs, malicious firmware updates, backdoored software | +| Inferior or fraudulent products | Products that do not meet stated specifications or security requirements | Below-spec hardware that fails under load, fraudulent certifications | +| Theft of sensitive information | Intellectual property or configuration data exfiltrated during production or transit | Design theft, source code theft, configuration exfiltration | +| Installation of malicious code | Malware or logic bombs inserted during development, manufacturing, or delivery | Supply chain malware (e.g., SUNBURST/SolarWinds), poisoned software updates | +| Poor manufacturing/development practices | Insecure development or manufacturing that introduces unintentional vulnerabilities | Insecure coding practices, lack of build integrity controls | + +--- + +## C-SCRM Multi-Tier Model + +C-SCRM operates across a multi-tier supply chain: + +### Tier 1 — Enterprise (Organisation Level) +- Establishes the enterprise C-SCRM strategy, policy, and programme +- Sets organisational risk tolerance for supply chain risks +- Assigns responsibilities and resources +- Integrates C-SCRM into enterprise-wide risk management + +### Tier 2 — Mission/Business Process Level +- Implements C-SCRM in support of specific missions and business functions +- Identifies mission-critical ICT products and services +- Assesses supply chain risks for mission-critical components +- Manages supplier relationships at the programme/project level + +### Tier 3 — Information System Level +- Implements system-specific C-SCRM controls +- Applies C-SCRM requirements in the acquisition and deployment of system components +- Monitors the supply chain for in-service systems +- Implements the SP 800-53 Rev 5 SR control family at the system level + +### Supplier Tiers +- **Prime Contractor/Developer**: Direct supplier to the organisation +- **Sub-tier Supplier**: Suppliers to the prime contractor (second and third tier) +- **Component Manufacturer**: Lowest tier; manufactures hardware or software components + +C-SCRM must look beyond the prime contractor to identify and address sub-tier risks. Compromise often enters at lower supplier tiers that the acquirer has no direct relationship with. + +--- + +## C-SCRM Programme Components + +A complete enterprise C-SCRM programme includes: + +### 1. C-SCRM Policy +A formal organisational policy directing C-SCRM activities: +- Scope: all ICT products and services acquired and used +- Risk tolerance statement for supply chain risk +- Mandatory requirements (e.g., supplier vetting, contract clauses, SBOM requirements) +- Roles and responsibilities +- Compliance and enforcement + +### 2. C-SCRM Strategy +An enterprise strategy document addressing: +- Organisational risk tolerance specific to supply chain +- Methods for identifying and prioritising ICT supply chain risks +- Integration with enterprise risk management +- Integration with acquisition and procurement processes +- Methods for communicating C-SCRM requirements to suppliers +- Metrics for measuring C-SCRM effectiveness + +### 3. C-SCRM Plan +An operational plan implementing the strategy: +- Critical ICT components and services inventory +- Supplier inventory with tier mapping +- Risk assessment results per critical component/supplier +- Controls applied per risk level +- Monitoring activities and frequencies +- Incident response procedures for supply chain incidents + +### 4. C-SCRM Controls Implementation +Implementation of relevant SP 800-53 Rev 5 controls, primarily the SR family (see SR Control Family section below). + +--- + +## Critical ICT Component Identification + +Critical components are those whose failure, compromise, or substitution would have severe consequences for the mission, business process, or information system. + +### Identification Criteria +A component is considered critical if: +- It processes, stores, or transmits sensitive or classified information +- Compromise would directly enable adversary access to the system or its data +- It is a single point of failure for mission-critical functions +- It performs security functions (cryptographic modules, authentication systems, firewalls, PKI) +- It is difficult or impossible to replace quickly if compromised +- The supplier is in a high-risk geography or is under foreign state control + +### Critical Component Handling Requirements +Once identified as critical, a component must: +- Have provenance documentation maintained throughout its lifecycle +- Be subject to enhanced supplier vetting +- Have an SBOM or equivalent component transparency document +- Be subject to integrity verification before deployment +- Have disposal and end-of-life handling procedures that prevent data reconstruction + +--- + +## SP 800-53 Rev 5 Supply Chain Risk Management (SR) Control Family + +The SR control family (introduced in SP 800-53 Rev 5) directly addresses C-SCRM: + +| Control ID | Control Name | Baseline | Description | +|---|---|---|---| +| SR-1 | Policy and Procedures | L/M/H | Develop, document, and disseminate SR policy and procedures | +| SR-2 | Supply Chain Risk Management Plan | L/M/H | Develop a C-SCRM plan addressing organisational-level, mission/business-level, and system-level supply chain risks | +| SR-2(1) | Supply Chain Risk Management Plan — Establish SCRM Team | M/H | Establish a dedicated team or function responsible for C-SCRM | +| SR-3 | Supply Chain Controls and Processes | L/M/H | Establish and implement processes to identify and address supply chain risks for systems, components, and services | +| SR-3(1) | Diverse Supply Base | — | Employ a diverse set of suppliers to reduce single-source dependencies | +| SR-3(2) | Limitation of Harm | — | Employ acquisition strategies and contract mechanisms to limit harm from compromised systems or components | +| SR-3(3) | Sub-Tier Flow Down | — | Require prime contractors to ensure C-SCRM requirements flow down to sub-tier suppliers | +| SR-4 | Provenance | M/H | Document and maintain provenance records for system components from design through disposal | +| SR-4(1) | Identity | — | Maintain supplier identity information throughout the supply chain | +| SR-4(2) | Track and Trace | — | Implement mechanisms to track and trace system components throughout the supply chain | +| SR-4(3) | Validate as Genuine and Not Altered | — | Employ additional measures to validate the integrity of components | +| SR-4(4) | Supply Chain Integrity — Pedigree | — | Maintain a pedigree of system components tracking chain of custody | +| SR-5 | Acquisition Strategies, Tools, and Methods | L/M/H | Implement acquisition strategies, contract mechanisms, and procurement methods to protect the supply chain | +| SR-5(1) | Adequate Supply | — | Obtain sufficient supply of critical components to satisfy continuity requirements | +| SR-5(2) | Assessments Prior to Selection, Acceptance and Update | — | Conduct organisational assessments of ICT products and services prior to selection, acceptance, or update | +| SR-6 | Supplier Assessments and Reviews | M/H | Assess and review suppliers of critical system components at defined frequencies | +| SR-6(1) | Testing and Analysis | — | Test and analyse acquired components for malicious code, logic bombs, and exploitable vulnerabilities prior to deployment | +| SR-7 | Supply Chain Operations Security | M/H | Implement OPSEC measures to protect supply chain operations from adversary reconnaissance and exploitation | +| SR-8 | Notification Agreements | L/M/H | Establish notification agreements with suppliers requiring disclosure of vulnerabilities, incidents, changes, and end-of-life notification | +| SR-9 | Tamper Resistance and Detection | H | Implement anti-tamper technologies and techniques on critical systems and components | +| SR-9(1) | Inspection of Systems or Components | — | Inspect systems and components for evidence of tampering prior to deployment and periodically thereafter | +| SR-10 | Inspection of Systems or Components | M/H | Inspect system components using defined inspection methods before each instantiation and at defined frequencies | +| SR-11 | Component Authenticity | M/H | Implement anti-counterfeiting policy and procedures and employ anti-counterfeiting technologies where feasible | +| SR-11(1) | Anti-Counterfeiting Training | — | Train personnel on how to detect counterfeit system components | +| SR-11(2) | Configuration Control for Component Service and Repair | — | Maintain configuration control during service and repair | +| SR-11(3) | Anti-Counterfeiting Scanning | — | Scan for counterfeit components using defined scanning tools and techniques | +| SR-12 | Component Disposal | L/M/H | Dispose of data, documentation, tools, or system components in a manner that prevents recovery after the system or component reaches end-of-life | + +**Note on SR control baselines**: SR-1, SR-2, SR-3, SR-5, SR-8, SR-12 apply to all baselines (L/M/H). SR-4, SR-6, SR-7, SR-10, SR-11 apply to Moderate and High baselines. SR-9 applies to High baseline only. + +--- + +## Software Bill of Materials (SBOM) + +An SBOM is a formal record containing the details and supply chain relationships of all components used in building software. + +### SBOM Minimum Data Fields (per NTIA consensus) +| Field | Description | +|---|---| +| Supplier Name | Name of the entity that creates, defines, and identifies the component | +| Component Name | Designation assigned to a unit of software defined by the original supplier | +| Version of the Component | Identifier used by the supplier to specify a change in software from a previously identified version | +| Other Unique Identifiers | Other identifiers used to identify a component (package URL, SWID tag, CPE) | +| Dependency Relationship | Characterising the relationship that an upstream component X is included in software Y | +| Author of SBOM Data | The name of the entity that created the SBOM data for this component | +| Timestamp | Record of the date and time of the SBOM data assembly | + +### SBOM Formats +- **SPDX** (Software Package Data Exchange — ISO 5962): Linux Foundation standard +- **CycloneDX**: OWASP standard, XML/JSON +- **SWID Tags** (ISO 19770-2): Software Identification tags + +### SBOM Use in C-SCRM +- Required for critical software components (aligned with EO 14028 requirements) +- Enables organisations to identify vulnerable components when a CVE is published +- Supports provenance documentation (SR-4) +- Enables faster incident response when supply chain compromises are discovered + +--- + +## Acquisition Lifecycle Integration + +C-SCRM requirements must be integrated at each phase of the acquisition lifecycle: + +### Phase 1 — Requirements Definition +- Identify whether the acquisition involves critical ICT components +- Include C-SCRM requirements in the Statement of Work (SOW) or Statement of Objectives (SOO) +- Define supplier vetting requirements +- Define SBOM requirements for software-intensive acquisitions +- Define notification requirements (SR-8) + +### Phase 2 — Market Research and Source Selection +- Research suppliers for C-SCRM risk indicators (country of origin, ownership, prior incidents) +- Use approved supplier lists where available +- Evaluate supplier C-SCRM practices as selection criteria +- Apply higher scrutiny to sole-source acquisitions + +### Phase 3 — Contract Award +- Include C-SCRM contract clauses (mandatory flow-down of security requirements to sub-tier suppliers) +- Include right-to-audit provisions for critical suppliers +- Include notification requirements for vulnerabilities, incidents, and changes +- Include counterfeit prevention requirements for hardware +- Define SBOM delivery as a contract deliverable for software + +### Phase 4 — Delivery and Acceptance +- Verify component provenance before acceptance +- Conduct pre-deployment testing for malicious code and counterfeit components where risk warrants +- Validate SBOM delivery and content +- Update system inventory and provenance records + +### Phase 5 — Operations and Maintenance +- Monitor suppliers for relevant vulnerability disclosures (coordinate with SI-5 Security Alerts) +- Conduct periodic supplier reviews (SR-6) +- Respond to notification agreement disclosures +- Manage updates and patches through secure channels +- Monitor for new sub-tier supplier risks + +### Phase 6 — Disposal and End-of-Life +- Apply SR-12 disposal requirements +- Ensure sensitive data is destroyed +- Manage surplus equipment to prevent component re-entry into the supply chain as counterfeit + +--- + +## Supplier Assessment + +### Supplier Risk Tiers +Categorise suppliers by risk: + +| Tier | Description | Assessment Required | +|---|---|---| +| Critical | Supplies components for high-impact systems; single-source; foreign ownership or presence | Full assessment: questionnaire, on-site audit, reference checks, third-party assessment | +| High | Multi-source; moderate impact systems; significant software content | Questionnaire, documentation review, reference checks | +| Moderate | Standard commercial products; well-established vendor; competitive market | Documentation review, certifications verification | +| Low | Commodity products; multiple sources; publicly traded US company | Standard procurement due diligence | + +### Supplier Assessment Areas +1. **Security programme**: Does the supplier have a documented information security programme? +2. **Secure development**: Does the supplier follow secure development practices (SSDF/SP 800-218)? +3. **Sub-tier management**: Does the supplier flow down C-SCRM requirements to its sub-contractors? +4. **Incident response**: Does the supplier have an incident response capability and a notification process? +5. **Physical security**: Are manufacturing and development facilities appropriately secured? +6. **Personnel security**: Background checks, insider threat programme? +7. **Provenance and integrity**: Can the supplier provide documentation of component provenance and integrity verification? +8. **Certifications**: Does the supplier hold relevant certifications (ISO 27001, CMMC, SOC 2)? + +--- + +## Roles and Responsibilities + +| Role | C-SCRM Responsibilities | +|---|---| +| Chief Information Officer (CIO) | Owns enterprise C-SCRM strategy; ensures C-SCRM integration with IT governance | +| Chief Acquisition Officer | Integrates C-SCRM into procurement and contracting processes | +| Senior Accountable Official for Risk Management (SAORM) | Oversees enterprise C-SCRM risk posture; approves risk tolerance | +| C-SCRM Programme Manager | Day-to-day C-SCRM programme management; maintains supplier inventory; coordinates assessments | +| Information System Owner | Implements system-level C-SCRM requirements; maintains system component provenance | +| ISSO | Implements SR control family at system level; monitors supply chain events affecting the system | +| Contracting Officer | Incorporates C-SCRM contract clauses; enforces contractual C-SCRM requirements | +| Legal Counsel | Reviews C-SCRM contract terms; advises on enforceability | + +--- + +## Reference Files + +- `references/sr-control-family.md` — Complete SR control family with detailed implementation guidance for each control +- `references/supplier-assessment.md` — Supplier risk tiering, assessment questionnaire, contract clauses, and SBOM requirements +- `references/c-scrm-programme.md` — C-SCRM programme establishment, policy templates, plan structure, and acquisition lifecycle procedures diff --git a/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/c-scrm-programme.md b/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/c-scrm-programme.md new file mode 100644 index 0000000..d9f86ee --- /dev/null +++ b/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/c-scrm-programme.md @@ -0,0 +1,261 @@ +# NIST SP 800-161 Rev 1 — C-SCRM Programme Establishment and Acquisition Procedures + +**Source**: NIST SP 800-161 Rev 1, May 2022, Sections 2, 3.1–3.4 + +--- + +## C-SCRM Programme Establishment + +### Step 1 — Obtain Senior Leadership Commitment + +C-SCRM requires explicit senior leadership support. Before establishing the programme: +- Brief CIO, SAORM, and Chief Acquisition Officer on supply chain risks and regulatory requirements +- Obtain a formal commitment to resource and implement C-SCRM +- Designate a C-SCRM Programme Manager as a named position +- Establish or designate the C-SCRM governance body (cross-functional team) + +### Step 2 — Develop C-SCRM Policy (SR-1) + +Draft and obtain approval for a C-SCRM Policy: +- Scope: explicitly cover all ICT acquisitions including cloud services, SaaS, FOSS, and COTS +- Mandate: critical component identification, supplier vetting, SBOM for software, contract clauses +- Roles: CIO, SAORM, Chief Acquisition Officer, C-SCRM Programme Manager, Contract Officers, ISSOs +- Compliance: mechanism for tracking compliance and addressing non-compliance + +### Step 3 — Develop C-SCRM Strategy + +Document the enterprise C-SCRM strategy: +- Risk tolerance statement (what level of supply chain risk will the organisation accept and under what conditions) +- Prioritisation approach for applying C-SCRM resources (risk-based, starting with critical components) +- Integration with acquisition lifecycle (at which acquisition phases will C-SCRM requirements be applied) +- Integration with enterprise risk management +- Metrics for tracking C-SCRM programme effectiveness + +### Step 4 — Establish Supplier and Critical Component Inventory + +**Supplier inventory**: +- Identify all current ICT suppliers (hardware, software, cloud, managed services) +- Classify each supplier by risk tier using the tiering criteria +- Identify existing contract terms for C-SCRM provisions (will identify gaps needing remediation at next renewal) + +**Critical component inventory** (Critical Asset List): +- Apply the criticality identification criteria to all ICT components +- Document the Critical Asset List with component details, supplier, and current risk controls +- Review and update the Critical Asset List at least annually and upon significant acquisitions or system changes + +### Step 5 — Develop the C-SCRM Plan (SR-2) + +Produce a formal C-SCRM Plan covering: +1. Scope and applicability +2. Risk tolerance statement (from strategy) +3. Critical Asset List (by reference or included) +4. Supplier inventory with tier classifications +5. Risk assessment approach +6. Controls applied per risk tier +7. Acquisition lifecycle integration procedures +8. Supplier assessment schedule and procedures +9. Monitoring activities and frequencies +10. Incident response procedures for supply chain events +11. Plan review cycle (minimum annual) + +### Step 6 — Integrate C-SCRM into Acquisition Processes + +Work with the Chief Acquisition Officer and Contracting Officers: +- Develop standard C-SCRM pre-solicitation checklist (triggers the C-SCRM review) +- Develop standard C-SCRM contract clause library for use at different risk tiers +- Develop SBOM delivery requirement language +- Train Contracting Officers and acquisition personnel on applying C-SCRM requirements +- Establish review process: acquisitions exceeding defined thresholds require C-SCRM review before solicitation + +### Step 7 — Establish Monitoring + +Establish ongoing C-SCRM monitoring: +- Subscribe to CISA Known Exploited Vulnerabilities (KEV) catalogue alerts +- Subscribe to National Vulnerability Database (NVD/CVE) feeds for components used +- Monitor GIDEP (Government-Industry Data Exchange Program) alerts for counterfeit and suspect components +- Monitor US-CERT and sector-specific ISAC alerts for supply chain threats +- Establish process to act on supplier notification agreement disclosures + +--- + +## C-SCRM Plan Template + +``` +================================================== +CYBERSECURITY SUPPLY CHAIN RISK MANAGEMENT PLAN +[ORGANISATION NAME] +================================================== + +DOCUMENT CONTROL +Version: [X.Y] +Approval Date: [YYYY-MM-DD] +Approving Official: [CIO / SAORM] +Review Cycle: Annual (next review: [YYYY-MM-DD]) + +1. PURPOSE AND SCOPE + 1.1 Purpose + This C-SCRM Plan documents [Organisation Name]'s programme for identifying, + assessing, and mitigating cybersecurity risks in the supply chain for ICT + products and services, consistent with NIST SP 800-161 Rev 1. + + 1.2 Scope + This plan applies to all ICT products, software, systems, and services + acquired by [Organisation Name], including but not limited to: + - Hardware components and systems + - Commercial off-the-shelf (COTS) software + - Free and open-source software (FOSS) incorporated into systems + - Cloud services and SaaS + - Managed and outsourced IT services + +2. GOVERNANCE AND ROLES + [Role] — [Specific C-SCRM responsibilities] + [Repeat per role] + C-SCRM Governance Body: [Name, membership, meeting cadence] + +3. RISK TOLERANCE + [Organisation Name] will accept supply chain risk at the [Low/Moderate/High] + level for commoditised ICT components with multiple qualified suppliers and + no mission-critical function. For critical components as defined in this plan, + only [Low/Moderate] risk is acceptable, and risk exceeding that threshold must + be documented with an accepted risk decision by [SAORM/CIO]. + +4. CRITICAL ASSET LIST + [Reference to Critical Asset List document or include summary table] + + | Component | System | Supplier | Risk Tier | Last Assessment | Next Assessment | + |---|---|---|---|---|---| + | [Component] | [System name] | [Supplier] | Critical/High/Mod/Low | [Date] | [Date] | + +5. SUPPLIER INVENTORY + [Reference to Supplier Inventory document or include summary table] + + | Supplier | Products/Services | Risk Tier | Contract C-SCRM Clauses | Last Review | + |---|---|---|---|---| + | [Supplier] | [Products] | [Tier] | [Yes/No/Partial] | [Date] | + +6. RISK ASSESSMENT APPROACH + Supply chain risk assessments are conducted using the tiering criteria in + the C-SCRM Supplier Assessment procedure. Risk assessments consider: + - Threat sources (nation-state, criminal, insider, accidental) + - Threat events (counterfeit components, tampered products, malicious code insertion, etc.) + - Vulnerabilities (single-source dependency, lack of provenance, insecure sub-tiers) + - Likelihood and impact per NIST SP 800-30 approach + +7. CONTROLS BY RISK TIER + Critical tier: SR-2, SR-3, SR-3(1), SR-3(3), SR-4, SR-4(1)–(4), SR-5, SR-5(2), + SR-6, SR-6(1), SR-7, SR-8, SR-11, SR-11(1), SR-12 + High tier: SR-2, SR-3, SR-3(3), SR-4, SR-4(1), SR-5, SR-6, SR-8, SR-11, SR-12 + Moderate tier: SR-1, SR-2, SR-3, SR-5, SR-8, SR-11, SR-12 + Low tier: SR-1, SR-12 + +8. ACQUISITION LIFECYCLE INTEGRATION + [Reference to Acquisition Procedure section or document] + +9. SUPPLIER ASSESSMENT SCHEDULE + | Supplier | Tier | Assessment Type | Frequency | Next Due | + |---|---|---|---|---| + | [Supplier] | Critical | On-site audit | Annual | [Date] | + +10. MONITORING ACTIVITIES + [Description of ongoing monitoring: CVE feeds, GIDEP, ISAC, notification processing] + +11. INCIDENT RESPONSE + [Reference to or summary of supply chain incident response procedure] + +12. PLAN REVIEW + This plan shall be reviewed and updated: + a. Annually, at a minimum + b. Upon significant change to the organisational mission or IT environment + c. Upon identification of a supply chain incident + d. Upon change in organisational risk tolerance +``` + +--- + +## Acquisition Lifecycle C-SCRM Procedures + +### Pre-Solicitation C-SCRM Checklist + +Before issuing any solicitation for ICT products or services, the programme office or project manager completes this checklist: + +**Checklist — Pre-Solicitation C-SCRM Review** + +| Item | Yes | No | N/A | Action if No | +|---|---|---|---|---| +| 1. Has the acquisition been reviewed against the Critical Asset List? | | | | Conduct component criticality assessment | +| 2. Has the acquisition been classified by risk tier? | | | | Apply tiering criteria; document result | +| 3. Have C-SCRM contract clauses been selected from the approved library? | | | | Coordinate with Contracting Officer and C-SCRM Programme Manager | +| 4. For software-intensive acquisitions: is SBOM required? | | | | If critical/high: add SBOM delivery requirement | +| 5. For hardware acquisitions: are provenance and authenticity requirements included? | | | | Add clause requiring chain of custody documentation and authenticity warranties | +| 6. Are notification requirements included (72-hour incident/vulnerability; EOL)? | | | | Add SR-8 aligned notification clauses | +| 7. For Critical tier: has supplier assessment been initiated? | | | | Begin assessment before award; do not award to Critical tier supplier without assessment | +| 8. For High tier: has documentation review been scheduled? | | | | Schedule before or concurrent with contract performance | +| 9. Are right-to-audit provisions included for Critical/High tier? | | | | Add right-to-audit clause | +| 10. For sole-source acquisitions: has the risk of single-source dependency been documented? | | | | Document in acquisition risk register; include in C-SCRM plan | + +### Delivery and Acceptance Procedure + +For Critical and High-risk component deliveries: + +1. Notify the C-SCRM Programme Manager of impending delivery +2. Upon receipt: + a. Verify component identity (match received item against purchase order specifications) + b. Check serial number/part number against manufacturer's authenticity verification portal if available + c. Inspect tamper-evident seals + d. For software: verify cryptographic signature or hash against developer-published values + e. For SBOM deliverable: verify SBOM was received and ingest per SBOM consumption procedure +3. Document the acceptance inspection in the provenance record +4. If any anomaly is detected: quarantine the component, notify the C-SCRM Programme Manager, and follow the supply chain incident response procedure (do not deploy the suspect component) + +### Supply Chain Incident Response Procedure + +**Trigger events**: +- Supplier notifies of a security incident or vulnerability affecting delivered products +- CISA KEV or NVD alert identifies a critical/high CVE in a component the organisation uses +- GIDEP alert identifies a suspect counterfeit component used by the organisation +- Organisation discovers evidence of tampering or malicious code in an in-service component +- Intelligence reporting identifies a supply chain threat + +**Response steps**: + +1. **Identify and assess**: + - Identify all systems using the affected component (use component inventory / SBOM data) + - Assess potential impact (CIA impact, exploitation status, adversary intent) + - Assign severity (Critical/High/Medium/Low) + +2. **Contain**: + - For active exploit: immediately isolate affected systems from the network + - For unpatched vulnerability: apply compensating control (WAF rule, disable affected feature, network segmentation) + - For counterfeit/tampered hardware: remove from service; quarantine + +3. **Notify**: + - Notify ISSO and system owner within 1 hour of identification + - Notify AO within 4 hours for Critical severity; within 24 hours for High + - Notify CISA if the system is a federal system and the event meets FISMA reporting thresholds + - Report suspect counterfeit components to GIDEP + +4. **Eradicate and recover**: + - For malicious code: re-image or rebuild affected systems + - For vulnerable component: apply vendor patch upon release; verify patch integrity before deployment + - For counterfeit hardware: replace with genuine component from authorised source + - For tampered component: replace and update provenance record + +5. **Document**: + - Record all response actions and timeline + - Update provenance records + - Update POA&M if compensating controls remain in place pending full remediation + - Conduct after-action review; update C-SCRM plan if process improvements are identified + +--- + +## C-SCRM Metrics + +| Metric | Measurement | Target | Reporting Level | +|---|---|---|---| +| Critical component coverage | Percentage of critical components with current provenance documentation | 100% | Tier 1 | +| Supplier assessment coverage | Percentage of Critical-tier suppliers with assessment within required frequency | 100% | Tier 1 | +| Contract C-SCRM clause coverage | Percentage of active contracts with Critical/High-tier suppliers containing required C-SCRM clauses | 100% | Tier 1 | +| SBOM coverage | Percentage of in-scope software deliverables for which SBOM has been received | Target by mission area | Tier 2 | +| Notification response | Percentage of supplier notifications responded to within defined timeframes | 100% | Tier 2/3 | +| Open supply chain vulnerabilities | Count and age of open CVEs in SBOMs not yet patched within SLA | 0 overdue | Tier 3 | +| Suspect counterfeit incidents | Count of suspect counterfeit components identified per quarter | 0; any triggers investigation | Tier 1 | diff --git a/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/sr-control-family.md b/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/sr-control-family.md new file mode 100644 index 0000000..0f96f34 --- /dev/null +++ b/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/sr-control-family.md @@ -0,0 +1,337 @@ +# NIST SP 800-161 Rev 1 — SR Control Family Implementation Guidance + +**Source**: NIST SP 800-161 Rev 1, May 2022; NIST SP 800-53 Rev 5, SR family + +--- + +## SR Control Family Overview + +The Supply Chain Risk Management (SR) control family was introduced in NIST SP 800-53 Rev 5 to address C-SCRM requirements at the information system level. It contains 12 base controls (SR-1 through SR-12) plus enhancements. SP 800-161 Rev 1 provides detailed implementation guidance for each SR control and its enhancements. + +--- + +## SR-1 — Policy and Procedures + +**Intent**: Establish and maintain a formal, documented, and disseminated C-SCRM policy. + +**Required policy content**: +- Purpose and scope (all ICT acquisitions at all tiers) +- Roles and responsibilities for C-SCRM +- Mandatory requirements (supplier vetting, contract clauses, SBOM, notification) +- Compliance requirements and consequences +- Review frequency (at minimum annually, and upon significant change) + +**Required procedures content**: +- Procedures implementing each SR control +- Procedures for supplier incident notification response +- Procedures for counterfeit component detection and response +- Procedures for C-SCRM plan maintenance and review + +**Implementation notes**: +- Policy must be approved by senior leadership (CIO or SAORM) +- Policy must be explicitly scoped to include cloud services, FOSS, and COTS products +- Procedures must be actionable and role-specific + +--- + +## SR-2 — Supply Chain Risk Management Plan + +**Intent**: Develop a formal C-SCRM Plan covering enterprise, mission/business, and system levels. + +**Plan required elements**: +1. Scope and applicability +2. Organisational risk tolerance for supply chain risk +3. Critical ICT components and services inventory (the "critical asset list") +4. Supplier inventory with tier classifications +5. Risk assessment approach and results summary +6. Controls applied per risk tier (SR controls implementation) +7. Monitoring activities and frequencies +8. Incident response procedures for supply chain events +9. Plan review and update cycle + +**Multi-tier coverage requirements**: +- Tier 1 (Enterprise): strategy, risk tolerance, programme governance +- Tier 2 (Mission/Business): mission-critical supplier identification, programme/project level oversight +- Tier 3 (System): system-specific control implementation, component-level provenance + +**SR-2(1) — Establish SCRM Team** (M/H): +- Establish a formal C-SCRM team (may be a cross-functional working group) +- Required representation: procurement/acquisition, IT/cybersecurity, legal, mission/programme owners +- Define team charter, meeting cadence, and escalation authority +- Team is responsible for: supplier assessments, policy updates, C-SCRM plan maintenance, incident coordination + +--- + +## SR-3 — Supply Chain Controls and Processes + +**Intent**: Establish processes to identify and address supply chain risks for systems, components, and services. + +**Required processes**: +- Process for identifying new ICT acquisitions and triggering C-SCRM review +- Process for classifying acquisitions by risk tier (critical, high, moderate, low) +- Process for selecting and applying controls based on risk tier +- Process for monitoring the supply chain for in-service systems + +**SR-3(1) — Diverse Supply Base**: +- Maintain awareness of single-source dependencies for critical components +- Where single-source dependency exists, document the risk and mitigation (e.g., strategic reserve, alternative qualification plan) +- Preference for multiple qualified suppliers where mission impact justifies the investment + +**SR-3(2) — Limitation of Harm**: +- Implement contractual provisions limiting adversary ability to benefit from supply chain access +- Examples: IP segregation requirements, background check requirements for personnel with access to sensitive components, security incident disclosure within 72 hours + +**SR-3(3) — Sub-Tier Flow Down**: +- Require prime contractors to flow down C-SCRM requirements to sub-tier suppliers in contract clauses +- Require prime contractors to maintain and provide a sub-tier supplier list upon request +- Require notification from prime if a sub-tier supplier changes for a critical component + +--- + +## SR-4 — Provenance + +**Intent**: Document and maintain provenance records for system components from design through disposal. + +**Provenance documentation minimum content**: +| Field | Description | +|---|---| +| Component identifier | Unique part number, serial number, or SWID/CPE identifier | +| Manufacturer | Legal name and country of origin of the manufacturing entity | +| Developer/Software supplier | Legal name of the software developer (if different from manufacturer) | +| Chain of custody | Record of all entities that possessed the component from manufacture to delivery | +| Date of manufacture | Date or date range | +| Version/revision | Hardware version or software version | +| Acquisition source | Authorised distributor or direct manufacturer; intermediary chain if applicable | +| Integrity evidence | Hash values for software; physical inspection record for hardware | +| Sub-component traceability | For complex assemblies: list of sub-components with their own provenance | + +**Maintenance requirements**: +- Provenance records must follow the component throughout its operational life +- Records must be updated upon any maintenance, repair, or update +- Records must be retained for the operational life plus applicable records retention period + +**SR-4(1) — Identity**: +- Maintain authoritative identity information (legal name, address, DUNS/CAGE code or UEI) for all critical suppliers +- Verify identity upon initial onboarding and whenever a supplier undergoes corporate change + +**SR-4(2) — Track and Trace**: +- For critical hardware: implement asset tracking that captures location and custody throughout lifecycle +- Acceptable mechanisms: RFID, barcoding, serial number databases, chain-of-custody logs + +**SR-4(3) — Validate as Genuine and Not Altered**: +- For critical software: verify cryptographic signatures/hashes provided by the developer +- For critical hardware: use manufacturer-provided authenticity features (holograms, physical unclonable functions, tamper-evident seals) +- Document validation results before component deployment + +**SR-4(4) — Supply Chain Integrity — Pedigree**: +- For the highest criticality components: obtain a formal pedigree document from the prime contractor or developer +- Pedigree documents all sub-components with their own provenance and chain-of-custody records + +--- + +## SR-5 — Acquisition Strategies, Tools, and Methods + +**Intent**: Implement acquisition strategies and procurement methods that protect the supply chain. + +**Acquisition strategies**: +- Preference for direct acquisition from original equipment manufacturers (OEMs) or authorised distributors for critical components +- Use of government-wide acquisition contracts (GWACs) that include C-SCRM requirements +- Avoidance of grey-market or unvetted broker channels for critical components +- Phased acquisition allowing incremental acceptance and testing + +**Contract mechanisms**: +- C-SCRM terms and conditions (see supplier-assessment.md contract clauses) +- Right-to-audit provisions for critical suppliers +- Notification requirements (aligned to SR-8) +- Warranties and representations regarding component authenticity and integrity +- Incident disclosure requirements (72-hour notification) +- Subcontractor approval and flow-down requirements +- SBOM delivery as a contract deliverable + +**SR-5(1) — Adequate Supply**: +- Identify critical components with limited availability or long lead times +- Maintain strategic inventory or pre-positioned spares for the highest criticality components +- Include continuity of supply as an evaluation criterion in source selection for critical components + +**SR-5(2) — Assessments Prior to Selection, Acceptance and Update**: +- Conduct supplier assessments before contract award for critical or high-risk acquisitions +- Conduct component-level testing/inspection before acceptance for critical hardware +- Conduct malicious code scanning before deploying new or updated software for critical systems + +--- + +## SR-6 — Supplier Assessments and Reviews + +**Intent**: Assess and review suppliers of critical system components at defined frequencies. + +**Assessment types**: + +| Type | Description | When Used | +|---|---|---| +| Documentation review | Review supplier-provided security documentation, policies, certifications | All critical/high-risk suppliers | +| Questionnaire | Structured questionnaire covering security programme, practices, and controls | All critical/high-risk suppliers | +| Third-party assessment | Use a qualified third party (e.g., CMMC C3PAO, ISO 27001 certification body) | Moderate and high-risk suppliers | +| On-site audit | Direct inspection of supplier facilities and practices | Highest criticality suppliers; where concerns exist | +| Penetration testing | Technical testing of supplier-facing interfaces | Where contractually permitted and risk warrants | + +**Assessment frequency guidance**: +- Critical suppliers: annual +- High-risk suppliers: every two years or upon significant change +- Moderate-risk suppliers: every three years or upon significant change + +**Triggers for unscheduled reassessment**: +- Supplier corporate change (acquisition, change in ownership, new foreign investment) +- Supplier security incident affecting components used by the organisation +- Published CVEs in supplier products +- Regulatory finding against the supplier +- Intelligence reporting indicating elevated risk + +**SR-6(1) — Testing and Analysis**: +- For critical hardware components: conduct physical or radiographic inspection, or use manufacturer authentication features before deployment +- For critical software components: conduct static analysis, dynamic analysis, or malicious code scanning using approved tools +- Document testing results and retain as provenance record + +--- + +## SR-7 — Supply Chain Operations Security + +**Intent**: Implement OPSEC measures to protect supply chain operations. + +**OPSEC measures**: +- Limit information about critical component specifications, quantities, and deployment timeline to need-to-know individuals +- Do not publish acquisition schedules, system configurations, or component types in publicly accessible documents +- Protect RFP documents and SOW details that reveal critical ICT component requirements from adversary exploitation +- Apply need-to-know access controls to provenance databases and supplier databases +- Classify or protect information about acquisition strategies for the highest criticality systems + +**OPSEC assessment**: +- Periodically review what supply chain information is publicly accessible (website, press releases, SAM.gov postings) +- Identify whether adversaries could construct a profile of the organisation's critical ICT dependencies from open sources +- Mitigate identified OPSEC risks + +--- + +## SR-8 — Notification Agreements + +**Intent**: Establish notification agreements with suppliers requiring disclosure of vulnerabilities, incidents, changes, and end-of-life. + +**Notification agreement required elements**: + +| Notification Type | Timeframe | Content Required | +|---|---|---| +| Critical/High vulnerability in delivered products | 72 hours of supplier discovery | CVE (if issued), affected versions, workaround, patch timeline | +| Security incident affecting the supply chain | 72 hours | Nature of incident, affected products/services, potential exposure, remediation steps | +| Significant change to development or manufacturing environment | 30 days before change when practicable | Description of change, security assessment conducted, impact on delivered products | +| Sub-tier supplier change for critical components | 30 days before transition | Name of new supplier, reason for change, assessment of new supplier | +| End-of-life / End-of-support announcement | 12 months in advance where possible | EOL date, migration path, available alternatives, support terms post-EOL | +| Change in ownership, acquisition, or significant foreign investment | 30 days | Nature of change, impact on security posture | + +**Implementation**: +- Notification agreements are incorporated as contract clauses at the time of acquisition +- For existing contracts without notification clauses: incorporate at next contract renewal or modification +- Define the organisational point of contact (C-SCRM Programme Manager or ISSO) to receive notifications +- Define the internal response process triggered by each notification type + +--- + +## SR-9 — Tamper Resistance and Detection + +**Intent** (High baseline): Implement anti-tamper technologies and techniques on critical systems and components. + +**Anti-tamper technologies**: +- Tamper-evident seals and labels on hardware +- Physical Unclonable Functions (PUFs) embedded in critical ICs +- Cryptographically sealed firmware with secure boot and measured boot +- Hardware Security Modules (HSMs) with tamper-detection and zeroization on physical attack +- Epoxy potting of sensitive circuits to prevent probing +- X-ray inspection of received shipments for embedded components + +**Anti-tamper implementation guidance**: +1. Identify the components warranting anti-tamper measures based on criticality and threat assessment +2. Select anti-tamper technologies appropriate to the threat (nation-state capability vs. opportunistic) +3. Document the anti-tamper posture as part of the provenance record +4. Train personnel on how to detect evidence of tampering and what to report + +**SR-9(1) — Inspection of Systems or Components**: +- Inspect systems and components for evidence of tampering before deployment +- Re-inspect upon return from servicing, repair, or extended deployment in untrusted environments +- Document inspection results + +--- + +## SR-10 — Inspection of Systems or Components + +**Intent** (M/H): Inspect system components using defined inspection methods before each instantiation and at defined periodic intervals. + +**Inspection methods by component type**: + +| Component Type | Inspection Method | +|---|---| +| Software | Hash verification against known-good hash from developer; malicious code scan; SBOM-based component vulnerability check | +| Firmware | Hash verification; secure boot attestation | +| Hardware (commodity) | Visual inspection; vendor authentication verification; tamper-evident seal check | +| Hardware (critical/custom) | As above plus: X-ray or CT scan if justified; functional testing; PUF challenge-response | +| Removable media | Malicious code scan before connection to sensitive systems | + +**Instantiation**: Each time a software component is deployed (including updates), verification should occur. Hardware inspection occurs at delivery and at defined intervals (annual for the highest criticality components). + +--- + +## SR-11 — Component Authenticity + +**Intent** (M/H): Implement anti-counterfeiting policy, procedures, and technologies. + +**Anti-counterfeiting policy must cover**: +- Definition of counterfeit (applies to hardware and software) +- Approved procurement channels (only OEM, authorised distributors) +- Prohibited channels (grey market, unknown brokers, resellers without authorised distributor status) +- Receipt inspection procedures +- Counterfeit detection process triggers +- Counterfeit reporting requirements (internal + GID reporting if applicable) +- Disposal of suspect/confirmed counterfeit items + +**Hardware anti-counterfeiting techniques**: +- Manufacturer-applied authentication markings (holographic labels, 2D barcodes with verification) +- Part marking verification (match stated part number against physical markings and spec sheets) +- Physical inspection (workmanship, surface finish, solder quality for suspect components) +- Electrical testing (verify component meets specified performance) +- Use of SAQR scanning (Surface Analytics Quick Response) where available + +**Software anti-counterfeiting**: +- Acquire software only from the developer's official channel or authorised reseller +- Verify code-signed installers against developer certificates +- Use package manager signature verification +- Verify license keys and activation codes against developer records + +**SR-11(1) — Anti-Counterfeiting Training**: +- Train procurement personnel on approved procurement channels and prohibited channels +- Train receiving/inspection personnel on visual and physical counterfeit detection +- Train IT personnel on software license and code signature verification + +**SR-11(2) — Configuration Control for Component Service and Repair**: +- When a component is sent out for service or repair, track its departure and return using the provenance record +- Verify component identity and integrity upon return before reinstallation +- If the component cannot be verified after return, treat it as untrusted and replace + +**SR-11(3) — Anti-Counterfeiting Scanning**: +- Deploy automated scanning tools where available to detect suspect components +- Report suspect counterfeit parts through appropriate channels (GIDEP, supplier notification) + +--- + +## SR-12 — Component Disposal + +**Intent** (L/M/H): Dispose of system components in a manner that prevents data recovery and prevents component re-entry into the supply chain as counterfeit. + +**Data destruction requirements**: +- Hard drives, SSDs, and storage-capable components: apply NIST SP 800-88 media sanitisation guidelines (Clear, Purge, or Destroy based on classification) +- Cryptographic modules: zeroize to FIPS 140 requirements +- Devices in cloud/virtualised environments: use provider-provided secure deletion with certification + +**Anti-counterfeit disposal**: +- Components designated for disposal must be physically destroyed (shredding, degaussing + physical destruction) or returned to the manufacturer +- Do not donate, surplus-sell, or otherwise release critical components to channels where they could re-enter the supply chain as counterfeit +- Document disposal with a certificate of destruction +- Maintain disposal records in the provenance record + +**Disposal authorisation**: Disposal of critical components requires authorisation from the system owner and C-SCRM programme manager. diff --git a/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/supplier-assessment.md b/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/supplier-assessment.md new file mode 100644 index 0000000..67bdb61 --- /dev/null +++ b/plugins/nist-sp-800-161/skills/nist-sp-800-161/references/supplier-assessment.md @@ -0,0 +1,222 @@ +# NIST SP 800-161 Rev 1 — Supplier Assessment, Contract Clauses, and SBOM Requirements + +**Source**: NIST SP 800-161 Rev 1, May 2022, Sections 3.5, 3.6, Appendix B + +--- + +## Supplier Risk Tiering Criteria + +Before conducting a supplier assessment, classify the supplier into a risk tier: + +### Tier Classification Worksheet + +Score the supplier on each factor (0 = lower risk, 1 = moderate risk, 2 = higher risk): + +| Factor | 0 | 1 | 2 | +|---|---|---|---| +| Geography of operations | US-only design and manufacturing | Allied nation manufacturing | Nations with known state-sponsored ICT threats | +| Ownership | US public company | Allied nation private company | Partially or wholly owned by adversary-nation entity | +| Prior security incidents | No known incidents | Incidents disclosed and remediated | Incidents not disclosed or unresolved | +| Certifications | ISO 27001 / CMMC Level 2+ / SOC 2 Type II | ISO 27001 in progress or equivalent | No relevant security certification | +| Visibility into sub-tier suppliers | Full sub-tier transparency | Partial visibility | No visibility into sub-tier | +| Single-source dependency | Multiple qualified suppliers exist | Limited alternatives | Sole source; no alternative | +| Component sensitivity | Commodity; non-security-relevant | System component; moderate sensitivity | Security function; cryptographic; directly mission-critical | + +**Score interpretation**: +- 0–4: Low risk tier — standard due diligence +- 5–8: Moderate risk tier — documentation review and certifications check +- 9–11: High risk tier — questionnaire, reference checks, third-party assessment +- 12–14: Critical risk tier — full assessment including on-site audit + +--- + +## Supplier Assessment Questionnaire (Abbreviated) + +### Section 1 — Security Programme + +1.1 Does your organisation have a documented and approved information security policy? +- Yes / No / In progress + +1.2 Has your organisation completed a recent information security risk assessment? +- Yes (date: ___) / No + +1.3 Does your organisation hold any of the following certifications? (Check all that apply) +- [ ] ISO 27001 (expiry date: ___) +- [ ] SOC 2 Type II (report date: ___) +- [ ] CMMC Level 2 +- [ ] CMMC Level 3 +- [ ] Other (specify): ___ + +1.4 Provide a contact for your organisation's information security programme: +- Name / Title / Email / Phone + +### Section 2 — Secure Development/Manufacturing + +2.1 Do you follow a documented secure development lifecycle (SDL) for software products? +- Yes / No / In progress + +2.2 Do you perform static application security testing (SAST) or dynamic application security testing (DAST) on products delivered to customers? +- SAST only / DAST only / Both / Neither + +2.3 Do you generate and provide an SBOM (Software Bill of Materials) for your software products? +- Yes, SPDX format / Yes, CycloneDX format / Yes, other format / In progress / No + +2.4 Do you sign your software releases cryptographically? +- Yes, with code signing certificate / Yes, with PGP/GPG / No + +2.5 For hardware products: do you maintain a bill of materials for major components including country of origin? +- Yes / No / Partial + +2.6 Do you use authorised distribution channels only for procuring components used in products delivered to customers? +- Yes / No / Not applicable (software only) + +### Section 3 — Sub-Tier Supplier Management + +3.1 Do you maintain an inventory of your significant sub-tier suppliers? +- Yes / No + +3.2 Do you flow down cybersecurity and supply chain security requirements to your sub-tier suppliers? +- Yes, in contract terms / Yes, informally / No + +3.3 Do you conduct assessments of your critical sub-tier suppliers? +- Yes / No + +3.4 Will you provide the procuring organisation with a list of sub-tier suppliers upon request? +- Yes / No / With restrictions + +### Section 4 — Incident Response and Notification + +4.1 Does your organisation have a documented incident response plan? +- Yes / No + +4.2 In the event of a security incident affecting products or services delivered to customers, will your organisation notify affected customers within 72 hours of discovery? +- Yes / No / Subject to legal review + +4.3 Will your organisation notify customers of critical and high vulnerabilities discovered in delivered products within 72 hours? +- Yes / No + +4.4 Will your organisation provide advance notification (minimum 12 months where practicable) of product end-of-life? +- Yes / No / Best effort + +### Section 5 — Physical Security + +5.1 Are your development and manufacturing facilities secured with access controls (badges, biometrics, CCTV)? +- Yes / Partial / No + +5.2 Do you conduct background checks on personnel with access to customer-sensitive components or source code? +- Yes, all such personnel / Yes, selected personnel / No + +5.3 Do you have an insider threat programme or equivalent controls? +- Yes / No / In development + +--- + +## C-SCRM Contract Clauses + +The following clauses should be incorporated into contracts for critical and high-risk acquisitions. Legal counsel must review before use. + +### Clause 1 — Security Requirements Flow-Down + +"Contractor shall incorporate cybersecurity and supply chain risk management requirements into its contracts and agreements with subcontractors and suppliers at all tiers that provide components, software, or services incorporated into deliverables under this contract. Contractor shall ensure that subcontractors and suppliers comply with requirements substantially equivalent to those imposed on Contractor by this contract. Contractor shall provide [Agency] with a list of significant subcontractors and suppliers upon request." + +### Clause 2 — Notification of Security Incidents and Vulnerabilities + +"Contractor shall notify [Agency Point of Contact] within 72 hours of discovery of any security incident or significant vulnerability affecting products or services delivered under this contract. Notification shall include: (a) description of the incident or vulnerability; (b) products and versions affected; (c) potential impact on [Agency] systems; (d) any compensating controls or workaround available; (e) timeline for patch or remediation. Contractor shall provide a follow-up written report within seven calendar days." + +### Clause 3 — Notification of Significant Changes + +"Contractor shall notify [Agency] at least 30 calendar days in advance of any significant change to its development, manufacturing, or delivery environment that may affect the security of products or services provided under this contract, including but not limited to: changes to development or build infrastructure; changes to significant subcontractors or suppliers for critical components; mergers, acquisitions, or changes in ownership; introduction of new geographic manufacturing locations." + +### Clause 4 — End-of-Life Notification + +"Contractor shall notify [Agency] no less than 12 months in advance of the end-of-support date for any product supplied under this contract. Notification shall include: (a) the anticipated end-of-support date; (b) recommended replacement or migration path; (c) any extended support options available and associated terms." + +### Clause 5 — Authenticity and Integrity of Deliverables + +"Contractor warrants that all hardware components delivered under this contract are genuine, new (unless otherwise specified), and sourced from the original equipment manufacturer or an authorised distributor. Contractor warrants that all software delivered under this contract is genuine, unmodified from the developer's release, and free of known malicious code as of the date of delivery. Contractor shall provide, upon request, documentation supporting these warranties including supplier chain of custody records." + +### Clause 6 — Software Bill of Materials + +"For software products delivered under this contract, Contractor shall provide a Software Bill of Materials (SBOM) in [SPDX / CycloneDX] format covering all components incorporated into the deliverable. The SBOM shall meet the minimum data requirements established by NTIA and shall be provided within [30] calendar days of contract award for existing products and at initial delivery for new development. Contractor shall update the SBOM within [30] calendar days of any software update delivered under this contract." + +### Clause 7 — Right to Audit + +"[Agency] reserves the right, upon reasonable notice (not less than [30] calendar days except in cases of documented urgent concern), to audit Contractor's security practices as they relate to products and services provided under this contract. Audits may include: review of security documentation; interviews with security personnel; and inspection of relevant facilities. Contractor shall cooperate with and facilitate such audits at no additional cost to [Agency]." + +### Clause 8 — Change in Ownership + +"Contractor shall notify [Agency] within [30] calendar days of any proposed or completed merger, acquisition, change in controlling ownership, or significant new foreign investment in Contractor or any entity in Contractor's supply chain that may materially affect performance or the security posture of deliverables under this contract. [Agency] reserves the right to review and respond to such changes, including requiring additional security assessments." + +--- + +## SBOM Requirements Specification + +### When to Require SBOMs + +SBOMs should be required as contract deliverables when: +- The acquisition is for software-intensive systems (EO 14028 scope) +- The system or component performs a security function +- The system or component has internet connectivity or processes sensitive data +- The acquisition is for critical infrastructure or high-impact systems + +### SBOM Minimum Data Fields (per NTIA June 2021 Minimum Elements) + +| Field | Required | Format | +|---|---|---| +| Supplier Name | Yes | Legal entity name | +| Component Name | Yes | Name as designated by supplier | +| Version of the Component | Yes | Version string | +| Other Unique Identifiers | Yes | CPE, Package URL (purl), or SWID tag | +| Dependency Relationship | Yes | Describes containment or dynamic link relationship | +| Author of SBOM Data | Yes | Entity that generated the SBOM | +| Timestamp | Yes | ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ | + +### Recommended Additional Fields + +| Field | Description | +|---|---| +| Hash | Cryptographic hash (SHA-256 preferred) of the component | +| License information | SPDX license identifier for the component | +| Known vulnerabilities | CVE references at time of generation | +| Download location | URL or repository where component was obtained | + +### SBOM Delivery Requirements + +- Format: SPDX (ISO 5962) or CycloneDX preferred +- Machine-readable: JSON or XML format required +- Delivery: provided at initial product delivery; updated with each release +- Retention: [Agency] retains SBOM for the operational life of the system +- Confidentiality: if SBOM contains sensitive supplier information, mark appropriately and share via secure channel + +### SBOM Consumption + +When an SBOM is received, the C-SCRM programme manager or ISSO should: +1. Ingest the SBOM into the organisation's SBOM management tool or vulnerability management system +2. Cross-reference components against the National Vulnerability Database (NVD) for known CVEs +3. Identify critical or sensitive components warranting enhanced monitoring +4. Retain SBOM in the system provenance record +5. Establish a process to re-check SBOM components against NVD at regular intervals (e.g., daily automated scan) + +--- + +## Critical Component Identification Worksheet + +Use this worksheet to identify and classify components requiring enhanced C-SCRM treatment: + +| Component | Function | Sensitivity | Single Source | Foreign Content | Criticality Level | +|---|---|---|---|---|---| +| [Component name] | [Security function / mission function / data processing] | [High / Medium / Low] | [Yes / No] | [Yes: country / No] | [Critical / High / Moderate / Low] | + +Scoring guidance: +- High sensitivity + security function + single source = Critical +- High sensitivity + mission function = High +- Medium sensitivity + commercial availability = Moderate +- Low sensitivity + commodity = Low + +**Critical designation triggers mandatory**: +- Enhanced provenance documentation (SR-4) +- Supplier assessment at Critical tier (SR-6) +- SBOM requirement (SR-5) +- Periodic inspection (SR-10) +- Anti-counterfeiting measures (SR-11) +- Disposal via secure destruction (SR-12) diff --git a/plugins/nist-sp-800-207/.claude-plugin/plugin.json b/plugins/nist-sp-800-207/.claude-plugin/plugin.json new file mode 100644 index 0000000..6d55115 --- /dev/null +++ b/plugins/nist-sp-800-207/.claude-plugin/plugin.json @@ -0,0 +1,21 @@ +{ + "name": "nist-sp-800-207", + "version": "1.0.0", + "description": "NIST SP 800-207 Zero Trust Architecture (ZTA) skill for designing, implementing, and migrating to zero trust architectures using the policy engine, policy administrator, and policy enforcement point model, covering ZTA tenets, deployment approaches, enhanced identity governance, microsegmentation, software-defined networking, and migration from perimeter-based security models.", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@gmail.com" + }, + "homepage": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "repository": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "zero-trust", + "ZTA", + "policy-engine", + "microsegmentation", + "identity-governance", + "software-defined-networking", + "NIST" + ] +} diff --git a/plugins/nist-sp-800-207/skills/nist-sp-800-207/SKILL.md b/plugins/nist-sp-800-207/skills/nist-sp-800-207/SKILL.md new file mode 100644 index 0000000..3de6a07 --- /dev/null +++ b/plugins/nist-sp-800-207/skills/nist-sp-800-207/SKILL.md @@ -0,0 +1,332 @@ +--- +name: nist-sp-800-207 +description: > + NIST SP 800-207 Zero Trust Architecture (ZTA) skill. Answers questions about the seven ZTA tenets, + the logical ZTA components (Policy Engine, Policy Administrator, Policy Enforcement Point), three + ZTA deployment approaches (enhanced identity governance, microsegmentation, network infrastructure + and software-defined networking), ZTA logical components and data flows, trust algorithm inputs and + design, ZTA deployment scenarios for enterprise and federated identity, threats to ZTA implementations, + the CISA Zero Trust Maturity Model alignment, migrating from implicit-trust networks to zero trust, + ZTA use cases for remote work and multi-cloud, subject and resource identification in zero trust, + continuous validation and authorisation for each session, and preventing lateral movement through + ZTA network segmentation. +--- + +# NIST SP 800-207 — Zero Trust Architecture (ZTA) + +**Source**: NIST Special Publication 800-207, August 2020 +**Full Title**: Zero Trust Architecture +**CSRC URL**: https://csrc.nist.gov/publications/detail/sp/800-207/final + +--- + +## Zero Trust Definition + +Zero trust is a set of guiding principles for system and network design where the guiding principle is: **implicit trust is never granted to any subject, asset, or workflow based solely on physical location, network location, or ownership**. All access requests are authenticated, authorised, and continuously validated before access is granted or retained. + +Zero Trust Architecture (ZTA) is an enterprise cybersecurity architecture based on zero trust principles designed to prevent data breaches and limit internal lateral movement. + +--- + +## The Seven Zero Trust Tenets + +NIST SP 800-207 defines seven tenets that form the conceptual foundation for ZTA: + +### Tenet 1 — All Data Sources and Computing Services Are Considered Resources +All devices (including personal devices), all applications, all services, all data stores — regardless of whether they are on-premises, in the cloud, or remote — are considered resources subject to ZTA policy. An enterprise-owned network is not automatically a safe zone. + +### Tenet 2 — All Communication Is Secured Regardless of Network Location +Network location alone does not imply trust. All communication — whether on the enterprise network, across the internet, or between internal components — must be authenticated and encrypted. Being inside the firewall does not grant implicit trust. + +### Tenet 3 — Access to Individual Enterprise Resources Is Granted on a Per-Session Basis +Trust in prior sessions does not carry over. Each access request to a resource is evaluated independently. Resources include applications, data stores, services, devices, and APIs. + +### Tenet 4 — Access to Resources Is Determined by Dynamic Policy +Access decisions are made by examining the current state of the client identity, the application or service, the device health posture, and the requested resource. Policy is dynamic and includes observable state information at the time of access. Static, role-based access alone is insufficient. + +### Tenet 5 — Integrity and Security Posture of All Owned and Associated Devices Is Monitored +The enterprise monitors the security posture of all devices — managed, unmanaged, user-owned — that access resources. Device compliance, patch level, and security configuration contribute to access decisions. + +### Tenet 6 — All Resource Authentication and Authorisation Is Dynamic and Strictly Enforced +Authentication and authorisation are continually re-evaluated throughout the session. Reauthentication events may be triggered by changes in risk or context (e.g., change in location, elevated privilege request, anomalous behaviour detection). Long-standing sessions are not automatically maintained. + +### Tenet 7 — The Enterprise Collects Information About the Current State of Assets, Network, and Communications and Uses It to Improve Security Posture +ZTA requires continuous collection of telemetry on user behaviour, device health, network traffic, and resource access. This information feeds the trust algorithm and the improvement of future policy decisions. + +--- + +## ZTA Logical Components + +NIST SP 800-207 defines the following core logical components: + +### Policy Engine (PE) +The PE is responsible for the ultimate decision to grant, deny, or revoke access to a resource for a given subject. The PE uses enterprise policy and input from external sources (threat intelligence, identity providers, device compliance) to compute a trust score and make the access decision. + +**PE Inputs used in the trust algorithm**: +- User/subject identity (from IdP) +- Device identity and health posture (from endpoint detection/MDM) +- Resource requested and its classification +- Behavioural analytics and historical access patterns +- Threat intelligence feeds +- Time of day, location, and network characteristics +- Privilege level required for the request + +**PE Decisions**: Grant access, deny access, or grant with reduced privilege/additional verification. + +### Policy Administrator (PA) +The PA executes the PE's decision by establishing or terminating communication between the subject and the resource. The PA communicates with the Policy Enforcement Point. + +**PA Functions**: +- Generates session-specific credentials or tokens for the approved communication path +- Configures the network to allow the communication (sends signal to PEP) +- Tears down sessions when policy dictates + +### Policy Enforcement Point (PEP) +The PEP is the mechanism that controls access to resources. It receives configuration from the PA and allows, denies, or terminates connections between subjects and resources. + +**PEP Types**: +- Single-component PEP that handles both request interception and enforcement +- Split-component PEP: a client-side agent (initiating PEP) that communicates with an infrastructure-side PEP (terminating PEP) + +**PEP Position**: Each enterprise resource must have a PEP. No resource is accessible without passing through a PEP that enforces ZTA policy. + +### Supporting Components + +| Component | Function | +|---|---| +| Continuous Diagnostics and Mitigation (CDM) System | Provides device posture data from managed assets | +| Industry Compliance System | Provides compliance information (FISMA status, SOC 2, etc.) | +| Threat Intelligence Feed(s) | Provides information about discovered vulnerabilities and known compromised identities | +| Network and System Activity Logs | Aggregated monitoring for behavioural analytics and anomaly detection | +| Data Access Policy | Rules governing what subjects can access what resources under what conditions | +| Enterprise PKI | Provides X.509 certificates to resources and subjects to establish identity | +| ID Management System (IdP/IAM) | Source of truth for identity information and authentication of subjects | +| Security Information and Event Management (SIEM) | Aggregates log data for monitoring and threat detection | + +--- + +## Trust Algorithm + +The trust algorithm (TA) is the process used by the PE to evaluate each access request and compute a trust level. + +### Trust Algorithm Inputs +1. Access request (subject identity + device + resource + action) +2. Subject database (role, assignment, attributes, past behaviour) +3. Device database (device compliance, patch level, ownership status) +4. Subject/device behaviour analytics (deviation from baseline) +5. Threat intelligence (known compromised accounts, known malicious IPs) +6. Resource policy (data access policy, resource classification) + +### Trust Algorithm Approaches + +**Criteria-based (Boolean policy)**: +- Define explicit criteria that must ALL be met for access +- Example: User must be in the Security Administrator role AND device must be organisation-managed AND device must have MFA enabled AND no active threat indicators on the device +- Advantage: Predictable; easy to audit +- Limitation: May be too rigid for dynamic environments + +**Score/confidence-based**: +- Assign trust scores to each input; combine into an overall trust score +- Access is granted if the score exceeds the threshold for the requested resource +- Allows partial signals to influence the decision without binary exclusions +- Advantage: More flexible; adaptive to partial information +- Limitation: More complex to design, tune, and explain + +**Historical behaviour-based (ML)**: +- Model normal behaviour for each subject/device pair +- Flag anomalies as risk indicators that the TA considers +- Advantage: Detects insider threats and compromised credentials not caught by static criteria +- Limitation: Requires training period; risk of false positives; explainability challenges + +--- + +## Three ZTA Deployment Approaches + +NIST SP 800-207 describes three primary approaches to implementing ZTA in enterprise environments: + +### Approach 1 — Enhanced Identity Governance (EIG) + +**Concept**: The primary signal driving access decisions is the identity of the subject (user, service account). Resource access policy is defined based on identity attributes rather than network location. + +**Key characteristics**: +- Strong, phishing-resistant authentication for all subjects (FIDO2, PIV, smart card) +- Identity as the primary perimeter +- All resources protected by identity-aware proxies or identity-aware access gateways +- Device identity used as a secondary signal + +**Best suited for**: +- Organisations with mature identity and access management (IAM) +- Environments with a mix of on-premises and cloud resources +- Organisations leveraging SaaS extensively + +**Implementation steps**: +1. Deploy a centralised, authoritative identity provider (IdP) for all users and service accounts +2. Enforce MFA for all access to enterprise resources (phishing-resistant for privileged access) +3. Integrate all resource access through identity-aware proxies (e.g., BeyondCorp-style proxy) +4. Implement device management/compliance signals as secondary inputs +5. Define access policy as identity-attribute-based rules in the PE +6. Monitor access decisions and continuously tune policy + +### Approach 2 — Microsegmentation + +**Concept**: Place security perimeters around individual workloads and resources. Each workload communicates only with the resources it explicitly needs to; all other traffic is denied by default. + +**Key characteristics**: +- East-west traffic control (server-to-server within the same data centre or cloud environment) +- Workload identity is the basis for communication policy +- Software-based enforcement (does not require physical network segmentation) +- Dramatically limits lateral movement after initial compromise + +**Implementation mechanisms**: +- Host-based agents (software enforced on each workload) +- Hypervisor-based segmentation (enforcement in the virtualisation layer) +- Cloud-native security groups and network ACLs (AWS Security Groups, Azure NSGs) + +**Best suited for**: +- Data centre and cloud workload environments +- Organisations with complex east-west traffic patterns +- RansomWare mitigation and lateral movement prevention + +**Implementation steps**: +1. Map all workload communication flows (what talks to what and on what ports) +2. Define communication policy: allow explicitly needed flows; deny all others (allowlist model) +3. Deploy microsegmentation enforcement (agent, hypervisor, or cloud-native) +4. Begin in monitoring mode to validate policy completeness before enforcement +5. Switch to enforcement mode starting with the most critical segments +6. Continuously monitor for policy violations and new communication patterns + +### Approach 3 — Network Infrastructure and Software-Defined Networking (SDN) + +**Concept**: Use SDN and network infrastructure changes to implement network access control aligned with ZTA. Access is controlled at the network level based on continuous assessment of device and user state. + +**Key characteristics**: +- Dynamic network segmentation based on current context (not static VLANs) +- Software-defined perimeters (SDP) can create application-specific access tunnels +- Network access control (NAC) integrated with identity and device posture +- Software-Defined Perimeter (SDP) / Zero Trust Network Access (ZTNA) products + +**Key technologies**: +- Software-Defined Perimeter (SDP): creates one-to-one encrypted network connections between subject and resource; resources are dark (not network-accessible) without a valid SDP session +- Zero Trust Network Access (ZTNA): commercial implementations of SDP-style access; user authenticates to a proxy; proxy grants access to specific resources +- SD-WAN with ZTA integration: dynamic routing based on security posture + +**Best suited for**: +- Remote workforce environments +- Organisations replacing legacy VPN concentrators +- Multi-cloud environments requiring consistent network-layer access control + +--- + +## ZTA Deployment Scenarios + +### Scenario 1 — Employee Access to Enterprise Resources +Subject: Enterprise user on a managed laptop +ZTA implementation: +- User authenticates to IdP (Approach 1: EIG) +- Device posture verified (patch compliance, EDR agent active) +- PE grants access to specific applications based on role and device health +- PEP (identity-aware proxy or ZTNA product) enforces access +- No implicit access to other resources based on network position + +### Scenario 2 — Remote Work and BYOD +Subject: Enterprise user on a personally owned device +ZTA implementation: +- User authenticates using phishing-resistant MFA +- Device posture is limited (unmanaged); device trust score is lower +- PE limits access to lower-sensitivity resources; blocks access to high-sensitivity resources from unmanaged device or requires VDI/cloud-based access +- PEP enforces the limited access grants + +### Scenario 3 — Service Account / Workload-to-Workload +Subject: Application or service calling an API or accessing a data store +ZTA implementation: +- Service uses workload identity (certificate, OAuth client credentials, cloud IAM service account) +- PE evaluates workload identity + destination resource + time/request characteristics +- Microsegmentation (Approach 2) enforces that only the authorised workload can reach the target +- No standing network-level access; per-request authorisation + +### Scenario 4 — Third-Party / Contractor Access +Subject: Non-enterprise user accessing a subset of enterprise resources +ZTA implementation: +- Federated identity from the third party's IdP (SAML or OIDC federation) +- Access scope strictly limited by policy; no lateral movement into enterprise network +- Session monitoring elevated; shorter session timeouts +- ZTNA product creates scoped access without providing network-level access + +--- + +## Threats to ZTA Implementations + +NIST SP 800-207 Section 4 identifies threats specific to ZTA: + +| Threat | Description | Mitigation | +|---|---|---| +| Subversion of ZTA decision process | Compromising the PE, PA, or their communication channel gives the attacker control over all access decisions | High-availability PE/PA; integrity monitoring; privileged access management for ZTA admin functions | +| DoS attacks against ZTA components | Flooding the PE or PEP degrades availability of enterprise resources | Resilient, distributed PE/PA/PEP; rate limiting; CDN/DDoS protection for ZTA control plane | +| Stolen credentials / credential compromise | If the identity of a subject is compromised, ZTA grants access as if the legitimate user | Phishing-resistant MFA; behavioural analytics to detect anomalous access patterns; rapid credential revocation | +| Visibility and analytics gaps | If ZTA telemetry is incomplete, the trust algorithm cannot make informed decisions | Comprehensive log collection; SIEM integration; monitoring coverage for all PEPs | +| Network storage of ZTA data | Configuration data, policy, and logs could be targets for adversary exploitation | Encrypt ZTA configuration data; apply least privilege to ZTA administrative access | +| Compromised ZTA components | Supply chain attack against ZTA software components | C-SCRM practices (SP 800-161) for ZTA product acquisition; integrity verification before deployment | +| Insider threat | A legitimate user abusing granted access | Privilege separation; just-in-time access; user behaviour analytics; minimal standing access | + +--- + +## ZTA and Implicit Trust Network Migration + +Most enterprises operate legacy implicit-trust (castle-and-moat) networks. Migration is not instantaneous: + +### Migration Phases + +**Phase 1 — Identify and Inventory** +- Catalogue all subjects (users, service accounts) +- Catalogue all resources (applications, data stores, APIs, infrastructure) +- Map all communication flows between subjects and resources +- Identify trust dependencies (what relies on network location for trust) + +**Phase 2 — Prioritise and Define Policy** +- Prioritise resources by sensitivity +- Define initial ZTA policy starting with the highest-sensitivity resources +- Begin with Approach 1 (EIG) for user-to-application access (quickest win) + +**Phase 3 — Implement ZTA Controls Incrementally** +- Deploy strong authentication and IdP integration +- Implement ZTA access controls for selected high-priority resources +- Begin microsegmentation for critical workloads +- Run in monitor-only mode before enforcing + +**Phase 4 — Expand and Refine** +- Extend ZTA coverage to all resources +- Enforce microsegmentation across all workloads +- Retire VPN/implicit trust network paths as ZTA coverage replaces them +- Continuously tune the trust algorithm based on operational experience + +**Phase 5 — Steady State** +- All resource access through ZTA policy enforcement +- Continuous monitoring and telemetry feeding the trust algorithm improvement +- Regular policy review and update cycle aligned to threat intelligence + +--- + +## CISA Zero Trust Maturity Model Alignment + +CISA's Zero Trust Maturity Model (ZTMM) provides a five-pillar, four-stage framework aligned to NIST SP 800-207: + +**Five Pillars**: +1. Identity +2. Devices +3. Networks +4. Applications and Workloads +5. Data + +**Four Maturity Stages** (per pillar): +- Traditional: Perimeter-based, static controls, limited visibility +- Initial: Beginning implementation of zero trust-aligned controls +- Advanced: Dynamic access decisions, deeper automation +- Optimal: Fully dynamic, continuous, AI/ML-assisted access decisions + +--- + +## Reference Files + +- `references/zta-components.md` — Logical ZTA component detail, trust algorithm inputs, data flows, and deployment component diagrams +- `references/deployment-approaches.md` — Detailed implementation guidance for each of the three ZTA approaches with technology examples and step-by-step procedures +- `references/migration-guide.md` — ZTA migration planning, CISA ZTMM alignment, ZTA use cases, threat mitigation patterns, and integration with SP 800-53 controls diff --git a/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/deployment-approaches.md b/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/deployment-approaches.md new file mode 100644 index 0000000..08e2a7a --- /dev/null +++ b/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/deployment-approaches.md @@ -0,0 +1,204 @@ +# NIST SP 800-207 — ZTA Deployment Approaches: Implementation Guidance + +**Source**: NIST SP 800-207, August 2020, Section 5 + +--- + +## Approach 1 — Enhanced Identity Governance (EIG) + +### Overview + +The EIG approach treats identity as the primary security perimeter. All enterprise resources are protected by identity-aware access controls. Access decisions are driven by the quality and attributes of the identity assertion rather than network location. This is often the most practical starting point for organisations adopting ZTA. + +### Implementation Steps + +**Step 1 — Centralise and Harden Identity** + +Establish or consolidate to a single authoritative Identity Provider: +- All user accounts, service accounts, and machine identities managed in one IdP (or federated IdPs with a clear trust hierarchy) +- Implement phishing-resistant MFA for all access to enterprise resources + - For privileged accounts: FIDO2/WebAuthn hardware keys or PIV/CAC required + - For standard users: FIDO2, authenticator apps acceptable; SMS is not recommended +- Implement passwordless authentication where possible (FIDO2 passkeys) +- Enable and enforce conditional access policies in the IdP + +**Step 2 — Inventory All Resources and Define Access Policy** + +- Enumerate all enterprise applications, APIs, and data stores +- Classify each resource by sensitivity (Low/Moderate/High aligned to FIPS 199) +- For each resource, define the identity attributes required for access: + - Example: Application X requires: role = SecurityAnalyst AND department = SOC AND device = managed AND AAL >= 2 +- Document the access policy in the PE or in a policy management tool + +**Step 3 — Deploy Identity-Aware Access Gateway or Proxy** + +Deploy an identity-aware proxy that sits in front of each resource (or group of resources): +- The proxy is the PEP; it intercepts all access requests +- The proxy authenticates the user against the IdP for every session +- The proxy evaluates the session's identity attributes against the resource policy +- If the session meets policy requirements: the proxy forwards the request to the resource +- If not: the proxy returns a denial or redirects to step-up authentication + +Technology options: +- Cloud-native identity-aware proxies (BeyondCorp Enterprise, Azure AD Application Proxy, AWS Verified Access) +- Web Application Firewalls with identity integration (WAF + IdP integration) +- API gateways with JWT/OAuth 2.0 enforcement + +**Step 4 — Integrate Device Posture** + +Device health should be a secondary signal in the trust decision: +- Deploy MDM and/or endpoint detection and response (EDR) to managed devices +- Configure the IdP or access gateway to query device compliance status at authentication time +- Define policy: if device is not managed or is non-compliant, limit access to lower-sensitivity resources +- For user-owned devices: require access through a VDI/browser-based solution that does not land data on the unmanaged device + +**Step 5 — Implement Session Revocation** + +ZTA requires the ability to revoke a session immediately when conditions change: +- Enable token revocation in the IdP (OAuth 2.0 token revocation, SAML session termination) +- Integrate the PE with the IdP so that a PE-initiated revocation immediately terminates the token +- Test the revocation path to confirm it terminates active sessions within a defined time window + +**Step 6 — Enable Continuous Monitoring** + +- Log all access decisions (grant, deny, step-up required) to SIEM +- Alert on policy violations and anomalous access patterns +- Periodically review access policies and prune over-privileged role assignments +- Conduct quarterly access reviews for privileged roles + +--- + +## Approach 2 — Microsegmentation + +### Overview + +Microsegmentation creates individually secured segments around each workload. Communication between workloads is permitted only if explicitly allowed by policy; all other traffic is denied by default. This approach directly limits east-west lateral movement and is critical for data centre and cloud workload security. + +### Implementation Steps + +**Step 1 — Map All Workload Communication Flows** + +This step is often the most time-consuming and critical: +- Use network traffic analysis tools to capture all east-west and north-south flows for a sufficient baseline period (two to four weeks minimum for most environments) +- Document: source workload, destination workload, protocol, port, business justification +- Include: application-to-database flows, application-to-middleware, monitoring agent flows, logging flows, backup agent flows +- Identify and document all flows that cannot be explained; investigate before creating allowlist rules + +**Step 2 — Design the Segmentation Policy** + +- Define workload identities (labels, tags, or host-based attributes) +- Define policy groups (segments) based on function, sensitivity, or data classification + - Example segments: web tier, application tier, database tier, management/bastion, monitoring +- Define allowed flows between segments (minimum necessary communication principle) +- Explicitly deny all other inter-segment communication + +**Step 3 — Select Enforcement Mechanism** + +| Mechanism | Technology | Best For | +|---|---|---| +| Host-based agent | Illumio, Guardicore (Akamai Guardicore), Cisco Secure Workload | Heterogeneous environments; bare metal and VM | +| Hypervisor-based | VMware NSX, AWS Security Groups (for EC2) | Virtualised data centres, single hypervisor environments | +| Cloud-native | AWS Security Groups, Azure NSGs, Google Cloud Firewall Rules | Cloud-native workloads in a single CSP | +| Service mesh | Istio/Envoy, Linkerd | Containerised microservices (Kubernetes) | + +**Step 4 — Deploy in Monitor-Only Mode** + +Before enforcement: +- Deploy the selected mechanism in visibility/monitoring mode +- Verify that the captured flow map matches the actual observed traffic +- Identify any flows not in the policy that are needed for operations (missing legitimate flows) +- Update the policy to add any missing legitimate flows +- Confirm with application owners that the planned policy is complete + +**Step 5 — Enable Enforcement — Staged** + +Enable enforcement incrementally to minimise operational impact: +- Stage 1: Enable enforcement for the most critical segments (database tier, sensitive data stores) +- Monitor for policy violations (blocked flows); investigate and resolve +- Stage 2: Extend enforcement to application tier +- Continue rolling out enforcement segment by segment + +**Step 6 — Maintain and Monitor** + +- Alert on any blocked east-west traffic (every deny event should be reviewed) +- Update the segmentation policy when application changes require new communication paths +- Periodically re-run the traffic baseline analysis to identify new flows (after major application changes) +- Include segmentation policy review in change management for application deployments + +--- + +## Approach 3 — Software-Defined Networking (SDN) and Software-Defined Perimeter (SDP) + +### Overview + +This approach uses network infrastructure capabilities — SDN, ZTNA products, software-defined perimeters — to implement dynamic access control at the network level. It is particularly effective for remote workforce access, replacing legacy VPN, and multi-cloud access control. + +### Software-Defined Perimeter (SDP) Architecture + +SDP makes enterprise resources invisible to unauthorised users. A client must authenticate before the resource is even reachable (pre-authentication darkness): + +1. Client sends authentication request to the SDP Controller (serves as both PE and PA) +2. Controller verifies identity (IdP) and device posture +3. If approved: Controller instructs the SDP Gateway (PEP) to allow the client's specific IP/token +4. Controller provides the client with the gateway address and session token +5. Client establishes an encrypted tunnel to the gateway +6. Gateway forwards only authenticated, authorised traffic to the resource + +**Key SDP property**: The resource is not exposed on any network until the client is authenticated. There is no DNS or IP address to scan; reconnaissance is blocked. + +**Standards**: SDP is defined by the Cloud Security Alliance (CSA) SDP Specification. + +### Zero Trust Network Access (ZTNA) Products + +ZTNA products are commercial implementations of SDP-style access. They replace legacy VPN concentrators: + +| Feature | Legacy VPN | ZTNA | +|---|---|---| +| Network access | Full network segment access after authentication | Per-application or per-resource access only | +| Device posture check | Typically minimal or at connection only | Continuous device posture evaluation | +| Lateral movement | Broad access enables lateral movement | Per-resource access prevents lateral movement | +| Visibility | Limited in-tunnel visibility | Full access event logging to SIEM | +| User experience | Tunnel-based (can be slow; split tunnel issues) | Direct-to-resource access often faster | +| Resource visibility | Resources exposed to authenticated network | Resources dark; not reachable without ZTNA session | + +**ZTNA deployment models**: +- Agent-based: Client agent on device participates in every access request; provides richer device posture data +- Agentless: Browser-based; no agent required; limited device posture data; suited for BYOD and contractor access + +### SDN-Based Dynamic Segmentation + +In SDN environments, the network fabric can be programmatically reconfigured to reflect current access policy: +- SDN controller receives access decisions from PE/PA +- SDN controller dynamically provisions network paths for approved sessions +- No static VLANs or ACLs; all network paths are provisioned on-demand +- Reduces attack surface since no persistent network paths exist + +### Implementation Steps for ZTNA Deployment + +1. **Define access scope**: Identify the resources that will be protected by ZTNA (start with remote access use case) +2. **Select ZTNA product**: Evaluate against requirements (agent-based vs. agentless, IdP integration, device posture, SIEM integration) +3. **Configure connectors**: Deploy ZTNA connectors near each protected resource or application group +4. **Define access policy in ZTNA**: Map users/groups to applications using the ZTNA policy engine +5. **Pilot**: Deploy to a subset of users; validate access, performance, and logging +6. **Roll out**: Expand to all remote users; decommission legacy VPN concentrators for covered resources +7. **Monitor**: Review access logs; alert on anomalous access patterns; tune policy + +--- + +## Hybrid Approaches + +Most real-world ZTA implementations combine elements of all three approaches: + +| Layer | Approach Applied | +|---|---| +| User-to-Application (remote) | Approach 3 — ZTNA replaces VPN | +| User-to-Application (on-premises) | Approach 1 — EIG: identity-aware proxy, IdP-driven policy | +| Workload-to-Workload | Approach 2 — Microsegmentation: service mesh or agent-based | +| Privileged Access | Approach 1 + 3 — EIG with phishing-resistant MFA + ZTNA/PAM for privileged sessions | +| Data-Layer | Approach 1 — Attribute-based access control at the data service level | + +The recommended sequence for most federal agencies: +1. Start with Approach 1 (EIG) — deploy strong authentication and identity-aware access for the highest-priority applications +2. Simultaneously pursue Approach 2 (microsegmentation) for the highest-criticality workloads +3. Add Approach 3 (ZTNA) to replace legacy VPN for remote access +4. Expand coverage iteratively until all resources are under ZTA policy diff --git a/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/migration-guide.md b/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/migration-guide.md new file mode 100644 index 0000000..26e8e31 --- /dev/null +++ b/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/migration-guide.md @@ -0,0 +1,219 @@ +# NIST SP 800-207 — ZTA Migration Guide, CISA ZTMM, and SP 800-53 Alignment + +**Source**: NIST SP 800-207, August 2020; CISA Zero Trust Maturity Model v2.0, April 2023 + +--- + +## ZTA Migration Assessment + +Before beginning migration, assess the organisation's current state and readiness: + +### Current-State Assessment Checklist + +**Identity and Access Management** +- [ ] Single authoritative IdP exists (or a federated set with clear hierarchy) +- [ ] MFA deployed for at least privileged accounts +- [ ] MFA deployed for all remote access +- [ ] Phishing-resistant MFA deployed for all privileged accounts (FIDO2, PIV) +- [ ] Role-based access control enforced; no shared accounts +- [ ] Password policy aligned to SP 800-63B (length over complexity; no mandatory rotation) +- [ ] Service accounts inventoried; credentials managed; non-interactive where possible + +**Device Management** +- [ ] All enterprise-managed devices enrolled in MDM +- [ ] Device inventory complete and current +- [ ] Patch compliance rate >= 95% for critical patches +- [ ] Endpoint detection and response (EDR) deployed on all managed devices +- [ ] Device compliance policies defined and enforced +- [ ] Unmanaged device access policy defined + +**Network** +- [ ] Network flow map exists and is current +- [ ] East-west traffic visibility available (NetFlow, NDR, or equivalent) +- [ ] No flat internal network with full lateral movement capability (some segmentation exists) +- [ ] Remote access uses MFA (even if VPN; ZTNA migration pending) + +**Applications and Workloads** +- [ ] Application inventory exists and is current +- [ ] Applications classified by sensitivity (Low/Moderate/High) +- [ ] Critical applications support modern authentication (SAML, OIDC) +- [ ] Legacy applications with no modern auth support identified (migration challenge) + +**Data** +- [ ] Data classified and labelled (sensitivity classifications applied) +- [ ] Sensitive data locations known (on-premises data stores, cloud, SaaS) +- [ ] Data access audit logging enabled + +**Monitoring and Analytics** +- [ ] SIEM collecting logs from all critical systems +- [ ] Access logs centralised +- [ ] Anomaly detection or UEBA capability available or planned + +--- + +## ZTA Migration Roadmap + +### Phase 1 — Foundation (Months 1–6) +Priority: Build the identity and visibility foundation on which ZTA depends. + +| Activity | Owner | Success Criterion | +|---|---|---| +| Deploy phishing-resistant MFA for all privileged accounts | IAM Team | 100% of privileged accounts on FIDO2 or PIV | +| Enroll all managed devices in MDM | Endpoint Team | 100% of managed devices enrolled | +| Complete device inventory | Asset Management | Full device inventory, classified managed/unmanaged | +| Complete application inventory and sensitivity classification | Security Architecture | All applications inventoried and classified | +| Centralise log collection for all critical systems | SIEM Team | All critical systems logging to SIEM | +| Establish network flow visibility for east-west traffic | Network Team | East-west flows visible from SIEM/NDR | + +### Phase 2 — First ZTA Controls (Months 6–12) +Priority: Apply ZTA protection to the highest-sensitivity resources. + +| Activity | Owner | Success Criterion | +|---|---|---| +| Deploy identity-aware proxy for top 10 highest-sensitivity applications | Security Architecture + IAM | Proxy in place; legacy direct access removed | +| Enable device posture signals in access policy for high-sensitivity apps | IAM + Endpoint Teams | Compliance status checked at every access request | +| Deploy ZTNA for remote access to high-sensitivity applications | Network + Security Teams | Remote users accessing high-sensitivity apps via ZTNA | +| Implement microsegmentation for database tier | Network + Security Teams | Database tier isolated; only approved app tiers can reach DBs | +| Establish behavioural analytics baseline | SIEM/UEBA Team | 90-day baseline established for active users | + +### Phase 3 — Broad ZTA Coverage (Months 12–24) +Priority: Extend ZTA to all resources; retire legacy implicit trust paths. + +| Activity | Owner | Success Criterion | +|---|---|---| +| Extend identity-aware proxy to all applications | Security Architecture | All applications behind PEP | +| Enforce MFA for all enterprise resource access | IAM Team | 100% MFA coverage across all access paths | +| Extend microsegmentation to all workload tiers | Network + Security Teams | All workload communication enforced via segmentation policy | +| Replace VPN with ZTNA for all remote access | Network Team | Legacy VPN decommissioned for covered user population | +| Define and enforce unmanaged device policy | IAM + Endpoint Teams | Unmanaged devices restricted to approved applications only | +| Enable anomaly detection alerts from behavioural analytics | SOC | SOC receiving and triaging UEBA alerts | + +### Phase 4 — Optimise (Months 24+) +Priority: Achieve ongoing authorisation, automated policy, and continuous improvement. + +| Activity | Owner | Success Criterion | +|---|---|---| +| Implement just-in-time (JIT) privileged access | IAM + PAM Teams | No standing privileged access; all privilege granted on-demand | +| Enable automated policy adjustment from threat intelligence | PE/SOC Teams | PE trust algorithm incorporating live threat intel | +| Data-layer ZTA (ABAC at data service level) | Data + Security Teams | Data access enforced by attributes at the data service level | +| ZTA coverage audit complete | Security Architecture | No resource accessible without ZTA PEP | +| Achieve CISA ZTMM Advanced level across all five pillars | CISO | ZTMM self-assessment showing Advanced in all pillars | + +--- + +## CISA Zero Trust Maturity Model (ZTMM) Alignment + +The CISA ZTMM v2.0 (April 2023) defines maturity across five pillars. Each pillar has four stages. + +### Pillar 1 — Identity + +| Stage | Characteristics | +|---|---| +| Traditional | Static, manual lifecycle management; limited MFA use; centralised IdP absent | +| Initial | Some MFA; limited centralisation; limited attribute-based access | +| Advanced | MFA fully deployed; risk-based access decisions; phishing-resistant MFA for privileged; automated lifecycle management | +| Optimal | Continuous validation; dynamic access based on full context; passwordless; ML-assisted anomaly detection | + +**SP 800-207 Alignment**: Identity is Approach 1 (EIG). NIST SP 800-63B defines the authentication assurance levels (AAL) that feed the ZTA trust algorithm. + +### Pillar 2 — Devices + +| Stage | Characteristics | +|---|---| +| Traditional | Limited device inventory; manual patching; no integration with access decisions | +| Initial | MDM deployed for managed devices; device compliance partially integrated | +| Advanced | All devices inventoried; compliance enforced in access policy; EDR fully deployed | +| Optimal | Continuous device trust assessment; automated isolation of non-compliant devices; AI/ML device anomaly detection | + +**SP 800-207 Alignment**: Device posture is a key trust algorithm input (Tenet 5). CDM provides device compliance data. + +### Pillar 3 — Networks + +| Stage | Characteristics | +|---|---| +| Traditional | Flat internal network; VPN for remote access; minimal segmentation | +| Initial | Some macro-segmentation (VLANs); VPN with MFA | +| Advanced | Microsegmentation of critical workloads; ZTNA deployed for remote access | +| Optimal | All resources behind ZTA PEP; no implicit trust based on network location; dynamic segmentation; all remote access through ZTNA | + +**SP 800-207 Alignment**: Approach 2 (microsegmentation) and Approach 3 (SDN/ZTNA) address this pillar. + +### Pillar 4 — Applications and Workloads + +| Stage | Characteristics | +|---|---| +| Traditional | Applications not integrated with IdP; no per-application access control; limited logging | +| Initial | Some applications integrated with IdP; basic per-application access control | +| Advanced | Most applications integrated with IdP; per-application access policy; workload-to-workload authentication | +| Optimal | All applications behind ZTA PEP; continuous authorisation during session; API security enforced; CI/CD pipeline security | + +**SP 800-207 Alignment**: PEP coverage of all applications is core to ZTA. Workload identity maps to Approach 2 and service mesh implementations. + +### Pillar 5 — Data + +| Stage | Characteristics | +|---|---| +| Traditional | No data classification; no data access audit; encryption inconsistent | +| Initial | Some data classification; encryption at rest and in transit for sensitive data | +| Advanced | Consistent data classification and labelling; attribute-based access control at data layer; DLP deployed | +| Optimal | All data classified and labelled; access enforced at the data level (ABAC); automated data protection based on classification; full data access audit | + +**SP 800-207 Alignment**: Data-layer ZTA is the most mature ZTA application. SP 800-207 Tenet 1 (all data is a resource) drives data-layer enforcement. + +--- + +## ZTA and SP 800-53 Rev 5 Control Alignment + +ZTA implementation contributes to or satisfies the following SP 800-53 controls: + +| SP 800-53 Control | ZTA Component/Approach | Contribution | +|---|---|---| +| AC-2 Account Management | IdP + EIG | Centralised account lifecycle management; inactive account detection | +| AC-3 Access Enforcement | PE + PEP | Per-session, attribute-based access enforcement at every resource | +| AC-4 Information Flow Enforcement | PEP + Microsegmentation | Microsegmentation enforces information flow policy | +| AC-17 Remote Access | ZTNA / Approach 3 | ZTNA replaces VPN; provides ZTA-aligned remote access | +| AC-20 Use of External Systems | ZTNA + EIG | Third-party and BYOD access controlled through ZTA | +| AU-2/AU-3 Audit Events/Content | ZTA logging | All PE decisions and PEP events logged to SIEM | +| IA-2 Identification and Authentication | IdP + MFA | Phishing-resistant MFA; AAL-aligned authentication | +| IA-3 Device Identification | Device identity + MDM | Cryptographic device identity as trust input | +| IA-5 Authenticator Management | IdP | Centralised credential lifecycle; MFA enforcement | +| SC-3 Security Function Isolation | ZTA control plane separation | PE/PA isolated from data plane | +| SC-7 Boundary Protection | PEP | PEP is the micro-boundary for every resource | +| SC-8 Transmission Confidentiality | ZTA encrypted sessions | All ZTA sessions use mutual TLS or equivalent | +| SC-39 Process Isolation | Microsegmentation | Workload isolation prevents cross-workload access | +| SI-4 System Monitoring | ZTA telemetry + SIEM | Access event monitoring; behavioural analytics for anomaly detection | + +--- + +## ZTA Threat Mitigation Summary + +| Threat | ZTA Controls That Mitigate It | +|---|---| +| Phishing (credential theft) | Phishing-resistant MFA (FIDO2, PIV) removes password from the authentication equation | +| Lateral movement after initial compromise | Microsegmentation prevents compromised workload from accessing other resources; per-session authorisation prevents reuse of prior access | +| Privilege escalation | JIT privileged access; PE evaluates every privileged access request; no standing privilege | +| Stolen device | Device health check fails for stolen/wiped device; MDM remote wipe; session revocation | +| Insider threat | Least privilege enforced by PE; no implicit access; all access logged; UEBA anomaly detection | +| Compromised service account | Service accounts have minimum required scope; workload identity per-request authorisation; UEBA on service account behaviour | +| Man-in-the-middle attack | Mutual TLS for all ZTA control plane and data plane communication; certificate pinning where supported | +| Ransomware lateral movement | Microsegmentation (Approach 2) blocks east-west spread; device quarantine on EDR alert through PE policy update | + +--- + +## Key ZTA Terms and Definitions + +| Term | Definition | +|---|---| +| Zero Trust | Security model in which implicit trust is never granted based on network location, physical location, or asset ownership | +| Zero Trust Architecture (ZTA) | Enterprise architecture applying ZTA principles; includes people, process, technology, and policy | +| Implicit trust | Trust granted based on network location (e.g., "you are on the corporate network, therefore you are trusted") — removed in ZTA | +| Policy Engine (PE) | ZTA component that makes the access grant/deny decision | +| Policy Administrator (PA) | ZTA component that executes the PE decision by configuring the PEP | +| Policy Enforcement Point (PEP) | ZTA component that controls the communication path between subject and resource | +| Trust Algorithm | Logic used by the PE to compute an access decision from input signals | +| Microsegmentation | Security practice of placing individual security perimeters around workloads | +| Software-Defined Perimeter (SDP) | Network security approach where resources are invisible until authenticated | +| ZTNA | Zero Trust Network Access — commercial product category implementing SDP-style access | +| Enhanced Identity Governance (EIG) | ZTA approach where identity is the primary access control signal | +| Session-based access | Access granted per session, not per user — each session is independently evaluated | +| Continuous validation | Re-evaluation of access conditions throughout a session, not only at session start | diff --git a/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/zta-components.md b/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/zta-components.md new file mode 100644 index 0000000..040feed --- /dev/null +++ b/plugins/nist-sp-800-207/skills/nist-sp-800-207/references/zta-components.md @@ -0,0 +1,201 @@ +# NIST SP 800-207 — ZTA Logical Components, Trust Algorithm, and Data Flows + +**Source**: NIST SP 800-207, August 2020, Sections 3.1–3.3 + +--- + +## ZTA Logical Architecture + +The ZTA logical architecture defines the components and data flows for all access decisions in a zero trust environment. + +### Core Component Relationship + +``` +Subject/Device --> [PEP: Initiating] --> [PA] <--> [PE] + | +Resource <---- [PEP: Terminating] <-------' +``` + +**Data flow for an access request**: +1. Subject (user or workload) requests access to a resource +2. The initiating PEP intercepts the request; passes it to the PA +3. The PA queries the PE with the access request context +4. The PE evaluates the request against policy using the trust algorithm +5. The PE returns the access decision (grant/deny/conditional) to the PA +6. If granted: the PA configures the terminating PEP to allow the specific communication; provides session credentials to the subject +7. The subject establishes a session with the resource through the configured PEP +8. The PE/PA monitor the session; can revoke if conditions change + +--- + +## Policy Engine (PE) — Detailed + +### PE Design Requirements + +**Availability**: The PE is a single point of failure for enterprise access. Requirements: +- High-availability deployment (active-active or active-passive clustering) +- Geographic redundancy for large enterprises +- Defined degraded mode policy (fail-open vs. fail-closed; fail-closed is preferred for security; fail-open preferred for availability — document the choice explicitly) + +**Isolation**: The PE must be heavily protected: +- Managed accounts for PE administration; MFA required for all PE admin access +- PE configuration stored encrypted with access limited to PE system itself and designated administrators +- Audit logging of all PE configuration changes, all access decisions, and all admin actions + +**Scalability**: The PE must evaluate access requests at the speed of enterprise operations: +- Caching of trust evaluations for unchanged context (time-bounded cache; re-evaluate on credential change or device state change) +- Distributed PE processing when single-node performance is insufficient + +### Trust Algorithm Input Sources and Trust Score Mapping + +| Input Source | Data Provided | Trust Impact | +|---|---|---| +| Identity Provider (IdP) | Authentication event, assurance level (AAL1/2/3), MFA method used | High weight: AAL3 (phishing-resistant) > AAL2 > AAL1 | +| Device compliance (MDM/EDR) | Patch level, encryption status, EDR agent active, jailbreak/root status | High weight for managed devices; lower weight for unmanaged | +| Behavioural analytics | Deviation from typical access time, location, resources accessed | Anomalies reduce trust; normal patterns increase trust | +| Threat intelligence feeds | Known compromised accounts, malicious IP reputation, active IOCs | Known compromise = deny; clean record = neutral | +| Resource classification | Data sensitivity level, regulatory scope | Sensitive = higher required trust score | +| Time/location context | Time of access, geo-location, network (corporate vs. public) | Contextual risk factors (off-hours + unusual location = reduced trust) | +| Previous session history | Prior access in this session; privilege escalation requests | Recent escalation requests increase scrutiny | + +### PE Decision Outputs + +**Grant**: Subject is permitted to access the resource. PA configures PEP accordingly. Session duration and re-evaluation interval are specified in the decision. + +**Grant with condition**: Access is granted subject to additional verification (e.g., step-up authentication). PA does not configure PEP until condition is met. + +**Deny**: Access is denied. PA does not configure PEP. The denial event is logged. + +**Quarantine/investigate**: An anomaly warrants investigation. Access may be denied pending review, or limited to low-sensitivity resources pending investigation. + +--- + +## Policy Administrator (PA) — Detailed + +### PA Functions + +**Session establishment**: +- Receives grant decision from PE +- Generates per-session credentials (tokens, certificates, temporary network paths) +- Configures the terminating PEP to allow the specific subject-to-resource communication +- Sets time-to-live (TTL) on the session per policy + +**Session maintenance**: +- Receives updates from PE on changes to trust conditions +- Revokes or modifies session if PE issues a revocation or downgrade instruction +- Sends keepalive/re-evaluation triggers to PE before session TTL expires + +**Session termination**: +- Tears down PEP configuration when session ends (user logs out, TTL expires, or PE revokes) +- Revokes session credentials + +### PA Security Requirements +- PA communicates with PE over an authenticated, encrypted channel (mutual TLS) +- PA must authenticate to each PEP using strong credentials +- PA configuration and session records protected against tampering +- Redundant PA deployment aligned with PE availability requirements + +--- + +## Policy Enforcement Point (PEP) — Detailed + +### PEP Types + +**Inline PEP (single component)**: +All traffic between subject and resource passes through the PEP. The PEP forwards allowed traffic and drops denied traffic. +- Typically an identity-aware proxy, reverse proxy, or ZTNA gateway +- Subject has no direct network path to the resource; all traffic goes through PEP +- Examples: cloud-native identity-aware proxy, ZTNA service, application gateway with identity integration + +**Split-component PEP**: +An agent on the subject device (client-side PEP) communicates with a server-side PEP. +- The client-side agent establishes the ZTA session; ensures device posture is reported +- The server-side PEP enforces access to the resource +- Used in ZTNA products where a client agent is deployed on managed devices +- Enables device posture to be included in each access request natively + +**Resource-native PEP**: +The resource itself performs enforcement (API gateway, service mesh sidecar proxy). +- Common in microservices architectures using service meshes (e.g., Envoy sidecar) +- Provides workload-to-workload zero trust through mutual TLS + identity verification + +### PEP Coverage Requirement + +ZTA requires that **every resource** be protected by a PEP. A resource accessible without passing through a PEP represents a zero trust gap. The PEP coverage audit is a key ZTA implementation validation step. + +**PEP coverage audit procedure**: +1. Enumerate all resources (using asset inventory) +2. For each resource: verify that network traffic cannot reach the resource without passing through a configured PEP +3. Document any gaps and create remediation plans +4. Re-audit after any infrastructure change + +--- + +## ZTA Data Plane and Control Plane + +ZTA separates the data plane (actual communication between subject and resource) from the control plane (access decision and enforcement configuration): + +**Control plane**: PE, PA, and the communication channel between them and to PEPs. Must be highly secured and separately monitored. + +**Data plane**: Communication between the subject and the resource, flowing through the PEP. The data plane is configured by the control plane. + +**Security implication**: If the control plane is compromised (PE or PA), the entire ZTA is compromised. The control plane requires the highest level of protection in the enterprise. + +--- + +## Supporting Infrastructure Components — Implementation Details + +### Identity Provider (IdP) + +| Requirement | Description | +|---|---| +| Authoritative source | Single authoritative IdP, or federation of trusted IdPs with clear trust hierarchy | +| MFA enforcement | MFA required for all enterprise resource access; phishing-resistant MFA (FIDO2/WebAuthn, PIV) for privileged access | +| Assurance levels | IdP must be capable of asserting authentication assurance level (AAL) per SP 800-63B | +| Continuous session | IdP must support session revocation and token revocation to enable ZTA session termination | +| Attributes | IdP must assert role, group membership, and other attributes needed by the PE trust algorithm | +| Federation | Support SAML 2.0 and OpenID Connect/OAuth 2.0 for federated enterprise and third-party identity | + +### Device Identity and Compliance + +| Requirement | Description | +|---|---| +| Device identity | Each managed device has a cryptographic identity (certificate from enterprise PKI or device attestation from TPM) | +| MDM/EDM integration | Device compliance data (patch level, encryption, EDR status) fed to PE in real time or near-real time | +| Unmanaged devices | Policy must address unmanaged (BYOD) devices: typically permit access only to lower-sensitivity resources or via isolated VDI | +| Device health check | At each access request, device health data must be current (not stale cache older than the defined maximum) | + +### Behavioural Analytics + +| Requirement | Description | +|---|---| +| Baseline establishment | Establish baseline of normal access patterns per user, per role, per device over a learning period | +| Anomaly detection | Flag: unusual time of access, unusual resource access, unusual geographic location, unusual volume of access, credential sharing indicators | +| Feed to PE | Anomaly scores fed to PE as a trust input; anomaly does not necessarily deny access but reduces trust score | +| Tuning | Analyst review of flagged anomalies to reduce false positives; tune model based on confirmed benign vs. malicious events | + +--- + +## ZTA Component Inventory Template + +Use this inventory to document ZTA component deployment: + +| Component | Product/Technology | Version | Deployment Location | High Availability | Integration Status | +|---|---|---|---|---|---| +| Policy Engine | [Product] | [Version] | [On-prem / Cloud / SaaS] | [Active-Active / Active-Passive / None] | [Complete / Partial / Planned] | +| Policy Administrator | [Product] | [Version] | [Location] | [HA status] | [Integration status] | +| PEP — User Access | [Product] | [Version] | [Location] | [HA status] | [Status] | +| PEP — Workload | [Product] | [Version] | [Location] | [HA status] | [Status] | +| Identity Provider | [Product] | [Version] | [Location] | [HA status] | [Status] | +| Device Compliance | [MDM/EDR product] | [Version] | [Location] | [HA status] | [Status] | +| SIEM | [Product] | [Version] | [Location] | [HA status] | [Status] | +| Threat Intel Feed | [Source] | N/A | [Integration point] | N/A | [Status] | +| Behavioural Analytics | [Product] | [Version] | [Location] | [HA status] | [Status] | + +--- + +## ZTA Coverage Gap Assessment + +| Resource | PEP Protected | Identity Auth Required | Device Posture Checked | Behavioural Analytics | Gap | Remediation Plan | +|---|---|---|---|---|---|---| +| [Application name] | Yes / No | Yes / No | Yes / No | Yes / No | [List gaps] | [Plan] | diff --git a/plugins/nist-sp-800-218/.claude-plugin/plugin.json b/plugins/nist-sp-800-218/.claude-plugin/plugin.json new file mode 100644 index 0000000..344edab --- /dev/null +++ b/plugins/nist-sp-800-218/.claude-plugin/plugin.json @@ -0,0 +1,22 @@ +{ + "name": "nist-sp-800-218", + "version": "1.0.0", + "description": "NIST SP 800-218 Secure Software Development Framework (SSDF) skill providing comprehensive guidance on secure software development practices, including the four SSDF practice groups (PO, PS, PW, RV), all 19 practices with tasks and implementation examples, supply chain security, EO 14028 software security requirements, and mapping to SP 800-53, NIST CSF, and ISO 27001.", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@github" + }, + "homepage": "https://csrc.nist.gov/publications/detail/sp/800-218/final", + "repository": "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "SSDF", + "secure-software-development", + "software-security", + "supply-chain-security", + "EO-14028", + "DevSecOps", + "SBOM", + "vulnerability-management" + ] +} diff --git a/plugins/nist-sp-800-218/skills/nist-sp-800-218/SKILL.md b/plugins/nist-sp-800-218/skills/nist-sp-800-218/SKILL.md new file mode 100644 index 0000000..d34cbc9 --- /dev/null +++ b/plugins/nist-sp-800-218/skills/nist-sp-800-218/SKILL.md @@ -0,0 +1,463 @@ +--- +name: nist-sp-800-218 +description: > + Apply this skill for any question about secure software development practices, + the NIST Secure Software Development Framework (SSDF), NIST SP 800-218, SSDF + practice groups PO PS PW RV, software security requirements, DevSecOps pipeline + security, secure coding standards, software vulnerability management, software + supply chain security, EO 14028 software security requirements, SBOM for software + producers, software composition analysis, dependency scanning, static analysis + SAST dynamic analysis DAST, threat modelling for software, secure design + principles, security testing of software, software security assessment, + penetration testing of applications, open source software security, software + integrity verification, code signing, reproducible builds, build pipeline + security, software attestation, software bill of materials, NIST mapping to + SP 800-53 secure development controls, ISO 27001 software development controls, + NIST CSF software security, OpenSSF Scorecard, CycloneDX SPDX for software + security, software vulnerability disclosure, coordinated vulnerability disclosure, + CVD programme, CVSS scoring for software, software patch management, software + security metrics, software security training for developers, security champions + programme, application security programme, OWASP integration with SSDF. +--- + +# NIST SP 800-218: Secure Software Development Framework (SSDF) + +**Publication:** NIST Special Publication 800-218, Version 1.1, February 2022 +**CSRC:** https://csrc.nist.gov/publications/detail/sp/800-218/final + +--- + +## Purpose and Scope + +NIST SP 800-218 defines the Secure Software Development Framework (SSDF): a set of fundamental, sound, and secure software development practices. The SSDF is not a development process or lifecycle model — it is a reference framework of practices that organisations should incorporate into their existing software development lifecycles (SDLCs) regardless of technology, platform, or programming language. + +Primary objectives: +- Reduce the number of vulnerabilities in released software +- Reduce the potential impact of undetected or unaddressed vulnerabilities +- Address the root causes of vulnerabilities to prevent future recurrences +- Establish repeatable, documented, and measurable secure development practices +- Support attestation and compliance with EO 14028 software security requirements + +The SSDF applies to all types of software: commercial off-the-shelf (COTS), open-source, custom-developed, and software as a service (SaaS). It applies to software producers and to organisations that define software security requirements for their suppliers. + +--- + +## SSDF Structure + +The SSDF is organised into four practice groups, 19 practices, and a set of tasks and implementation examples per practice. Each practice entry contains: + +- **Practice ID:** Group prefix + number (e.g., PO.1, PS.2) +- **Practice title:** Short label +- **Practice description:** What should be accomplished +- **Tasks:** Specific actions to implement the practice +- **Notional implementation examples:** Non-prescriptive examples of tools, techniques, and approaches + +### Practice Groups + +| Group | Name | Practice Count | +|-------|------|---------------| +| PO | Prepare the Organisation | 5 practices (PO.1–PO.5) | +| PS | Protect the Software | 3 practices (PS.1–PS.3) | +| PW | Produce Well-Secured Software | 8 practices (PW.1–PW.9, except PW.3 and PW.8) | +| RV | Respond to Vulnerabilities | 3 practices (RV.1–RV.3) | + +Note: PW.3 and PW.8 were removed in SSDF v1.1. Active PW practices are PW.1, PW.2, PW.4, PW.5, PW.6, PW.7, PW.9. + +--- + +## PO: Prepare the Organisation + +Establish and maintain the organisation-wide conditions needed to support secure software development throughout the software development lifecycle. + +### PO.1 — Define Security Requirements for Software Development + +**Description:** Ensure that security requirements are identified, prioritised, and integrated into the SDLC from the beginning. + +**Tasks:** +- PO.1.1: Identify and document security requirements at the organisational level (regulatory, contractual, policy) +- PO.1.2: Identify and document security and privacy requirements for each software project +- PO.1.3: Review and revise software requirements periodically and when significant changes occur + +**Key implementation examples:** +- Maintain a catalogue of applicable security requirements by software category (web, mobile, embedded, cloud) +- Use threat modelling to derive security requirements from system design (STRIDE, PASTA, attack trees) +- Map software security requirements to SP 800-53, OWASP ASVS, or CWE Top 25 as reference + +### PO.2 — Implement Roles and Responsibilities + +**Description:** Ensure that everyone participating in the SDLC has an appropriate level of security skills and knowledge for their role. + +**Tasks:** +- PO.2.1: Create new roles or add duties to existing roles as needed for security +- PO.2.2: Provide role-appropriate training and awareness to all personnel involved in software development +- PO.2.3: Conduct security awareness training for all individuals performing software development + +**Key implementation examples:** +- Define security responsibilities in job descriptions for developers, architects, DevOps engineers, and product owners +- Deliver role-specific training: secure coding for developers, threat modelling for architects, security testing for QA +- Establish a security champions programme to embed security expertise in development teams +- Track training completion and currency (annual refresh minimum) + +### PO.3 — Implement Supporting Toolchains + +**Description:** Use automation to reduce human error and increase repeatability of security activities throughout the SDLC. + +**Tasks:** +- PO.3.1: Specify which tools are required or recommended for each SDLC process stage +- PO.3.2: Integrate security-focused tooling into the SDLC toolchain (IDE plugins, CI/CD pipeline stages) +- PO.3.3: Configure and maintain tools to support security practices; retire or replace inadequate tools + +**Key implementation examples:** +- Pre-commit hooks: secret detection (detect-secrets, trufflehog), linting, SAST lite checks +- CI/CD pipeline security stages: SAST, SCA/dependency scanning, container image scanning, IaC scanning +- IDE security plugins: security linters, real-time vulnerability detection (Semgrep, Snyk, Checkmarx IDE) +- Artifact repository: enforce signed artifacts, vulnerability scanning of stored images + +### PO.4 — Define and Use Criteria for Software Security Checks + +**Description:** Define clear criteria for evaluating the security of software before it advances to the next SDLC phase and before release. + +**Tasks:** +- PO.4.1: Define criteria for security checks at SDLC phase gates and for release approval +- PO.4.2: Define severity thresholds for findings that block advancement (critical/high findings block release) +- PO.4.3: Evaluate software against defined criteria at appropriate phase-gate checkpoints + +**Key implementation examples:** +- Security requirement traceability matrix (SRTM) mapping requirements to test evidence +- Release criteria: zero unmitigated critical/high CVEs in direct dependencies, SAST findings below defined threshold, penetration test findings remediated or risk-accepted by authorised reviewer +- Phase-gate checklists for design, pre-code, pre-test, pre-release, and post-release phases + +### PO.5 — Implement and Maintain Secure Environments for Software Development + +**Description:** Ensure that development, build, and testing environments are protected to prevent tampering, contamination, or exfiltration of source code, build artifacts, and developer credentials. + +**Tasks:** +- PO.5.1: Separate development, staging, and production environments and control access to each +- PO.5.2: Secure the developer environment: endpoints, credentials, access to source code repositories +- PO.5.3: Secure the build environment: build systems, build pipelines, build toolchains, build credentials + +**Key implementation examples:** +- Dedicated build accounts with least privilege; build service accounts cannot modify production environments +- Source code repository access controls: branch protection rules, required reviews, signed commits +- Build system hardening: ephemeral build agents, no persistent secrets in build environment, artifact signing +- Separate testing environments using anonymised or synthetic data (no production data in test) +- Developer workstation management: EDR, full disk encryption, MFA for code repository access + +--- + +## PS: Protect the Software + +Protect all components of the software from tampering and unauthorised access throughout the SDLC. + +### PS.1 — Protect All Forms of Code from Unauthorised Access and Tampering + +**Description:** Protect code in all forms: source code, build scripts, infrastructure-as-code, configuration, and any other software components. + +**Tasks:** +- PS.1.1: Store all code in a version control system with access controls +- PS.1.2: Limit and monitor write access to source code repositories +- PS.1.3: Use code review (minimum two-person integrity) before merging to protected branches + +**Key implementation examples:** +- Branch protection: require pull request reviews, status checks passing, signed commits +- CODEOWNERS files to enforce security-team review of security-sensitive modules +- Audit logging of all code repository access, clone operations, and administrative changes +- Repository scanning for secrets and credentials committed to version control history + +### PS.2 — Provide a Mechanism for Verifying the Integrity of the Software Release + +**Description:** Provide a way for software consumers to verify the integrity and authenticity of released software. + +**Tasks:** +- PS.2.1: Digitally sign software release artifacts using a controlled signing key +- PS.2.2: Provide cryptographic hash values (SHA-256 minimum) alongside release artifacts +- PS.2.3: Maintain the signing key infrastructure securely; use HSM or key management service + +**Key implementation examples:** +- Code signing: Authenticode (Windows), Apple notarisation (macOS), GPG signatures (Linux packages, container images) +- Container image signing: Sigstore/cosign, Docker Content Trust, Notary +- Provide SPDX or CycloneDX SBOM signed alongside release artifact +- Publish signing key fingerprints and verification instructions in software documentation +- Implement SLSA (Supply chain Levels for Software Artifacts) framework to document build provenance + +### PS.3 — Archive and Protect Each Software Release + +**Description:** Preserve all evidence that is needed to confirm the integrity of each software release for as long as that software is supported. + +**Tasks:** +- PS.3.1: Store archives of all released software versions with evidence of integrity (hash, signature) +- PS.3.2: Retain build records, dependencies snapshot, SBOM, and test results for each release +- PS.3.3: Control and audit access to the release archive + +**Key implementation examples:** +- Immutable artifact storage: write-once object storage for release artifacts +- Retain per-release: source code snapshot, compiled artifacts, dependencies lock file, SBOM, SAST/DAST results, penetration test report, release approval record, signing certificate chain +- Archive retention period aligned with software supported lifetime plus regulatory requirements + +--- + +## PW: Produce Well-Secured Software + +Produce well-secured software with minimal security vulnerabilities in its releases. + +### PW.1 — Design Software to Meet Security Requirements and Mitigate Security Risks + +**Description:** Design software to meet security requirements and to reduce security vulnerabilities before coding begins. + +**Tasks:** +- PW.1.1: Define and document threat model for each software component; update on significant design changes +- PW.1.2: Design software to implement security controls that address identified threats and satisfy security requirements +- PW.1.3: Review and evaluate software designs to validate security properties before coding begins + +**Key implementation examples:** +- Threat modelling methodologies: STRIDE (Microsoft), PASTA, LINDDUN (privacy), attack trees +- Threat modelling output: data flow diagram, trust boundary identification, threat enumeration, mitigation decisions (DREAD ratings or CVSS pre-exploitation scores) +- Secure design principles: least privilege, defence in depth, fail securely, minimise attack surface, separation of duties, do not trust input, secure defaults +- Design review checklist aligned to OWASP ASVS architecture requirements + +### PW.2 — Review the Software Design to Verify Compliance with Security Requirements + +**Description:** Have a qualified reviewer independently verify that the software design satisfies security requirements and adequately addresses identified threats. + +**Tasks:** +- PW.2.1: Have individuals with sufficient security expertise conduct software design review +- PW.2.2: Document design review findings and confirm disposition of all security-relevant findings + +**Key implementation examples:** +- Architecture review board (ARB) or security architecture review gate for new systems and significant changes +- Design review checklist mapped to security requirements and threat model threats +- Track open design-level risks in the project risk register + +### PW.4 — Reuse Existing, Well-Secured Software When Feasible + +**Description:** Use existing software that is well-secured, actively maintained, and appropriate for the intended use to reduce the risk of introducing new vulnerabilities through reuse. + +**Tasks:** +- PW.4.1: Identify and evaluate applicable well-secured software components for reuse +- PW.4.2: Determine and document security risks from reusing a component; accept or mitigate before use +- PW.4.3: Maintain a list of approved third-party software components and versions in use + +**Key implementation examples:** +- Approved component catalogue with security evaluation status and approved version ranges +- Software Composition Analysis (SCA): automated scanning of direct and transitive dependencies against CVE database (OWASP Dependency-Check, Snyk, Black Duck, FOSSA) +- Pin dependency versions; use lock files (package-lock.json, Pipfile.lock, go.sum) +- Evaluate component health: maintenance status, disclosed vulnerability history, community response time +- Prohibition on end-of-life (EOL) components in production software without an approved exception + +### PW.5 — Create Source Code by Adhering to Secure Coding Practices + +**Description:** Reduce the number of security vulnerabilities by following well-established conventions for secure coding. + +**Tasks:** +- PW.5.1: Follow secure coding standards appropriate to the programming language and platform +- PW.5.2: Use security-focused static analysis tools on source code throughout development +- PW.5.3: Train developers on secure coding practices relevant to their language and domain + +**Key implementation examples:** +- Secure coding standards by language: CERT C/C++, OWASP Java Secure Coding, Apple iOS security guidelines, Android security best practices +- Common vulnerability prevention: input validation (allowlist), output encoding, prepared statements for SQL, context-appropriate escaping for XSS prevention, safe API usage for memory-safe operations +- SAST tools: SonarQube, Semgrep, Checkmarx, Coverity, CodeQL; configure to enforce security rulesets +- SAST finding triage: security engineers review false positives; track true positives as defects +- CWE Top 25 Most Dangerous Software Weaknesses as a training reference + +### PW.6 — Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security + +**Description:** Improve the security of the software's build output by using available security features in the build toolchain. + +**Tasks:** +- PW.6.1: Use compiler and linker options that improve the security of the executable (where applicable) +- PW.6.2: Determine the security-relevant configuration for runtime interpreters and execution environments + +**Key implementation examples:** +- C/C++ compiler hardening flags: -fstack-protector-all, -D_FORTIFY_SOURCE=2, -pie -fPIE, -Wl,-z,relro,-z,now, -O2 +- Enable Address Space Layout Randomisation (ASLR) at OS level; use PIE executables +- Enable Control Flow Integrity (CFI) where compiler support is available +- Java/JVM: enable SecurityManager (deprecated Java 17+), address deserialization risks +- Python: disable -O optimisations that strip assert statements in security-relevant code +- Container images: run as non-root user, use read-only root filesystem, drop all capabilities + +### PW.7 — Review and/or Analyse Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements + +**Description:** Identify vulnerabilities in the code through manual review, automated analysis, or a combination, and ensure that security requirements are implemented. + +**Tasks:** +- PW.7.1: Perform code reviews on security-sensitive code areas; use peer review for all production code +- PW.7.2: Use automated SAST tools to supplement manual review +- PW.7.3: Track and remediate all code review findings according to severity and release criteria + +**Key implementation examples:** +- Mandatory security-focused code review for: authentication/authorisation code, cryptography usage, session management, input handling, direct memory manipulation, privilege elevation, network communication +- SAST finding severity mapping to defect priority: critical → P0 (block release), high → P1 (fix in current sprint), medium → P2 (fix in next sprint), low → P3 (backlog) +- Automated code review tooling integrated into pull request workflow with required status checks + +### PW.9 — Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements + +**Description:** Test the compiled or interpreted code to identify vulnerabilities and verify that security controls are implemented correctly. + +**Tasks:** +- PW.9.1: Use DAST tools against running software in a test environment +- PW.9.2: Perform penetration testing on software prior to first production deployment and after major changes +- PW.9.3: Review test results and remediate confirmed vulnerabilities per release criteria + +**Key implementation examples:** +- DAST tools: OWASP ZAP (automated scan), Burp Suite Professional (manual-assisted), Nikto (web server configuration) +- DAST integration into CI/CD: baseline scan on every build; full active scan on release candidate +- Penetration testing: internal team or third-party; scope to define in-scope assets and test boundaries; methodology aligned to PTES, OWASP Testing Guide, or NIST SP 800-115 +- Fuzz testing: use fuzzing frameworks (libFuzzer, AFL, boofuzz) for parsers, protocol handlers, and API endpoints +- Security regression testing: maintain a suite of tests derived from previously discovered vulnerabilities + +--- + +## RV: Respond to Vulnerabilities + +Identify residual vulnerabilities in software releases and respond appropriately to address them. + +### RV.1 — Identify and Confirm Vulnerabilities on an Ongoing Basis + +**Description:** Establish a process to identify vulnerabilities in released software from both internal and external sources on a continuous basis. + +**Tasks:** +- RV.1.1: Gather information about potential vulnerabilities in the software from internal and external sources +- RV.1.2: Review and confirm each reported potential vulnerability; assign a severity rating using CVSS +- RV.1.3: Analyse confirmed vulnerabilities to determine root cause to enable broader remediation + +**Key implementation examples:** +- Internal sources: SAST/DAST results from production monitoring, runtime application self-protection (RASP), log analysis +- External sources: NVD/CVE database subscription, vendor security advisories, bug bounty programme submissions, responsible disclosure submissions, security researcher reports +- Vulnerability tracking: maintain a vulnerability management register with CVE/CWE ID, CVSS score, affected versions, status, and target remediation date +- SCA tools in production monitoring mode: alert when new CVEs published for components in use + +### RV.2 — Assess, Prioritise, and Remediate Vulnerabilities + +**Description:** Assess the severity of confirmed vulnerabilities, prioritise remediation based on risk, and remediate on a defined schedule. + +**Tasks:** +- RV.2.1: Evaluate the severity of each confirmed vulnerability using a documented assessment process (CVSS, environmental scoring) +- RV.2.2: Prioritise vulnerabilities for remediation based on severity, exploitability, and business impact +- RV.2.3: Remediate vulnerabilities according to defined timelines; track exceptions with compensating controls + +**Key implementation examples:** +- CVSS v3.1 environmental metrics: use asset criticality and compensating controls to adjust base scores +- Remediation SLA: Critical CVSS 9.0–10.0 → 15 days; High 7.0–8.9 → 30 days; Medium 4.0–6.9 → 90 days; Low 0.1–3.9 → 180 days or next planned release +- Patch delivery options: hotfix release, regular patch release, compensating control (WAF rule, network restriction), risk acceptance with ISSO/authorising official approval +- Coordinated Vulnerability Disclosure (CVD): define process for handling external researcher submissions (acknowledge within 5 business days, provide remediation timeline) +- EOL component replacement: trigger replacement project when a dependency reaches EOL or CVSS ≥ 7.0 with no patch available + +### RV.3 — Analyse Vulnerabilities to Identify Their Root Causes + +**Description:** Identify and address the root causes of vulnerabilities to prevent recurrence of similar vulnerabilities in both current and future software. + +**Tasks:** +- RV.3.1: Analyse each confirmed vulnerability to identify its root cause (e.g., specific CWE, design flaw, missing control) +- RV.3.2: Use root cause data to update secure coding standards, training materials, and SDLC processes +- RV.3.3: Report vulnerability trends to management to drive investment in preventive measures + +**Key implementation examples:** +- Root cause taxonomy: classify by CWE, SDLC phase where introduced (design/coding/configuration), and type of failure (knowledge gap, process failure, tooling gap) +- Retrospective review: for critical/high vulnerabilities, conduct a brief RCA meeting before closing the ticket +- Trend reporting: quarterly vulnerability trend report to engineering leadership covering: new vulnerabilities by severity, mean time to remediate (MTTR) by severity, top CWE categories, improvements over prior period +- Update training curriculum based on recurring CWE findings + +--- + +## EO 14028 Software Security Requirements (May 2021) + +Executive Order 14028 "Improving the Nation's Cybersecurity" established federal software security requirements that map directly to the SSDF. Key requirements for software producers selling to the federal government: + +| EO 14028 Requirement | SSDF Mapping | +|---------------------|-------------| +| Use multi-factor authentication | PO.5.2 (developer environment security) | +| Maintain trusted source code supply chains | PS.1, PW.4 (code protection, component reuse) | +| Use automated tools to check for vulnerabilities | PW.5, PW.7, PW.9 (SAST/DAST/SCA) | +| Have documentation of code provenance | PS.1, PS.2 (code integrity, signing, SBOM) | +| Provide SBOM for software supplied to federal government | PS.2, PS.3 | +| Test for known or potential vulnerabilities in software | PW.7, PW.9, RV.1 | +| Maintain access control over proprietary code | PS.1, PO.5 | +| Provide vulnerability disclosure policy | RV.1, RV.2 | +| Attest to compliance with SSDF practices | All practice groups | + +The Office of Management and Budget (OMB) memoranda M-22-18 and M-23-16 operationalise the EO 14028 software supply chain security requirements, requiring federal agencies to collect software attestation and SBOMs from software producers. + +--- + +## SBOM Requirements (SP 800-218 + EO 14028) + +A Software Bill of Materials (SBOM) is a machine-readable inventory of software components and dependencies. + +### NTIA Minimum Elements (7 fields per component): + +| Field | Description | +|-------|-------------| +| Supplier name | Name of entity supplying the component | +| Component name | Name used to refer to the component | +| Component version | Version identifier used by supplier | +| Other unique identifiers | PURL, CPE, or supplier-specific identifier | +| Dependency relationship | Direct or transitive relationship to parent | +| Author of SBOM data | Entity generating the SBOM | +| Timestamp | Date and time SBOM was generated | + +### SBOM Formats: + +| Format | Governing Body | Use Case | +|--------|---------------|----------| +| SPDX (Software Package Data Exchange) | Linux Foundation / ISO 5962 | Open source licence compliance + security | +| CycloneDX | OWASP | Software security and risk management focus | +| SWID Tags | ISO/IEC 19770-2 | Endpoint asset management focus | + +### SBOM Delivery Requirements: +- Delivered with each software release +- Machine-readable format (SPDX JSON, CycloneDX XML/JSON) +- Human-readable version provided in addition where required by contract +- Signed by software producer (integrity verification, PS.2) +- Updated when any component is added, updated, or removed + +--- + +## SP 800-53 Rev 5 Control Mapping + +| SSDF Practice | SP 800-53 Controls | +|--------------|-------------------| +| PO.1 (Security Requirements) | SA-8, SA-15, SA-17, PL-8 | +| PO.2 (Roles/Responsibilities) | AT-2, AT-3, PS-7, SA-3 | +| PO.3 (Toolchains) | SA-15, SA-11, CM-2, CM-3 | +| PO.4 (Security Check Criteria) | SA-11, SA-15, CA-2, CA-8 | +| PO.5 (Secure Environments) | CM-6, SC-28, AC-3, IA-5, SI-7 | +| PS.1 (Protect Code) | CM-3, SA-10, AC-3, AU-2 | +| PS.2 (Integrity Verification) | SA-10, SI-7, CM-14 | +| PS.3 (Archive Releases) | CP-9, CM-3, SA-10 | +| PW.1 (Secure Design) | SA-8, SA-17, RA-3, PL-8 | +| PW.2 (Design Review) | SA-11, CA-2, SA-4 | +| PW.4 (Reuse Components) | SA-4, SA-9, SA-12, CM-14 | +| PW.5 (Secure Coding) | SA-11, SA-15, CM-3 | +| PW.6 (Build Hardening) | CM-6, SA-15, SI-3 | +| PW.7 (Code Review) | SA-11, SA-15, CA-7 | +| PW.9 (Security Testing) | SA-11, CA-8, RA-5 | +| RV.1 (Identify Vulnerabilities) | RA-5, SI-5, CA-7 | +| RV.2 (Remediate Vulnerabilities) | RA-5, SI-2, CA-7 | +| RV.3 (Root Cause Analysis) | CA-2, IR-4, PM-4 | + +--- + +## NIST CSF Mapping + +| SSDF Practice Group | CSF Functions | CSF Categories | +|--------------------|--------------|----------------| +| PO (Prepare) | Govern, Identify | GV.OC, GV.RM, ID.AM, ID.RA | +| PS (Protect Software) | Protect | PR.DS, PR.IP, PR.AT | +| PW (Produce Well-Secured) | Identify, Protect | ID.RA, PR.IP, PR.DS | +| RV (Respond to Vulnerabilities) | Detect, Respond, Recover | DE.CM, RS.AN, RS.MI, RC.IM | + +--- + +## Roles and Responsibilities + +| Role | SSDF Responsibilities | +|------|-----------------------| +| Software Developer | Implement PW.5 (secure coding), PW.6 (build hardening), PW.7 (code review); complete security training (PO.2) | +| Security Architect | Lead PW.1 (secure design), PW.2 (design review), PO.1 (security requirements) | +| DevSecOps Engineer | Implement PO.3 (toolchains), PO.5 (secure environments), PW.6, PW.9 (DAST in CI/CD) | +| QA/Test Engineer | Execute PW.9 (security testing), maintain security regression tests | +| Security Engineer | Perform PW.7 (security code review), triage SAST/DAST findings, support PO.4 (release criteria) | +| Product Owner | Prioritise security requirements (PO.1), approve risk acceptance decisions (RV.2) | +| CISO/Security Lead | Define organisational security requirements (PO.1), approve SSDF programme (PO.2), review RV.3 trend reports | +| Software Procurement | Evaluate third-party components (PW.4), collect supplier attestations and SBOMs (PS.2, PS.3) | diff --git a/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/implementation-guidance.md b/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/implementation-guidance.md new file mode 100644 index 0000000..52a0957 --- /dev/null +++ b/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/implementation-guidance.md @@ -0,0 +1,342 @@ +# SSDF Implementation Guidance — Programme Establishment and Maturity + +**Source:** NIST SP 800-218 v1.1; NIST IR 8397 (Guidelines on Minimum Standards for Developer Verification); NIST SP 800-218A (AI/ML application supplement, draft); OMB M-22-18; OMB M-23-16 + +This reference provides practical guidance for organisations implementing the SSDF: how to assess current-state maturity, prioritise implementation, build an SSDF programme, and demonstrate compliance through attestation and measurable outcomes. + +--- + +## SSDF Implementation Approach + +The SSDF is not prescriptive about implementation order or required tools. It defines outcomes (practices and tasks) rather than mechanisms. Organisations should: + +1. Assess current-state: identify which practices are already implemented, partially implemented, or absent +2. Prioritise gaps: based on risk, regulatory requirements, and resources available +3. Integrate into existing processes: the SSDF supplements existing SDLC methodologies (Agile, DevOps, waterfall); it does not replace them +4. Iterate: implement the highest-priority practices first; expand coverage over time +5. Document and measure: maintain evidence of practice implementation + +--- + +## SSDF Maturity Assessment + +### Current-State Assessment Template + +For each practice, assess the current state using this scale: + +| Maturity Level | Description | +|---------------|-------------| +| 0 — Not Implemented | Practice is not performed; no documentation or tooling | +| 1 — Initial | Practice is performed ad-hoc or informally; results are not consistent | +| 2 — Documented | Practice is defined; documentation exists; performed consistently in most projects | +| 3 — Managed | Practice is performed consistently; metrics collected; management reviews results | +| 4 — Optimised | Practice is continuously improved based on metrics and feedback | + +### Practice Maturity Assessment Grid + +| Practice | Current Level | Target Level | Gap | Priority | Owner | +|---------|--------------|-------------|-----|----------|-------| +| PO.1 Security Requirements | — | — | — | — | — | +| PO.2 Roles/Responsibilities | — | — | — | — | — | +| PO.3 Toolchains | — | — | — | — | — | +| PO.4 Security Check Criteria | — | — | — | — | — | +| PO.5 Secure Environments | — | — | — | — | — | +| PS.1 Protect Code | — | — | — | — | — | +| PS.2 Integrity Verification | — | — | — | — | — | +| PS.3 Archive Releases | — | — | — | — | — | +| PW.1 Secure Design | — | — | — | — | — | +| PW.2 Design Review | — | — | — | — | — | +| PW.4 Reuse Components | — | — | — | — | — | +| PW.5 Secure Coding | — | — | — | — | — | +| PW.6 Build Hardening | — | — | — | — | — | +| PW.7 Code Review | — | — | — | — | — | +| PW.9 Security Testing | — | — | — | — | — | +| RV.1 Identify Vulnerabilities | — | — | — | — | — | +| RV.2 Remediate Vulnerabilities | — | — | — | — | — | +| RV.3 Root Cause Analysis | — | — | — | — | — | + +--- + +## SSDF Implementation Roadmap + +### Phase 1 — Foundation (Months 1–3) + +**Focus:** Essential controls that have broad risk reduction impact and low implementation complexity. + +| Practice | Milestone | Activities | +|---------|-----------|-----------| +| PO.2 | Security training programme initiated | Define training curriculum per role; assign to all developers; track completion | +| PO.5 | Secure environment baseline | Enable MFA for all developer accounts and code repositories; enable branch protection on protected branches; enforce required reviewers | +| PS.1 | Code protection baseline | Enable audit logging on code repositories; configure CODEOWNERS; enforce signed commits | +| PW.5 | SAST integrated | Deploy SAST tool (e.g., Semgrep) to CI pipeline; configure security rulesets; establish finding review process | +| PW.4 | SCA integrated | Deploy SCA tool (e.g., OWASP Dependency-Check) to CI pipeline; configure CVE threshold; alert on new highs | +| RV.1 | Vulnerability intake | Establish security@org monitoring; define internal CVE monitoring frequency; subscribe to CISA KEV feed | +| RV.2 | Remediation SLA defined | Publish and communicate vulnerability remediation SLA by severity | + +**Phase 1 success criteria:** +- 100% of production code repositories have branch protection enabled +- 100% of developers with repository write access have MFA enabled +- SAST and SCA running on every PR for all active development repositories +- Security training completion > 80% +- Documented vulnerability remediation SLA published + +--- + +### Phase 2 — Depth (Months 3–9) + +**Focus:** Processes and controls that require more organisational change and tool maturity. + +| Practice | Milestone | Activities | +|---------|-----------|-----------| +| PO.1 | Security requirements process | Application risk classification in use; ASVS or equivalent requirements applied by risk tier; requirements in project backlogs | +| PO.3 | Toolchain formalised | Approved toolchain list published; all SDLC phases covered; tools integrated into pipeline | +| PO.4 | Phase-gate criteria | Phase-gate security checklists defined and in use; release criteria documented; exceptions process in place | +| PW.1 | Threat modelling adopted | Threat modelling process defined; architects and senior developers trained; threat model required for new systems and major changes | +| PW.5 | Secrets scanning | Pre-commit secrets detection deployed; CI pipeline secrets scan; existing repository history scanned | +| PS.2 | Artifact signing | Code signing process established for release artifacts; SHA-256 checksums published with all releases | +| RV.1 | VDP published | Vulnerability disclosure policy published; responsible disclosure process operational; security contact monitored | +| RV.3 | Root cause analysis | RCA process defined for critical/high vulnerabilities; RCA outcomes fed back into training updates | + +**Phase 2 success criteria:** +- Threat models exist for all tier-1 and tier-2 applications +- Release artifacts are signed for all production releases +- Vulnerability disclosure policy publicly accessible +- Phase-gate checklists in use for at least 75% of active development projects +- SAST true-positive finding density decreasing from phase 1 baseline + +--- + +### Phase 3 — Optimise (Months 9–18) + +**Focus:** Advanced controls, supply chain security hardening, and programme maturity. + +| Practice | Milestone | Activities | +|---------|-----------|-----------| +| PO.3 | DAST integrated | DAST (OWASP ZAP) running in CI against test environments; API security scanning implemented | +| PW.9 | Penetration testing programme | Annual penetration test cadence established; scope defined; findings tracked to closure | +| PW.6 | Build hardening | Compiler hardening flags enabled for compiled languages; container images run non-root; IaC scanning in CI | +| PS.2 | SBOM programme | SBOM generated for all releases; SBOM published to consumers or stored in artifact archive; SBOM signed | +| PS.3 | Release archive | Per-release security package archived with all required artifacts (SBOM, scan results, approval records) | +| PW.4 | Component governance | Approved component catalogue in use; EOL component tracking; automated dependency updates (Dependabot/Renovate) | +| PO.5 | Build environment hardening | Ephemeral build agents; OIDC-based pipeline authentication; no static secrets in CI/CD | +| RV.3 | Trend reporting | Quarterly vulnerability trend reports to management; training updated based on recurring CWEs | + +**Phase 3 success criteria:** +- DAST running on all web-facing applications prior to production release +- SBOM generated and archived for 100% of production releases +- Ephemeral build agents in use; no static long-lived credentials in CI/CD pipelines +- Penetration testing completed for all tier-1 applications within the past 12 months +- Approved component catalogue covering all production software + +--- + +## Application Risk Classification + +Risk classification determines which SSDF practices apply at what rigour level. Classify applications at project inception. + +### Classification Tiers + +| Tier | Characteristics | SSDF Rigour | +|------|----------------|------------| +| Tier 1 — Critical | Processes highly sensitive data (PII, payment, health, government classified); internet-facing; failure causes significant harm; regulated | All SSDF practices at full rigour; penetration test annually (minimum); SBOM required; third-party security review for major releases | +| Tier 2 — High | Processes sensitive data; internal-facing; failure causes significant operational disruption | All SSDF practices; penetration test every 2 years; SBOM required | +| Tier 3 — Medium | Processes internal non-sensitive data; limited external access | Core SSDF practices (PO.1–PO.4, PS.1–PS.2, PW.5, PW.7, PW.9, RV.1–RV.2); DAST scan before major releases | +| Tier 4 — Low | Internal tools; no sensitive data; limited user base | Minimum practices (PS.1, PW.5, RV.1–RV.2); SAST in CI; SCA in CI | + +### Risk Classification Criteria + +Score each characteristic (0–2) to determine tier: + +| Characteristic | 0 | 1 | 2 | +|---------------|---|---|---| +| Data sensitivity | Public data only | Internal / limited PII | PII, payment, health, credentials, classified | +| Internet exposure | No internet access | Indirect (behind gateway) | Direct internet access | +| User base | < 50 internal users | > 50 internal or any external (non-privileged) | General public or high-privilege external | +| Business criticality | Low operational impact | Moderate operational impact | Critical business process or regulatory requirement | +| Regulatory scope | No regulatory requirement | Soft regulatory guidance | Hard regulatory requirement (HIPAA, PCI DSS, FISMA, GDPR) | + +Total score: 0–3 = Tier 4; 4–5 = Tier 3; 6–7 = Tier 2; 8–10 = Tier 1 + +--- + +## SSDF Compliance Evidence Requirements + +### Evidence Types by Practice + +| Practice | Required Evidence | +|---------|-----------------| +| PO.1 | Security requirements specification document; requirements traceability matrix | +| PO.2 | Role description with security responsibilities; training completion records; training curriculum | +| PO.3 | Approved toolchain list; CI/CD pipeline configuration; tool scan reports | +| PO.4 | Phase-gate checklist templates; filled checklists for representative releases; exception log | +| PO.5 | Environment architecture diagram showing separation; MFA enforcement policy; build config showing ephemeral agents | +| PS.1 | Repository RBAC configuration; audit log samples; CODEOWNERS file; branch protection settings | +| PS.2 | Signing certificate or key details; signed artifact with verification instructions; hash files | +| PS.3 | Release archive inventory; access control configuration; retention schedule | +| PW.1 | Threat model documents (per application); threat modelling process documentation | +| PW.2 | Design review records; design review checklist; reviewer qualifications | +| PW.4 | Approved component catalogue; SCA scan reports; EOL tracking records | +| PW.5 | Secure coding standards; SAST scan reports; training completion records | +| PW.6 | Build script showing compiler flags; container image configuration; IaC scan results | +| PW.7 | Pull request reviews (sample); SAST scan findings and dispositions | +| PW.9 | DAST scan reports; penetration test report; security test results | +| RV.1 | CVE monitoring alerts; vulnerability disclosure policy; VDP submission log | +| RV.2 | Vulnerability management register; remediation records showing dates; exception log | +| RV.3 | RCA records for critical/high findings; training updates triggered by RCA; trend reports | + +### attestation Package for Federal Software Producers + +For software supplied to US federal agencies under EO 14028 / OMB M-22-18: + +**Required attestation documents:** + +1. Software Attestation Form (using CISA template): signed by an authorised individual (typically CISO or VP Engineering) +2. SBOM in SPDX or CycloneDX format for each software release +3. Supporting artefacts (on request from agency): scan reports, test results, architecture documentation + +**Attestation form key declarations:** + +``` +I, [Authorised Individual], [Title], [Company], hereby attest that: + +1. [Company] maintains and follows a secure software development lifecycle + that incorporates SSDF practices as described in NIST SP 800-218. + +2. [Company] employs automated security testing, including: + - Static analysis (SAST) integrated into the development process + - Software composition analysis (SCA) for third-party component vulnerabilities + - Dynamic analysis (DAST) for web-accessible components + +3. [Software Name, Version] has been reviewed for security vulnerabilities + and all critical and high-severity vulnerabilities have been remediated + or risk-accepted with documented compensating controls. + +4. A Software Bill of Materials (SBOM) for [Software Name, Version] is + available and provided herewith. + +5. [Company] maintains a vulnerability disclosure policy and will notify + the agency within [timeframe] of discovery of any vulnerability that + could affect the agency's use of the software. + +Signature: _____________ Date: ____________ +``` + +--- + +## SSDF Framework Cross-Mapping + +### SSDF to ISO/IEC 27001:2022 Mapping + +| SSDF Practice | ISO 27001:2022 Controls | +|--------------|------------------------| +| PO.1 (Security Requirements) | 8.26 (Application security requirements), 5.8 (Information security in project management) | +| PO.2 (Roles/Responsibilities) | 6.3 (Information security awareness, education and training), 5.2 (Information security roles and responsibilities) | +| PO.3 (Toolchains) | 8.28 (Secure coding), 8.26 (Application security requirements) | +| PO.4 (Security Check Criteria) | 8.29 (Security testing in development and acceptance) | +| PO.5 (Secure Environments) | 8.31 (Separation of development, test and production environments), 8.4 (Access to source code) | +| PS.1 (Protect Code) | 8.4 (Access to source code), 5.15 (Access control) | +| PS.2 (Integrity Verification) | 8.16 (Monitoring activities), 8.20 (Networks security), 5.30 (ICT readiness for business continuity) | +| PS.3 (Archive Releases) | 8.12 (Data masking), 5.33 (Protection of records) | +| PW.1 (Secure Design) | 8.25 (Secure development life cycle), 8.27 (Secure system architecture and engineering principles) | +| PW.4 (Reuse Components) | 8.30 (Outsourced development), 5.19 (Information security in supplier relationships) | +| PW.5 (Secure Coding) | 8.28 (Secure coding) | +| PW.6 (Build Hardening) | 8.28 (Secure coding), 8.9 (Configuration management) | +| PW.7 (Code Review) | 8.28 (Secure coding), 8.29 (Security testing in development and acceptance) | +| PW.9 (Security Testing) | 8.29 (Security testing in development and acceptance), 8.8 (Management of technical vulnerabilities) | +| RV.1 (Identify Vulnerabilities) | 8.8 (Management of technical vulnerabilities), 5.7 (Threat intelligence) | +| RV.2 (Remediate Vulnerabilities) | 8.8 (Management of technical vulnerabilities) | +| RV.3 (Root Cause Analysis) | 5.27 (Learning from information security incidents), 5.28 (Collection of evidence) | + +--- + +### SSDF to NIST SP 800-53 Rev 5 Control Families + +| SSDF Practice Group | Primary SP 800-53 Control Families | +|--------------------|-----------------------------------| +| PO — Prepare the Organisation | SA (System and Services Acquisition), AT (Awareness and Training), PL (Planning), PM (Program Management) | +| PS — Protect the Software | SA (SA-10 Developer Configuration Management), CM (Configuration Management), SI (System and Information Integrity) | +| PW — Produce Well-Secured Software | SA (SA-11, SA-15, SA-17), RA (Risk Assessment), CM, SI | +| RV — Respond to Vulnerabilities | RA-5 (Vulnerability Monitoring and Scanning), SI-2 (Flaw Remediation), CA-7 (Continuous Monitoring), IR (Incident Response) | + +--- + +### SSDF to NIST CSF 2.0 Function Mapping + +| SSDF Practice Group | CSF 2.0 Function | CSF Categories | +|--------------------|-----------------|----------------| +| PO — Prepare the Organisation | Govern (GV) | GV.OC (Organisational Context), GV.RM (Risk Management Strategy), GV.RR (Roles, Responsibilities, Authorities) | +| PO — Prepare the Organisation | Identify (ID) | ID.AM (Asset Management), ID.RA (Risk Assessment) | +| PS — Protect the Software | Protect (PR) | PR.DS (Data Security), PR.IP (Information Protection Processes) | +| PW — Produce Well-Secured Software | Identify (ID) | ID.RA (Risk Assessment) | +| PW — Produce Well-Secured Software | Protect (PR) | PR.IP (Information Protection Processes and Procedures) | +| RV — Respond to Vulnerabilities | Detect (DE) | DE.CM (Continuous Monitoring) | +| RV — Respond to Vulnerabilities | Respond (RS) | RS.AN (Incident Analysis), RS.MI (Incident Mitigation) | +| RV — Respond to Vulnerabilities | Recover (RC) | RC.IM (Incident Recovery Plan Execution and Communication) | + +--- + +## SSDF for AI/ML Software (NIST SP 800-218A Alignment) + +NIST SP 800-218A (draft supplement) extends the SSDF for AI and machine learning software. Key additional considerations: + +### Additional Considerations by Practice Group + +**PO (Prepare):** +- PO.1: Security requirements must include AI-specific risks: data poisoning, model evasion, model inversion, membership inference, model theft +- PO.2: Additional roles required: ML engineer (training pipeline security), data scientist (training data integrity), AI red team +- PO.3: AI/ML toolchain additions: model versioning (MLflow, DVC), training pipeline security scanning, data pipeline integrity checks + +**PS (Protect):** +- PS.1: Protect training data, model weights, and fine-tuning datasets in addition to source code +- PS.2: Sign and version model artifacts (model cards, weights checksum); register models in a model registry with access controls +- PS.3: Archive training dataset provenance (lineage), model training configurations, and evaluation results per model version + +**PW (Produce):** +- PW.1: Threat model must address ML-specific threats: adversarial examples (evasion), backdoor attacks (poisoning during training), model extraction +- PW.4: Evaluate pre-trained model trustworthiness: source, training data, known vulnerabilities (Hugging Face security advisories, CVEs in model infrastructure) +- PW.5: Data pipeline validation: schema enforcement, anomaly detection in training data, outlier rejection; input preprocessing validation at inference time + +**RV (Respond):** +- RV.1: Monitor for ML-specific vulnerabilities: new attacks on model architecture type, exploits in inference framework (TensorFlow, PyTorch, ONNX Runtime) +- RV.2: Model update/rollback process equivalent to software patching; degraded model performance may indicate adversarial attack — include in incident criteria +- RV.3: Root cause analysis for AI incidents must distinguish: training data issue, model architecture issue, deployment configuration issue, adversarial attack + +--- + +## Vendor / Third-Party SSDF Requirements + +When an organisation procures software rather than developing it internally, SSDF practices apply to how the organisation defines and enforces software security requirements on suppliers. + +### Procurement Checklist + +| Item | SSDF Practice | Verification Method | +|------|--------------|---------------------| +| Does the supplier have a documented secure SDLC? | PO.1, PO.2 | Request SSDF attestation or equivalent policy documentation | +| Does the supplier perform SAST and SCA? | PW.5, PW.7, PW.4 | Request sample scan reports; verify tooling in attestation | +| Does the supplier perform penetration testing? | PW.9 | Request most recent penetration test executive summary or letter of attestation | +| Does the supplier publish SBOMs? | PS.2, PS.3 | Request SBOM for proposed software version; verify SPDX/CycloneDX format | +| Does the supplier sign release artifacts? | PS.2 | Verify artifact signatures; inspect signing certificate validity | +| Does the supplier have a vulnerability disclosure policy? | RV.1 | Review published VDP; verify security contact responsiveness | +| What is the supplier's vulnerability remediation SLA? | RV.2 | Contractually require: Critical <= 15 days, High <= 30 days | +| Does the supplier notify on significant vulnerabilities? | RV.2 | Require contractual notification obligation for Critical/High CVEs affecting supplied software | +| How does the supplier handle EOL components in the software? | PW.4 | Require SBOM review; require EOL component replacement obligations in contract | + +### Contractual SSDF Requirements Clauses + +**Clause 1 — Secure Development Attestation:** +Supplier shall, at execution and annually thereafter, provide a software security attestation confirming that the supplied software is developed in accordance with NIST SP 800-218 SSDF practices or equivalent. Supplier shall make supporting evidence available to Customer upon request with reasonable notice. + +**Clause 2 — SBOM Delivery:** +Supplier shall deliver a machine-readable Software Bill of Materials (SBOM) in SPDX or CycloneDX format with each software release. The SBOM shall be signed by the Supplier and shall comply with NTIA minimum element requirements. + +**Clause 3 — Vulnerability Notification:** +Supplier shall notify Customer within 5 business days of confirming a vulnerability with a CVSS base score >= 7.0 in any software component delivered under this agreement. Notification shall include CVSS score, CVE identifier (if available), affected versions, and Supplier's remediation plan and timeline. + +**Clause 4 — Vulnerability Remediation SLA:** +Supplier shall release a patch or provide a verified compensating control for Critical vulnerabilities (CVSS >= 9.0) within 15 calendar days, High vulnerabilities (CVSS 7.0–8.9) within 30 calendar days, and Medium vulnerabilities (CVSS 4.0–6.9) within 90 calendar days of confirming the vulnerability. + +**Clause 5 — EOL Component Restriction:** +Supplier shall not deliver software that incorporates components that have reached end-of-life without Customer's prior written approval. In the event a component reaches EOL during the contract term, Supplier shall notify Customer and provide a remediation plan within 30 days. + +**Clause 6 — Source Code and Artifact Integrity:** +Supplier shall provide a cryptographic hash (SHA-256 minimum) and a digital signature for all software release artifacts. Customer may verify artifact integrity prior to installation. Supplier shall maintain signing key security in accordance with applicable industry standards. diff --git a/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/secure-development-controls.md b/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/secure-development-controls.md new file mode 100644 index 0000000..2235f43 --- /dev/null +++ b/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/secure-development-controls.md @@ -0,0 +1,374 @@ +# Secure Development Controls — DevSecOps Pipeline and Build Security + +**Source:** NIST SP 800-218 v1.1; SLSA Framework v1.0; OWASP CI/CD Security Top 10; OpenSSF Scorecard; EO 14028; OMB M-22-18; OMB M-23-16 + +This reference documents the technical controls for securing the software development pipeline, build environment, and software supply chain, aligned to SSDF practice groups PO and PS. + +--- + +## DevSecOps Pipeline Architecture + +A DevSecOps pipeline integrates security tooling and policy gates directly into the CI/CD workflow. The pipeline must not be optional — security gates enforce that releases cannot proceed without passing security checks. + +### Required Pipeline Security Stages + +``` +[Developer Workstation] + pre-commit hooks: + - secrets detection (gitleaks / detect-secrets) + - code formatting / linting compliance + - SAST lite check (Semgrep, fast rules) + +[Version Control — Pull Request Opened] + automated status checks (required to pass before merge): + - SAST full scan (SonarQube / Semgrep / CodeQL) + - SCA scan (OWASP Dependency-Check / Snyk / Black Duck) + - IaC scan (checkov / tfsec / terrascan) if IaC modified + - Secrets scan (trufflehog / gitleaks on diff + history) + - Licence compliance check (FOSSA / Licensee) + human checks (required to pass before merge): + - Minimum 2 reviewers approved + - CODEOWNERS approval for security-critical modules + - Security review for changes to auth, crypto, admin modules + +[CI Build — On Merge to Main] + build stage: + - Dependency install from private proxy/cache + - Compile with security hardening flags (PW.6) + - Unit tests + security unit tests + security scan stage: + - Container image build + image vulnerability scan (Trivy / Snyk Container) + - SBOM generation (Syft / CycloneDX CLI) + - SLSA provenance generation + artifact publishing: + - Sign artifact (cosign / GPG) + - Publish to controlled artifact registry with metadata + +[Pre-Release Test Environment Deployment] + DAST: + - OWASP ZAP baseline scan (automated) + - API security scan + security integration tests: + - Security regression test suite + - Authentication and authorisation test cases + penetration test: + - Full application penetration test for major releases + - Limited scope spot-check for minor releases + +[Release Approval Gate] + automated checks: + - All previous gates passed + - No open critical/high vulnerabilities without risk acceptance + - SBOM generated and signed + - Artifact signature verified + human approval: + - Release manager approval + - Security sign-off for major releases + +[Production Deployment] + deployment controls: + - Signed artifact verified before deployment + - SBOM published to consumers or stored in repository + - Deployment recorded in change management system + +[Production Monitoring] + runtime security monitoring: + - CVE alert feed monitoring against deployed SBOM components + - WAF and runtime anomaly detection + - Dependabot / Renovate continuous dependency update PRs +``` + +--- + +## SAST Configuration + +### Semgrep Recommended Rulesets for SSDF + +| Ruleset | Focus | SSDF Practice | +|---------|-------|--------------| +| p/security-audit | Broad security patterns | PW.5, PW.7 | +| p/owasp-top-ten | OWASP Top 10 vulnerabilities | PW.5, PW.7 | +| p/cwe-top-25 | CWE Top 25 dangerous weaknesses | PW.5, PW.7 | +| p/secrets | Hardcoded credentials and API keys | PS.1 | +| p/supply-chain | Supply chain risk patterns | PW.4 | +| p/jwt | JSON Web Token misuse | PW.5 | +| p/xss | Cross-site scripting | PW.5 | +| p/sql-injection | SQL injection patterns | PW.5 | +| p/insecure-transport | HTTP usage, weak TLS | PW.5 | + +### SARIF Output and Integration + +Static Analysis Results Interchange Format (SARIF) v2.1.0 is the standard format for SAST tool outputs. SARIF enables: +- Unified finding display in GitHub Code Scanning or Azure DevOps +- Finding deduplication across multiple scanners +- Historical trending of finding count by severity +- PR annotations showing findings inline on changed lines + +SARIF severity mapping: +- `error` → SAST finding blocks PR merge (Critical/High threshold) +- `warning` → SAST finding displayed but does not block +- `note` → Informational finding + +### CodeQL Queries for SSDF-Critical CWEs + +| CQL Query Name | CWE | SSDF Practice | +|----------------|-----|--------------| +| SqlInjection | CWE-89 | PW.5 | +| ReflectedXss | CWE-79 | PW.5 | +| StoredXss | CWE-79 | PW.5 | +| UnsafeDeserializationOfUserInput | CWE-502 | PW.5 | +| CommandInjection | CWE-78 | PW.5 | +| PathInjection | CWE-22 | PW.5 | +| SensitiveDataLogged | CWE-532 | PW.5, PO.2 | +| HardcodedCredentials | CWE-798 | PS.1 | +| InsecureRandomness | CWE-338 | PW.5 | +| UnusedCatchBlock | CWE-390 | PW.5 | +| RegexInjection | CWE-730 | PW.5 | + +--- + +## SCA and Dependency Management + +### Software Composition Analysis Scanning Coverage + +SCA tools must analyse: +1. Direct dependencies declared in manifests (package.json, requirements.txt, pom.xml, go.mod, Gemfile, Cargo.toml) +2. Transitive (indirect) dependencies pulled in by direct dependencies +3. OS-level packages in container images (RPM, DEB packages) +4. Libraries statically compiled into executables (where detectable) +5. Development dependencies (may not require same urgency as production but should be monitored) + +### Dependency Version Pinning Strategy + +| Level | Description | Benefit | Risk | +|-------|-------------|---------|------| +| Dependency Range (e.g., ^1.2.0) | Allows minor/patch updates | Automatic security patches | Non-deterministic builds; may pull breaking changes | +| Version Lock (pin to e.g., 1.2.3) | Specific version only | Deterministic builds | Must manually update; risks missing security patches | +| Hash Pinning (pin to SHA-256 of package) | Specific content hash | Maximum integrity assurance | Requires manual update on any change | + +**SSDF recommendation:** Use version pinning with a lock file (package-lock.json, poetry.lock, go.sum) for deterministic builds. Supplement with automated dependency update pull requests (Dependabot or Renovate) configured to create PRs for patch and minor updates with SCA scan on each. Hash pinning recommended for critical cryptographic or authentication libraries. + +### OWASP Dependency-Check Integration + +OWASP Dependency-Check (ODC) identifies project dependencies with known published CVEs. + +```yaml +# ODC CI/CD integration example (GitHub Actions) +- name: Run OWASP Dependency-Check + uses: dependency-check/dependency-check-action@main + with: + project: 'my-project' + path: '.' + format: 'SARIF' + args: > + --failOnCVSS 7 + --enableRetired + --suppression suppression.xml + env: + JAVA_HOME: ${{ env.JAVA_HOME_17_X64 }} + +- name: Upload ODC results to GitHub Security + uses: github/codeql-action/upload-sarif@v3 + with: + sarif_file: reports/dependency-check-report.sarif +``` + +--- + +## Secrets Management Controls + +### Secret Types and Detection Patterns + +| Secret Type | Detection Pattern (regex class) | Rotation Action | +|------------|-------------------------------|-----------------| +| AWS Access Key | AKIA[0-9A-Z]{16} | Immediate key revocation in IAM | +| AWS Secret Key | 40-char base64 adjacent to AKIA key | Immediate key revocation | +| GitHub PAT (classic) | ghp_[a-zA-Z0-9]{36} | Revoke token at github.com/settings/tokens | +| GitHub App Installation Token | ghs_[a-zA-Z0-9]{36} | Token auto-expires but revoke immediately | +| Generic API Key | api_key|apikey|api-key followed by 20+ char value | Identify service → revoke in service console | +| Private Key (PEM) | -----BEGIN (RSA|EC|OPENSSH|PRIVATE) KEY----- | Generate new key pair; rotate all dependent certs | +| Database URL with password | (postgres|mysql|mongodb):\/\/[^:]+:[^@]+@ | Rotate database user password | +| JWT Secret | Common variable names: JWT_SECRET, SECRET_KEY + long string | Rotate secret; invalidate all existing JWTs | +| Slack Webhook URL | hooks.slack.com/services/[^ ]+ | Regenerate webhook in Slack app settings | +| NPM Auth Token | npm_[a-zA-Z0-9]{36} | Revoke token at npmjs.com | + +### Secrets Management Platform Integration + +Recommended secrets delivery pattern for build pipelines: + +``` +[Pipeline Job Starts] + → CI/CD platform authenticates to secrets manager using OIDC workload identity + → Secrets manager validates OIDC token claims (repository, workflow, branch) + → Secrets manager returns time-limited secret value or temporary credentials + → Secret injected as environment variable ONLY for the job scope + → Secret NOT written to disk, NOT included in logs + [Pipeline Job Ends] + → Temporary credentials expire automatically + → No secret persists in pipeline environment +``` + +OIDC-based authentication eliminates the need for long-lived static credentials in CI/CD pipelines — the most common source of supply chain CI/CD compromises. + +Supported patterns: +- GitHub Actions → AWS (OIDC): `aws-actions/configure-aws-credentials` +- GitHub Actions → Vault (OIDC): `hashicorp/vault-action` +- GitLab CI → AWS (OIDC): `id_tokens` block with `sts:AssumeRoleWithWebIdentity` +- Azure DevOps → Azure Key Vault: Service connection with workload identity federation + +--- + +## Container Security Controls + +Container images are a common software delivery artifact. Container security requirements: + +### Image Build Security + +| Control | Implementation | +|---------|---------------| +| Base image selection | Use official minimal base images: distroless, alpine, ubi-minimal; avoid generic ubuntu/debian for production | +| Base image version pinning | Pin base image to digest: `FROM gcr.io/distroless/java17-debian12@sha256:` | +| CVE-free at build time | Run Trivy or Snyk Container scan; fail build if CRITICAL OS CVEs present | +| No secrets in image layers | SAST scan Dockerfiles for secret patterns; verify with docker history inspection | +| Run as non-root | Dockerfile must include `USER nonroot` or equivalent non-UID-0 user | +| Read-only root filesystem | Set `readOnlyRootFilesystem: true` in Kubernetes securityContext | +| Drop all capabilities | Set `capabilities: drop: ["ALL"]` in Kubernetes securityContext | +| No privileged containers | Prohibit `privileged: true` except for explicitly approved infrastructure workloads | + +### Container Image Signing with cosign / Sigstore + +```bash +# Sign an image using cosign with GitHub Actions OIDC (keyless signing) +cosign sign --yes "${IMAGE_NAME}@${IMAGE_DIGEST}" + +# Verify image signature (consumer side) +cosign verify \ + --certificate-identity-regexp "https://github.com/org/repo/.github/workflows/release.yml" \ + --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \ + "${IMAGE_NAME}@${IMAGE_DIGEST}" +``` + +Sigstore keyless signing uses short-lived certificates issued by the Fulcio certificate authority, with signed timestamps recorded in the Rekor transparency log. This provides: +- No long-lived signing key to protect +- Verifiable link between the signed artifact and the GitHub Actions workflow that produced it +- Public audit trail of all signatures in Rekor + +--- + +## SBOM Generation and Consumption + +### Generating SBOMs with Syft + +```bash +# Generate CycloneDX JSON SBOM from a container image +syft scan "${IMAGE_NAME}@${IMAGE_DIGEST}" \ + --output cyclonedx-json="sbom.cdx.json" \ + --output spdx-json="sbom.spdx.json" + +# Generate SBOM from filesystem/source code +syft scan dir:./src --output cyclonedx-json="sbom-src.cdx.json" + +# Attach SBOM to OCI image as attestation using cosign +cosign attest --yes \ + --predicate sbom.cdx.json \ + --type cyclonedx \ + "${IMAGE_NAME}@${IMAGE_DIGEST}" +``` + +### SBOM Quality Checks + +A high-quality SBOM must meet these criteria: + +| Quality Dimension | Minimum Requirement | +|------------------|---------------------| +| Completeness | All direct and transitive dependencies included | +| Identifiability | Each component has at least one of: PURL, CPE, or package name + version | +| Machine-readability | SPDX JSON or CycloneDX JSON format | +| Accuracy | Package versions match what is installed (not just what is declared in manifest) | +| Freshness | Generated from the specific build output, not from manifest alone | +| Integrity | SBOM itself is signed (producer signs the SBOM file) | + +### SBOM Consumption for Vulnerability Monitoring + +SBOM-based CVE monitoring workflow: + +``` +[SBOM File] → Extract package list (name, version, PURL/CPE) + → Query OSV.dev API for each package: + GET https://api.osv.dev/v1/query + Body: {"package": {"name": "", "ecosystem": ""}, "version": ""} + → Query NVD API for each CPE: + GET https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName= + → Alert on any result with CVSS >= configured threshold + → Create vulnerability management ticket for each new match + → Re-query on scheduled interval (daily minimum) +``` + +--- + +## EO 14028 / OMB M-22-18 Software Attestation + +### Self-Attestation Requirements + +Software producers providing software to federal agencies must, under OMB M-22-18 and M-23-16, provide: + +1. A software attestation form confirming adherence to SSDF practices +2. Supporting artifacts on request: SBOMs, test reports, vulnerability scan results + +**Attestation form required assertions (aligned to SSDF):** + +| Assertion | SSDF Mapping | +|-----------|-------------| +| The software was developed and built in secure environments | PO.5 | +| Authorised access to developer environments is enforced | PO.5.2 | +| Software source code is protected from unauthorised access | PS.1 | +| The software is verified for integrity via signed artifacts or hashes | PS.2 | +| Software dependencies are inventoried (SBOM) | PS.2, PS.3 | +| Vulnerability scanning is performed during development | PW.7, PW.9 | +| Vulnerabilities are addressed on a risk-prioritised basis | RV.2 | +| Software code is reviewed for security vulnerabilities | PW.7 | + +### Third-Party Assessment + +For critical software (as defined by CISA criteria), self-attestation is not sufficient. A third-party assessment organisation (3PAO) or government-authorised assessor must: + +1. Review the software producer's SSDF practices against a defined criteria +2. Inspect SDLC documentation, toolchain configuration, and policy records +3. Test the attestation claims against observable evidence +4. Issue a third-party assessment report + +Critical software categories (CISA definition): software that operates with elevated privilege, performs critical system functions, or is directly integrated into operational technology or national security systems. + +--- + +## Security Metrics for DevSecOps Programme + +| Metric | Description | Target | Measurement Source | +|--------|-------------|--------|-------------------| +| SAST finding density | Number of SAST findings per 1,000 lines of code | Decreasing trend; below baseline threshold | SAST scan results per release | +| Mean time to remediate — Critical | Average days from critical CVE publication to patch release | <= 15 days | Vulnerability management system | +| Mean time to remediate — High | Average days from high CVE publication to patch release | <= 30 days | Vulnerability management system | +| Dependency freshness | Percentage of dependencies within one major version of latest | >= 90% | SCA scan results | +| EOL dependency count | Number of production dependencies past end-of-life | 0 (or approved exception) | SCA + vendor EOL calendar | +| SBOM completeness rate | Percentage of releases with complete, signed SBOM | 100% | Artifact registry metadata | +| Secrets in code incidents | Number of confirmed secrets committed to code repository | 0 per quarter | Repository scanning results | +| Security training completion | Percentage of developers with current security training | 100% of production code contributors | LMS completion records | +| Pipeline security gate bypass count | Number of approved exceptions to security pipeline gates | <= 2 per quarter with full documentation | Pipeline bypass log | +| Pen test finding closure rate | Percentage of pen test findings closed within SLA | >= 95% | Vulnerability management system | + +--- + +## OWASP CI/CD Security Top 10 Mapping to SSDF + +| OWASP CI/CD Risk | Description | SSDF Controls | +|-----------------|-------------|--------------| +| CICD-SEC-1: Insufficient Flow Control Mechanisms | Ability to push code without reviews and checks | PO.4, PS.1 (branch protection, required gates) | +| CICD-SEC-2: Inadequate Identity and Access Management | Excessive pipeline permissions; shared pipeline credentials | PO.5.3 (least privilege, OIDC-based auth) | +| CICD-SEC-3: Dependency Chain Abuse | Malicious packages; dependency confusion | PW.4 (component evaluation, private proxy, hash pinning) | +| CICD-SEC-4: Poisoned Pipeline Execution | Injecting code into pipeline via pull request triggers | PO.5.3 (pipeline isolation; no privileged access to untrusted code) | +| CICD-SEC-5: Insufficient Pipeline Based Access Controls | Secrets accessible to all pipeline jobs | PO.5.3 (secret scoping; OIDC; no long-lived secrets) | +| CICD-SEC-6: Insufficient Credential Hygiene | Hardcoded credentials in pipeline definitions or source code | PS.1.2 (secrets scanning), PO.5.3 (secrets manager integration) | +| CICD-SEC-7: Insecure System Configuration | Misconfigured version control, artifact registry, or pipeline platform | PO.5 (secure environment baseline) | +| CICD-SEC-8: Ungoverned Usage of 3rd Party Services | Unreviewed third-party actions or integrations with access to pipeline | PW.4 (third-party component evaluation), PO.3 (toolchain governance) | +| CICD-SEC-9: Improper Artifact Integrity Validation | Deploying artifacts without verifying integrity or provenance | PS.2 (signing and hash verification), PS.3 (immutable archive) | +| CICD-SEC-10: Insufficient Logging and Visibility | Lack of audit trail for pipeline activity | PO.5 (audit logging), PW.9 (test evidence retention) | diff --git a/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/ssdf-practices.md b/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/ssdf-practices.md new file mode 100644 index 0000000..8daed56 --- /dev/null +++ b/plugins/nist-sp-800-218/skills/nist-sp-800-218/references/ssdf-practices.md @@ -0,0 +1,553 @@ +# SSDF Practices Reference — All Practice Groups + +**Source:** NIST SP 800-218 v1.1, February 2022 +**CSRC:** https://csrc.nist.gov/publications/detail/sp/800-218/final + +This reference provides the complete SSDF practice inventory with all tasks and representative implementation examples, serving as a detailed lookup for each of the 19 active practices across four practice groups. + +--- + +## PO: Prepare the Organisation + +**Purpose:** Establish the organisational conditions, processes, and resources necessary to ensure that software development is performed securely throughout the SDLC. + +### PO.1 — Define Security Requirements for Software Development + +**Practice description:** Ensure that security requirements that apply to software that the organisation produces are identified, prioritised, and integrated into the SDLC. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PO.1.1 | Identify and communicate the organisation-wide security and privacy requirements to which software must adhere | Map applicable laws (FISMA, HIPAA, PCI DSS, state privacy laws), contractual obligations, and organisational policies to a software security requirement baseline; publish as internal standard | +| PO.1.2 | Identify and communicate the security and privacy requirements for each software project | Conduct application risk classification at project initiation; derive requirements from threat model, data classification, and applicable compliance scope; document in the project security requirements specification | +| PO.1.3 | Periodically review and revise the security requirements to address changes in the threat landscape and regulatory environment | Annual review cycle; ad-hoc review triggered by new CVE patterns, regulatory changes, or significant architectural changes | + +**Key frameworks linked:** +- OWASP Application Security Verification Standard (ASVS): requirement levels 1/2/3 corresponding to application risk tier +- CWE Top 25 Most Dangerous Software Weaknesses: use as a minimum requirements reference +- NIST SP 800-53 SA-8 (Security and Privacy Engineering Principles), SA-15 (Development Process, Standards, and Tools) + +--- + +### PO.2 — Implement Roles and Responsibilities + +**Practice description:** Ensure that everyone participating in the SDLC is prepared to perform their security-related activities. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PO.2.1 | Create new roles or add security duties to existing roles to ensure security activities are owned and performed | Define security responsibilities in job descriptions for: developers (secure coding), architects (threat modelling, secure design), DevOps (pipeline security), product owners (security requirements prioritisation), QA (security test case development) | +| PO.2.2 | Provide role-appropriate training for all SDLC participants on their security responsibilities | Annual role-based security training; new hire security onboarding; training currency tracked in LMS | +| PO.2.3 | Conduct security awareness training for all individuals performing software development | OWASP Top 10 coding awareness; language-specific secure coding examples; phishing and social engineering awareness for developers | + +**Security champion programme:** + +A security champion is a developer or engineer who serves as the primary security point of contact within their development team. The programme: + +1. Selects champions from volunteer developers with security interest +2. Provides champions with advanced training (CISSP, CSSLP, OWASP ASVS, threat modelling) +3. Gives champions a defined responsibility set: security requirement review, threat model facilitation, code review of security-sensitive changes, SAST finding triage +4. Reserves time in sprints for security activities (typically 10–20% of champion's sprint allocation) +5. Connects champions to a security community of practice for knowledge sharing + +**Training curriculum mapping:** + +| Role | Minimum Training | Recommended Additional | +|------|-----------------|----------------------| +| Developer | OWASP Top 10, CWE Top 25, language-specific secure coding | Threat modelling, OWASP ASVS, OWASP WebGoat/Juice Shop practical | +| Security Champion | All developer training + threat modelling workshop | CSSLP, OWASP Testing Guide | +| Architect | Threat modelling (STRIDE/PASTA), secure design principles, OWASP ASVS L3 | Security architecture review facilitation | +| DevOps/Platform | Pipeline security, secrets management, container security, IaC security | SLSA framework, supply chain security | +| QA | Security test case development, DAST tool operation, OWASP Testing Guide | Penetration testing fundamentals | + +--- + +### PO.3 — Implement Supporting Toolchains + +**Practice description:** Use toolchains and their security features to reduce human error and increase repeatability of security activities throughout the SDLC. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PO.3.1 | Specify which toolchain components address which security tasks | Publish the approved toolchain for each SDLC phase; document what security function each tool serves | +| PO.3.2 | Implement and integrate toolchain components; configure to support security tasks | Integrate tools into CI/CD pipeline with required pass/fail gates; configure rulesets and severity thresholds | +| PO.3.3 | Continuously test, maintain, and update toolchain components | Annual toolchain review; alert on tool vendor advisories; retire deprecated tools | + +**Recommended toolchain by SDLC phase:** + +| SDLC Phase | Security Tool Category | Tool Examples | +|-----------|----------------------|--------------| +| IDE / Pre-commit | SAST lite, secret detection, linting | Semgrep, detect-secrets, trufflehog, gitleaks, git-secrets | +| Pull Request / Code Review | SAST, IaC scanning | SonarQube, Checkmarx, Snyk Code, Semgrep, tfsec, checkov | +| CI Build | SCA, container scanning, SBOM generation | OWASP Dependency-Check, Snyk Open Source, Black Duck, Trivy, Syft, CycloneDX CLI | +| Pre-release Testing | DAST, API scanning, fuzz testing | OWASP ZAP, Burp Suite, Nuclei, OSS-Fuzz, AFL++, OWASP Amass | +| Release | Artifact signing, SBOM publishing | cosign, Sigstore, GPG, SLSA provenance generator (slsa-github-generator) | +| Production Monitoring | RASP, WAF, runtime CVE alerting | OpenTelemetry + security dashboards, Dependabot/Renovate alerts | + +**Pipeline gate configuration example:** + +``` +Stage: Security-SAST + Tool: Semgrep (rulesets: p/security-audit, p/owasp-top-ten) + Threshold: FAIL if: + - Any finding with severity=CRITICAL + - Any finding with severity=HIGH AND confidence=HIGH + Action on failure: Block merge to main branch + Notification: Alert security-team@org.example + developer + +Stage: Security-SCA + Tool: OWASP Dependency-Check + Threshold: FAIL if: + - Any CVE with CVSS >= 9.0 in direct dependencies + - Any CVE with CVSS >= 7.0 with known exploit + Action on failure: Block release pipeline; create security defect ticket + +Stage: Security-Container + Tool: Trivy + Threshold: FAIL if: + - Any OS package CVE with severity=CRITICAL + - Container running as root (unless explicit exception) + Action on failure: Block deployment +``` + +--- + +### PO.4 — Define and Use Criteria for Software Security Checks + +**Practice description:** Define and use criteria for checking the security of the software at important decision points in the SDLC. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PO.4.1 | Define criteria for checking software security at phase transitions and at release | Create phase-gate security checklists; define what evidence is required to proceed (test results, review sign-offs, scan artifacts) | +| PO.4.2 | Define severity thresholds for findings that block progression | Document finding severity to gate impact mapping; publish as policy | +| PO.4.3 | Evaluate software against the defined criteria at the appropriate checkpoints | Execute checklists at each gate; document any exceptions with compensating controls and risk acceptance | + +**SDLC security phase-gate checklist:** + +| Gate | Required Evidence | Blocking Criteria | +|------|-----------------|------------------| +| Requirements → Design | Completed threat model, security requirements documented | No threat model, missing security requirements for data classification tier | +| Design → Code | Design review sign-off from architect and security reviewer | Open high/critical design-level risks without accepted mitigation | +| Code → Test | SAST scan complete, no critical/high unmitigated findings, peer code review complete for all changes | Any unreviewed security-critical code, critical SAST findings open | +| Test → Release Candidate | DAST scan complete, penetration test complete (for significant releases), no critical/high findings open without accepted exception | Open critical/high pen test findings without risk acceptance; missing SBOM | +| Release Candidate → Production | Release approval from designated approver; security checklist signed; SBOM archived; artifacts signed | Missing signatures, unsigned artifacts, open critical vulnerabilities | + +--- + +### PO.5 — Implement and Maintain Secure Environments for Software Development + +**Practice description:** Ensure that all components of the environments used for software development are strongly protected from internal and external threats. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PO.5.1 | Separate development, staging, and production environments | Separate cloud accounts or subscriptions per environment; no shared credentials between environments; production access requires MFA + JIT | +| PO.5.2 | Secure the developer environment | Enforce endpoint security (EDR, disk encryption, MFA); require MFA for all code repository access; monitor for credential exposure | +| PO.5.3 | Secure the build environment | Use ephemeral build agents; use OIDC/workload identity for pipeline authentication (no static long-lived secrets stored in pipeline); sign all build outputs | + +**Build environment security requirements:** + +1. Build agents: ephemeral containers or VMs spun up per build job, destroyed after completion — no persistent build workers with accumulated state +2. Secrets management: all build-time secrets retrieved from secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) using temporary credentials via OIDC federation; no secrets in environment variables committed to pipeline definitions +3. Dependency caching: private artifact proxy/cache (Nexus, Artifactory, GitHub Packages) with allow-listing; no direct pull from public registries in production builds +4. Build provenance: generate SLSA provenance attestation for each build; attest build environment, source commit, build steps +5. Artifact signing: sign all release artifacts before publishing; reject unsigned artifacts in deployment pipelines + +**Developer workstation security baseline:** + +| Control | Requirement | +|---------|------------| +| Endpoint protection | EDR agent installed and reporting to security operations | +| Disk encryption | Full disk encryption (BitLocker/FileVault) enabled | +| Screen lock | 5-minute screen lock timeout | +| MFA for repositories | Phishing-resistant MFA required for GitHub/GitLab/Bitbucket access | +| SSH key management | Ed25519 keys minimum; keys protected with strong passphrase; hardware security key recommended | +| Credentials | No hardcoded credentials; use credential manager or OS keychain | +| OS patching | Critical patches applied within 7 days; all patches within 30 days | + +--- + +## PS: Protect the Software + +**Purpose:** Protect all components of the software from tampering and unauthorised access throughout the SDLC and after release. + +### PS.1 — Protect All Forms of Code from Unauthorised Access and Tampering + +**Practice description:** Protect all components of software from being tampered or treated in an unsafe manner, whether they are stored internally or externally. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PS.1.1 | Store all forms of code in version control with access controls | Centralised Git platform with enforced authentication; individual developer accounts (no shared credentials); separate repositories per component | +| PS.1.2 | Limit access to code repositories to authorised individuals; log all access | RBAC on repositories: read/write for developers, read-only for CI/CD service accounts; quarterly access review; audit logging of all access events | +| PS.1.3 | Use two-party review for all code merged to production branches | Branch protection rules requiring minimum 2 reviewer approvals; CODEOWNERS file for security-critical modules requiring security team approval; dismiss stale reviews on push | + +**Repository configuration security baseline:** + +``` +Protected branches: main, release/* + - Require pull request reviews: minimum 2 approvals + - Require review from CODEOWNERS for: auth/, crypto/, admin/, api/security/ + - Dismiss stale reviews when new commits are pushed + - Require status checks to pass: security-sast, security-sca, security-secrets + - Require signed commits + - Require linear history + - Restrict who can push to matching branches: restrict to release engineers + - Block force pushes + - Block branch deletion +``` + +**Secrets in code repository:** + +- Pre-commit hook using gitleaks or detect-secrets to block commits containing patterns matching: API keys, passwords, private keys, tokens, AWS access keys, database connection strings +- Automated scanning of existing repository history: trufflehog --verified on repository + all branches; findings reported to security team for key rotation +- Response to confirmed secret committed: immediately rotate the exposed credential; purge from git history using BFG Repo Cleaner or git-filter-repo; force-push branches; notify affected service owners + +--- + +### PS.2 — Provide a Mechanism for Verifying the Integrity of the Software Release + +**Practice description:** Make software integrity verification information available to software acquirers. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PS.2.1 | Digitally sign software using a code signing certificate or key pair | Authenticode (Windows PE/MSI), Apple Developer ID (macOS, iOS), GPG detached signatures (packages, archives), cosign (container images, generic artifacts) | +| PS.2.2 | Provide hash values for software artifacts using SHA-256 or stronger | Publish SHA-256, SHA-384, or SHA-512 checksums alongside all release artifacts; use sha256sum or CertUtil to generate; publish on secure HTTPS distribution channel | +| PS.2.3 | Protect signing keys securely | Sign using key stored in HSM or cloud KMS (AWS KMS, Azure Key Vault, GCP KMS); never export private key; key access restricted to release pipeline service account; key rotation schedule defined and practiced | + +**SLSA (Supply chain Levels for Software Artifacts) framework levels:** + +| SLSA Level | Requirements | Protections | +|-----------|-------------|------------| +| SLSA 1 | Documented build process | Establishes basic provenance trail | +| SLSA 2 | Version-controlled build process; hosted build platform that generates signed provenance | Guards against build tampering | +| SLSA 3 | Hardened build platform; auditable build platform; builds isolated from other builds | Guards against compromised build platform | +| SLSA 4 (Level 4, now Build L3 in SLSA v1.0) | Hermetic builds; reproducible builds; signed provenance by build platform | Highest assurance of build integrity | + +**Provenance attestation content:** + +```json +{ + "subject": [{"name": "artifact-name", "digest": {"sha256": ""}}], + "predicateType": "https://slsa.dev/provenance/v1", + "predicate": { + "buildDefinition": { + "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1", + "externalParameters": {"workflow": {"ref": "refs/tags/v1.0.0", "repository": "https://github.com/org/repo", "path": ".github/workflows/release.yml"}}, + "resolvedDependencies": [{"uri": "git+https://github.com/org/repo", "digest": {"gitCommit": ""}}] + }, + "runDetails": {"builder": {"id": "https://github.com/slsa-framework/slsa-github-generator"}, "metadata": {"invocationId": "", "startedOn": "", "finishedOn": ""}} + } +} +``` + +--- + +### PS.3 — Archive and Protect Each Software Release + +**Practice description:** Preserve the integrity of each software release by protecting it from any changes. + +| Task ID | Task Description | Example Implementations | +|---------|-----------------|------------------------| +| PS.3.1 | Store each release version as an immutable, integrity-verified archive | Immutable object storage (S3 Object Lock, Azure Blob immutable storage, Google Cloud Storage Object Hold); compute and record SHA-256 hash of archive at ingest | +| PS.3.2 | Keep records of all release artifacts, and all relevant observations about the software's security | Per-release security package contents (see below) | +| PS.3.3 | Restrict and audit access to archived releases and their associated records | IAM-controlled access to artifact archive; only release engineers and auditors may access; all access logged | + +**Per-release security package contents:** + +``` +release-v/ + artifacts/ + software-. (signed release binary/package) + software-..sha256 (cryptographic hash) + software-..sig (detached GPG or cosign signature) + sbom/ + software-.spdx.json (SPDX format SBOM, signed) + software-.cdx.json (CycloneDX format SBOM) + security/ + sast-results-.sarif (SAST tool output in SARIF format) + sca-results-.json (SCA dependency scan output) + dast-results-.json (DAST scan summary) + pentest-report-.pdf (penetration test report — CONFIDENTIAL) + vulnerability-exceptions.json (risk-accepted findings with approver and expiry) + provenance/ + slsa-provenance.intoto.jsonl (SLSA provenance attestation) + approvals/ + release-approval-.md (signed release approval record) +``` + +--- + +## PW: Produce Well-Secured Software — Extended Detail + +### PW.1 — Design Software to Meet Security Requirements and Mitigate Security Risks + +**Threat modelling process:** + +Step 1 — Scope and decompose the system: +- Create a data flow diagram (DFD) at Level 0 (system context) and Level 1 (major components) +- Identify: processes, data stores, external entities, data flows +- Draw trust boundaries between different security domains + +Step 2 — Identify threats: +- Apply STRIDE to each DFD element: + - Spoofing: can an attacker impersonate a principal or component? + - Tampering: can an attacker modify data in transit or at rest? + - Repudiation: can a legitimate user deny performing an action? + - Information Disclosure: can unauthorised parties access sensitive data? + - Denial of Service: can availability of the system be disrupted? + - Elevation of Privilege: can an attacker gain elevated permissions? + +Step 3 — Evaluate threats: +- Assign DREAD scores (Damage, Reproducibility, Exploitability, Affected users, Discoverability) or CVSS pre-exploit base scores +- Prioritise by score + +Step 4 — Determine mitigations: +- For each threat: accept / transfer / avoid / mitigate +- Document mitigation approach taken +- Map mitigations to SP 800-53 controls or OWASP ASVS requirements + +Step 5 — Validate: +- Design review verifies all threats have a documented disposition +- Mitigations verified in code and test phases + +--- + +### PW.4 — Reuse Existing, Well-Secured Software When Feasible + +**Component health evaluation criteria:** + +| Criterion | Acceptable | Warning | Reject | +|-----------|-----------|---------|--------| +| Last maintainer activity | < 6 months | 6–18 months | > 18 months (no response to issues) | +| Known CVEs | None or all patched | Any CVSS < 7.0 unpatched | Any CVSS >= 7.0 unpatched | +| Licence | Permissive (MIT, Apache-2.0, BSD) | Weak copyleft (LGPL) — legal review | Strong copyleft (GPL) in commercial product — legal review required | +| Download volume / community | Large active community | Small but active | Effectively abandoned | +| OpenSSF Scorecard | >= 7.0 | 4.0–6.9 | < 4.0 | +| Security policy | SECURITY.md present | No security policy but responsive | No security policy and unresponsive | + +**OpenSSF Scorecard checks (key checks for SSDF alignment):** + +- Branch-Protection: branch protection enabled (PO.5) +- Code-Review: code review required (PS.1) +- Dangerous-Workflow: no dangerous patterns in CI (PO.3, PO.5) +- Dependency-Update-Tool: automated dependency updates configured (PW.4) +- Fuzzing: fuzz testing active (PW.9) +- Maintained: recent commits — maintenance not abandoned (PW.4) +- Pinned-Dependencies: dependencies pinned to specific hashes (PW.4, PS.2) +- SAST: SAST tool runs in CI (PW.7) +- Security-Policy: SECURITY.md present with disclosure process (RV.1) +- Signed-Releases: release artifacts signed (PS.2) +- Token-Permissions: principle of least privilege in workflow tokens (PO.5) +- Vulnerabilities: no unpatched CVEs in default branch (RV.2) + +--- + +### PW.5 — Create Source Code by Adhering to Secure Coding Practices + +**Language-specific secure coding standards reference:** + +| Language | Primary Standard | Key CWE Risks to Address | +|----------|----------------|--------------------------| +| C / C++ | CERT C Coding Standard, MISRA C (embedded) | CWE-119 (buffer overflow), CWE-416 (use-after-free), CWE-401 (memory leak), CWE-190 (integer overflow) | +| Java | CERT Java Coding Standard, Oracle Secure Coding Guidelines | CWE-502 (deserialization), CWE-611 (XXE), CWE-78 (OS command injection) | +| Python | OWASP Python Cheat Sheet, Bandit ruleset | CWE-89 (SQL injection), CWE-78 (command injection), CWE-22 (path traversal) | +| JavaScript / TypeScript | OWASP JavaScript Security Cheat Sheet | CWE-79 (XSS), CWE-1321 (prototype pollution), CWE-918 (SSRF) | +| Go | Google Go security guidelines | CWE-89 (database/sql without parameterisation), CWE-22 (filepath.Join bypass) | +| .NET / C# | Microsoft SDL secure coding, .NET security checklists | CWE-502 (BinaryFormatter deserialization), CWE-89 (ADO.NET without parameters) | +| Ruby | Brakeman ruleset, Rails security guide | CWE-89 (ActiveRecord raw SQL), CWE-77 (shell injection via backticks) | +| PHP | OWASP PHP Security Cheat Sheet | CWE-89, CWE-98 (file inclusion), CWE-79 if output not escaped | + +**Universal secure coding principles (language-agnostic):** + +1. Input validation: reject inputs that do not conform to an expected allowlist of characters, lengths, and formats; never construct queries, commands, or markup from untrusted input without neutralisation +2. Output encoding: use context-appropriate encoding before inserting untrusted data into HTML (HTML entity encoding), JavaScript (JS escape), URL (percent encoding), SQL (parameterised queries), OS command (avoid; use subprocess with array arguments) +3. Authentication: use established identity libraries; never implement custom authentication protocols; enforce MFA for privileged operations +4. Session management: use cryptographically random session identifiers; set Secure and HttpOnly flags on cookies; implement session expiry; revalidate session after privilege change +5. Cryptography: use current algorithms only (AES-256-GCM, ChaCha20-Poly1305, RSA-2048+, ECC P-256+, SHA-256+); use established cryptographic libraries; never implement custom cryptographic algorithms; never use MD5 or SHA-1 for security purposes +6. Error handling: return generic error messages to users; log detailed error information to secure log store; never expose stack traces, database errors, or internal paths in user-facing responses +7. Logging: log security events (authentication, authorisation failures, input validation failures, privilege changes) with sufficient context; exclude sensitive data (passwords, credentials, session tokens, PII) from logs + +--- + +### PW.9 — Test Executable Code to Identify Vulnerabilities + +**Security testing approach by test type:** + +| Test Type | Purpose | When | Tools | +|-----------|---------|------|-------| +| SAST | Find vulnerabilities in source code | PR + CI build | Semgrep, CodeQL, SonarQube, Checkmarx | +| SCA | Identify vulnerable dependencies | PR + CI build | OWASP DC, Snyk, Black Duck, Trivy | +| Secrets scanning | Detect committed credentials | Pre-commit + CI | gitleaks, detect-secrets, trufflehog | +| DAST (baseline) | Automated web vulnerability scan | CI on test environment | OWASP ZAP baseline scan | +| DAST (full active) | Full web vulnerability assessment | Release candidate | OWASP ZAP full scan, Burp Suite | +| API security testing | REST/GraphQL/gRPC vulnerability testing | Release candidate | OWASP ZAP, Burp Suite REST extension, Postman security tests | +| Container scanning | OS and layer vulnerability scanning | CI build | Trivy, Snyk Container, Clair | +| IaC scanning | Infrastructure-as-code misconfiguration | PR + CI | tfsec, checkov, terrascan, kics | +| Fuzz testing | Discover edge cases and memory corruption | Ongoing / nightly | libFuzzer, AFL++, boofuzz, ClusterFuzz | +| Penetration test | Adversarial exploitation attempt | Pre-production release and annually | PTES methodology; OWASP Testing Guide | +| Software composition analysis — licence | Identify licence compliance issues | PR + CI | FOSSA, Black Duck, Licensee | + +**Penetration test scope document template:** + +``` +Software Penetration Test Scope — v +Target application: +Target version: +Test environment: Dedicated test environment (not production); URL/endpoint: +Test window: to +Testing methodology: OWASP Testing Guide v4.2 / PTES +In scope: + - Web application: all endpoints and functionality accessible at + - API: REST API endpoints as documented in + - Mobile application: version +Out of scope: + - Production environment and production data + - Third-party services and integrations (no active testing against external providers) + - Denial of service attacks + - Social engineering +Rules of engagement: + - Immediately notify if critical finding discovered that affects production + - No active exploitation of discovered vulnerabilities that could result in data loss +Deliverables: + - Final report within 5 business days of test completion + - Executive summary, technical findings (with CVSS scores, reproduction steps, remediation guidance), appendix with all test evidence +``` + +--- + +## RV: Respond to Vulnerabilities — Extended Detail + +### RV.1 — Identify and Confirm Vulnerabilities + +**Vulnerability disclosure policy (VDP) template:** + +``` +Vulnerability Disclosure Policy — + +Security Contact: security@.example +PGP Key Fingerprint: (available at ) + +Scope: + In scope: all software products listed at + Out of scope: third-party services, infrastructure not managed by + +What to report: + - Authentication or authorisation vulnerabilities + - Remote code execution vulnerabilities + - SQL injection, XSS, or other injection vulnerabilities + - Memory corruption vulnerabilities + - Sensitive data exposure + - Cryptographic vulnerabilities + +Process: + 1. Submit report to security@.example + 2. Acknowledgement within 2 business days + 3. Initial severity assessment shared within 5 business days + 4. Remediation timeline communicated within 10 business days + 5. Coordinated disclosure: we request 90 days before public disclosure to allow remediation + 6. We do not take legal action against researchers following this policy + +Recognition: + We maintain a public Hall of Fame for reporters of valid security issues. + We do not currently offer a monetary bug bounty. +``` + +**External vulnerability source monitoring:** + +| Source | Frequency | Mechanism | +|--------|-----------|-----------| +| NVD (nvd.nist.gov) | Daily | NVD API query for products in SBOM/CPE inventory | +| CISA KEV (Known Exploited Vulnerabilities) | Daily | CISA KEV JSON feed subscription; alert on any KEV match to software inventory | +| Vendor security advisories | Per advisory | Advisory mailing list subscription per vendor | +| GitHub Security Advisories | Daily | Dependabot alerts or GitHub API | +| OSV.dev | Daily | OSV API query for package ecosystem | +| Bug bounty / responsible disclosure | Continuous | Monitored security email address | + +--- + +### RV.2 — Assess, Prioritise, and Remediate Vulnerabilities + +**Vulnerability severity and remediation SLA:** + +| CVSS v3.1 Base Score | Severity | Remediation SLA | Risk Acceptance Authority | +|---------------------|----------|----------------|--------------------------| +| 9.0–10.0 | Critical | 15 calendar days | CISO; compensating control if patch unavailable | +| 7.0–8.9 | High | 30 calendar days | Security Manager | +| 4.0–6.9 | Medium | 90 calendar days | Engineering Lead | +| 0.1–3.9 | Low | 180 calendar days or next planned release | Development Team | +| 0.0 (Informational) | Informational | Best effort; no SLA | Development Team | + +**CVSS environmental scoring adjustments:** + +Environmental metrics allow the base CVSS score to be adjusted for the specific context: + +- Modified Attack Vector: if the vulnerability requires network access but the service is internal-only network-accessible, this may reduce the effective score +- Modified Confidentiality/Integrity/Availability Impact: if the affected system processes public data only (no PII, no financial), Confidentiality Impact may be reduced +- Compensating Controls (CR/IR/AR): if a WAF, network restriction, or other compensating control is in place that meaningfully reduces exploitability, this reduces temporal and environmental scores + +Always document: +1. Base CVSS score (from NVD or vendor) +2. Environmental adjustments applied and rationale +3. Final effective score used for prioritisation +4. Approver name and date + +**Patch delivery options decision tree:** + +``` +Vulnerability confirmed → Assign CVSS score +→ Is a patch available from vendor/maintainer? + YES → Apply patch per SLA; regression test; release patch version + NO → Is a workaround available (WAF rule, configuration change, feature disable)? + YES → Apply compensating control; document; set review date (30 days or when patch appears) + NO → Is the risk acceptable given asset context? + YES → Risk accept with ISSO/CISO approval; document with expiry date + NO → Remove or replace the vulnerable component +``` + +--- + +### RV.3 — Analyse Vulnerabilities to Identify Root Causes + +**Root cause taxonomy:** + +| Root Cause Category | CWE Class | SDLC Phase | Preventive Action | +|--------------------|-----------|-----------|-------------------| +| Input validation omission | CWE-20 | Coding | Add input validation training; SAST rule for untrusted input usage | +| SQL injection via string concatenation | CWE-89 | Coding | Enforce ORM usage or parameterised queries via SAST | +| Reflected/stored XSS | CWE-79 | Coding | Enforce output encoding library; template auto-escaping; CSP policy | +| Insecure direct object reference | CWE-639 | Design/Coding | Add design review checklist item for authorisation on resource access | +| Hardcoded credential | CWE-798 | Coding | Pre-commit secret detection; secrets management training | +| Dependency vulnerability | CWE-1035 | Build/Maintenance | SCA alerts; dependency update automation (Dependabot/Renovate) | +| Missing authentication | CWE-306 | Design | Add authentication requirement to all endpoints in design review | +| Insecure deserialization | CWE-502 | Coding | Prohibit native deserialization of untrusted data; use JSON/XML with schema validation | +| Security misconfiguration | CWE-16 | Operations | IaC scanning; security baseline configuration standards | +| Insufficient logging | CWE-778 | Design/Coding | Security logging requirements in design checklist | + +**Root cause reporting template (per vulnerability):** + +``` +Vulnerability Root Cause Analysis + +CVE/Ticket ID: +Affected component: +CVSS Score: (environmental: ) +Date introduced: +Date detected: +Detection source: + +Root cause description: + [Describe the specific code pattern, design decision, or process failure that caused the vulnerability] + +CWE classification: CWE- — +SDLC phase where introduced: +Type of failure: + +Why was it not caught earlier? + [Describe why existing controls did not detect it] + +Corrective action for this vulnerability: + [Describe the specific code change or configuration fix applied] + +Systemic preventive actions: + 1. [Training update / SAST rule / checklist addition / policy change — whichever applies] + 2. [Additional action if warranted] + +Owner for preventive actions: +Target completion date: +``` diff --git a/plugins/nist-sp-800-30/.claude-plugin/plugin.json b/plugins/nist-sp-800-30/.claude-plugin/plugin.json new file mode 100644 index 0000000..dd32213 --- /dev/null +++ b/plugins/nist-sp-800-30/.claude-plugin/plugin.json @@ -0,0 +1,23 @@ +{ + "name": "nist-sp-800-30", + "description": "NIST SP 800-30 Rev 1 Risk Assessment advisor — threat source identification, risk model construction, likelihood and impact determination, risk communication, and integration with the RMF and organisational risk management processes.", + "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": [ + "nist", + "nist-sp-800-30", + "risk-assessment", + "threat-analysis", + "vulnerability-assessment", + "risk-management", + "grc", + "federal", + "cybersecurity" + ] +} diff --git a/plugins/nist-sp-800-30/skills/nist-sp-800-30/SKILL.md b/plugins/nist-sp-800-30/skills/nist-sp-800-30/SKILL.md new file mode 100644 index 0000000..e68454f --- /dev/null +++ b/plugins/nist-sp-800-30/skills/nist-sp-800-30/SKILL.md @@ -0,0 +1,369 @@ +--- +name: nist-sp-800-30 +description: > + Expert NIST SP 800-30 Rev 1 risk assessment advisor. Use this skill whenever a user asks + about conducting risk assessments using NIST SP 800-30, including: identifying threat sources + and threat events, assessing vulnerabilities and predisposing conditions, determining + likelihood of occurrence, determining magnitude of impact, calculating risk levels, building + risk registers, communicating and sharing risk assessment results, preparing risk assessment + reports, integrating risk assessments into the NIST Risk Management Framework (RMF), + selecting risk assessment approaches (quantitative, qualitative, semi-quantitative), + or questions about NIST SP 800-30 tasks and steps. Also trigger for: "how do I perform + a risk assessment?", "what is the NIST risk model?", "help me build a risk register", + "threat source identification", "risk likelihood and impact scales", or any federal + information system risk assessment question. +--- + +# NIST SP 800-30 Rev 1 — Risk Assessment Skill + +You are an expert risk assessment advisor specialising in **NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments** (September 2012). You assist **federal agencies, contractors, security teams, and risk management professionals** in conducting rigorous, structured risk assessments for federal information systems and organisations in accordance with NIST guidance. + +This skill is grounded exclusively in NIST SP 800-30 Rev 1. All guidance, scales, tables, and processes referenced are drawn directly from that publication. + +--- + +## How to Respond + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| Risk assessment planning | Structured plan: purpose, scope, assumptions, information sources, risk model | +| Threat source identification | Table: Threat Source | Type | Description | Adversarial Capability | Intent | Range of Effects | +| Threat event identification | Table: Threat Event | Source | Relevance | Likelihood of Initiation | +| Vulnerability/predisposing conditions | Table: Vulnerability | Predisposing Condition | Severity | Pervasiveness | +| Likelihood determination | Table: Threat Event | Initiation Likelihood | Impact Severity | Overall Likelihood | +| Impact analysis | Table: Threat Event | Affected Asset | Impact Type | Impact Magnitude | +| Risk determination | Risk register: Threat Event | Likelihood | Impact | Risk Level | Uncertainty | +| Risk assessment report | Full structured report with executive summary and risk tables | +| RMF integration guidance | Narrative with mapping to RMF steps | +| General question | Clear, concise prose with SP 800-30 task/appendix citations | + +--- + +## NIST SP 800-30 Rev 1 Overview + +### Purpose and Scope +NIST SP 800-30 Rev 1 provides guidance for conducting risk assessments as part of an overall risk management process. It supports the **NIST Risk Management Framework (RMF)** defined in SP 800-37 and the enterprise risk management approach in SP 800-39. Risk assessments inform decision-makers at all three tiers: + +| Tier | Level | Description | +|------|-------|-------------| +| Tier 1 | Organisation | Strategic risk decisions, mission/business functions | +| Tier 2 | Mission/Business Process | Risk to business processes supporting the mission | +| Tier 3 | Information System | Operational system-level risk | + +### Relationship to Other NIST Publications +- **SP 800-39**: Organisational information security risk management (provides the overarching risk management process) +- **SP 800-37**: RMF — Categorise, Select, Implement, Assess, Authorise, Monitor +- **SP 800-53**: Security and privacy controls for federal information systems +- **SP 800-53A**: Guide for Assessing Security and Privacy Controls +- **SP 800-137**: Information Security Continuous Monitoring + +--- + +## The Four-Step Risk Assessment Process + +### Step 1 — Prepare for the Risk Assessment + +**Purpose**: Establish the context and parameters for the assessment before collection of threat, vulnerability, and impact data. + +**Tasks:** + +| Task | Description | Key Output | +|------|-------------|-----------| +| 1-1 | Identify the purpose of the risk assessment | Purpose statement | +| 1-2 | Identify the scope of the risk assessment | Scope boundaries (organisational, system, information) | +| 1-3 | Identify assumptions and constraints | Documented assumptions, resource constraints, time-box | +| 1-4 | Identify sources of threat, vulnerability, and impact information | List of authoritative/supplementary sources (threat intel, CVEs, NVD etc.) | +| 1-5 | Identify the risk model and analytic approaches (Table C-2 applies) | Defined risk model, likelihood function, impact methodology | + +**Risk Model Elements (per SP 800-30 Section 2.2):** +- **Threat sources** (adversarial, accidental, structural, environmental) +- **Threat events** (specific actions or incidents) +- **Vulnerabilities** (weaknesses that enable exploitation) +- **Predisposing conditions** (conditions that increase susceptibility) +- **Likelihood of occurrence** (probability that a threat event is initiated and causes harm) +- **Magnitude of impact** (severity of harm) +- **Risk** (function of likelihood and impact) + +**Analytic Approaches:** +| Approach | Description | When to Use | +|----------|-------------|-------------| +| Quantitative | Numerical values for all risk factors (e.g., ALE = AV × EF × ARO) | When data supports numerical precision | +| Qualitative | Descriptive scales (Very Low–Very High) | Most federal assessments; easier to communicate | +| Semi-quantitative | Numbered scales (1–10) mapped to qualitative descriptors | Balance of precision and communicability | + +--- + +### Step 2 — Conduct the Risk Assessment + +**Purpose**: Identify threats, vulnerabilities, and adverse impacts; determine likelihood and magnitude; calculate risk levels. + +**Tasks:** + +#### Task 2-1: Identify Threat Sources + +Threat sources are categorised into four types per **Appendix D, Table D-1**: + +| Type | Definition | Examples | +|------|-----------|---------| +| **Adversarial** | Individuals or groups seeking to exploit information systems | Nation-states, cyber criminals, hacktivists, insiders, competitors | +| **Accidental** | Non-malicious human errors by authorised users | Misconfigured systems, accidental deletion, user error | +| **Structural** | Failure of equipment, environmental controls, or software | Hardware failure, software bugs, infrastructure decay | +| **Environmental** | Natural disasters and uncontrollable physical events | Flood, earthquake, hurricane, power outage, pandemic | + +For each adversarial threat source, document: +- **Capability**: Very Low / Low / Moderate / High / Very High (relative technical sophistication) +- **Intent**: Confirmed hostile intent, suspected, or opportunistic +- **Targeting**: Specific (targeted) / General (untargeted) + +#### Task 2-2: Identify Threat Events + +A **threat event** is an event or situation initiated by a threat source that has the potential to cause harm. Use **Appendix E, Table E-2** as the basis. + +**Adversarial Threat Event Categories (Appendix E):** +- Reconnaissance, intelligence gathering, targeting +- Exploitation of vulnerabilities (software, configuration, supply chain) +- Exfiltration, extraction, and theft +- Exploitation of supply chain (malicious code in hardware, software, services) +- Targeted attacks (watering hole, spear phishing, social engineering) +- Denial and disruption (DDoS, ransomware, data destruction) +- Corruption and modification of information + +**Non-Adversarial Threat Event Categories:** +- Accidental destruction, loss, alteration of information +- Structural failure of information systems +- Environmental disruption (floods, power) +- Human error by privileged users + +For each identified threat event, record: +- Source (which threat source initiates it) +- Description +- Relevance (Not Relevant / Relevant / Very Relevant) +- Estimated likelihood of initiation + +#### Task 2-3: Identify Vulnerabilities and Predisposing Conditions + +**Vulnerabilities** are weaknesses in systems, procedures, or controls that can be exploited. +**Predisposing conditions** are characteristics of systems or organisations that make threat events more or less likely to have adverse impacts. + +| Factor | Description | Scale | +|--------|-------------|-------| +| Vulnerability severity | Degree to which the vulnerability increases risk | Very Low / Low / Moderate / High / Very High | +| Pervasiveness | How widely the vulnerability or predisposing condition is present | Very Low / Low / Moderate / High / Very High | + +Sources for vuln identification: +- NIST National Vulnerability Database (NVD) +- CISA Known Exploited Vulnerabilities (KEV) catalogue +- NIST SP 800-53 control assessment results (from SP 800-53A) +- Security assessment reports +- Penetration test results +- SIEM and continuous monitoring data + +#### Task 2-4: Determine Likelihood of Occurrence + +Likelihood of occurrence is a **two-part determination** per SP 800-30 Section 3.2.4: + +**Part 1 — Likelihood of threat event initiation** (adversarial) or occurrence (non-adversarial): + +| Qualitative | Semi-Quantitative | Description | +|-------------|------------------|-------------| +| Very High | 96–100 | Near certainty the adversary will initiate the threat event | +| High | 80–95 | Highly likely the adversary will initiate the threat event | +| Moderate | 21–79 | Somewhat likely the adversary will initiate the threat event | +| Low | 5–20 | Unlikely the adversary will initiate the threat event | +| Very Low | 0–4 | Highly unlikely the adversary will initiate the threat event | + +**Part 2 — Likelihood that the threat event causes adverse impact** (given initiation): + +| Qualitative | Description | +|-------------|-------------| +| Very High | Near certain that the threat event results in adverse impact | +| High | Highly likely that the threat event results in adverse impact | +| Moderate | Somewhat likely that the threat event results in adverse impact | +| Low | Unlikely that the threat event results in adverse impact | +| Very Low | Highly unlikely that the threat event results in adverse impact | + +**Overall Likelihood** = combination of Part 1 and Part 2, using the Likelihood of Occurrence matrix (Appendix I, Table I-2). + +#### Task 2-5: Determine Magnitude of Impact + +Impact is assessed per **Appendix H** and across impact types: + +**Impact Types (per FIPS 199 / SP 800-60):** +- Confidentiality +- Integrity +- Availability + +| Level | Qualitative | Description | +|-------|-------------|-------------| +| 5 | Very High | Multiple severe or catastrophic adverse effects on organisational operations, assets, individuals, or national security | +| 4 | High | Severe degradation of capability; major damage to important organisational assets; major harm to individuals | +| 3 | Moderate | Significant degradation; significant damage to organisational assets; significant harm to individuals | +| 2 | Low | Limited degradation; minor damage to assets; minor harm | +| 1 | Very Low | Negligible diminishment; negligible damage; negligible adverse effects on individuals | + +**Impact Areas (beyond CIA triad, per Appendix H):** +- Mission effectiveness +- Reputation and trust +- Financial +- Legal, regulatory, contractual +- Physical infrastructure and safety +- Human safety + +#### Task 2-6: Determine Risk + +**Risk** is a function of the **likelihood of occurrence** and the **magnitude of impact**. SP 800-30 uses a 5×5 risk matrix: + +**Risk Determination Matrix (Appendix I, Table I-4):** + +| | Very Low Impact | Low Impact | Moderate Impact | High Impact | Very High Impact | +|--|----------------|-----------|----------------|------------|----------------| +| **Very High Likelihood** | Low | Moderate | High | Very High | Very High | +| **High Likelihood** | Low | Moderate | Moderate | High | Very High | +| **Moderate Likelihood** | Low | Low | Moderate | High | High | +| **Low Likelihood** | Very Low | Low | Low | Moderate | High | +| **Very Low Likelihood** | Very Low | Very Low | Low | Low | Moderate | + +Risk values: Very Low / Low / Moderate / High / Very High + +Also document **uncertainty** alongside each risk determination: +- **Uncertainty** reflects limitations in data, confidence in threat intelligence, and model assumptions. +- Express as: Low / Moderate / High uncertainty with a brief explanation. + +--- + +### Step 3 — Communicate Risk Assessment Results + +**Purpose**: Communicate results to organisational decision-makers to support risk response decisions. + +**Tasks:** + +| Task | Description | Output | +|------|-------------|--------| +| 3-1 | Communicate risk assessment results to risk executives, authorising officials, and mission/business owners | Risk assessment report (structured) | +| 3-2 | Share risk-related information with stakeholders organisation-wide as appropriate | Risk register updates, briefings, dashboards | + +**Risk Assessment Report Structure:** +1. Executive Summary (purpose, scope, overall risk posture) +2. Risk Assessment Methodology (risk model, analytic approach, assumptions) +3. Threat Sources (list with characteristics) +4. Threat Events (list with descriptions and relevance) +5. Vulnerabilities and Predisposing Conditions +6. Risk Determination Table (all identified risks with likelihood, impact, level, uncertainty) +7. Summary of Key Risks (top risks requiring immediate attention) +8. Appendices (supporting data, sources, methodology details) + +--- + +### Step 4 — Maintain the Risk Assessment + +**Purpose**: Keep the risk assessment current and relevant as the threat landscape, system, and organisational context evolve. + +**Tasks:** + +| Task | Description | Trigger | +|------|-------------|---------| +| 4-1 | Monitor the risk factors that contribute to changes in risk | Continuous monitoring output, threat intelligence | +| 4-2 | Update the risk assessment to reflect the current risk environment | Significant change in system, threat landscape, or mission | + +**Integration with Continuous Monitoring (SP 800-137):** +- Risk assessment results feed into the continuous monitoring strategy +- Security control effectiveness data from ongoing assessments updates risk factors +- Risk assessment refresh recommended: annually at minimum; following significant system changes; following security incidents + +--- + +## Core Workflows + +### 1. Conducting a Risk Assessment (End-to-End) + +1. Clarify: tier level (Org/Mission/System), system type (categorisation), and assessment approach (qualitative/semi-quantitative) +2. Work through all 6 tasks in Step 2 sequentially +3. Produce a risk register table: + +| # | Threat Source | Threat Event | Vulnerability | Likelihood | Impact | Risk Level | Uncertainty | Recommended Response | +|---|--------------|-------------|--------------|-----------|--------|-----------|------------|---------------------| +| 1 | | | | | | | | | + +4. Summarise top risks by risk level (Very High → Very Low) +5. Offer to generate a risk assessment report + +### 2. Risk Register Generation +When building a risk register: +- Use the 5-column format: Threat Event | Likelihood | Impact | Risk Level | Uncertainty +- Group by threat source type (adversarial, accidental, structural, environmental) +- Assign risk IDs (e.g., RA-001, RA-002) +- Flag any risks rated High or Very High for immediate executive attention +- Note residual risk after proposed controls + +### 3. RMF Integration +Risk assessment outputs map to RMF steps (SP 800-37 Rev 2): + +| RMF Step | SP 800-30 Integration | +|----------|----------------------| +| Categorise (Step 1) | Risk assessment informs system categorisation (FIPS 199 impact level) | +| Select (Step 2) | Risk assessment results guide tailoring of SP 800-53 control baselines | +| Assess (Step 4) | Security assessment results update risk factors in task 4-1 | +| Authorise (Step 5) | Risk assessment report is key input to Authorization Package | +| Monitor (Step 6) | Continuous monitoring triggers risk assessment updates per task 4-1/4-2 | + +### 4. Threat Modelling Support +When helping to identify and prioritise threat sources and events: +1. Use Table D-1 (adversarial) and D-2 (non-adversarial) as the starting taxonomy +2. Consider the organisation's sector, mission criticality, and known adversary targeting +3. Apply relevance filtering: is this threat source known to target this type of organisation? +4. Cross-reference CISA advisories and sector-specific threat reports for adversarial assessment +5. For each relevant threat event, trace the kill chain: Initial Access → Execution → Persistence → Privilege Escalation → Exfiltration + +--- + +## Qualitative Risk Scales Reference + +### Likelihood of Threat Event Initiation (Adversarial) — Table G-2 +| Value | Qualitative | Description | +|-------|-------------|-------------| +| 10 | Very High | Adversary is highly capable and motivated; attacks of this type are common against similar targets | +| 8 | High | Adversary is capable and motivated; attacks of this type occur regularly against similar targets | +| 5 | Moderate | Adversary has some capability and motivation; attacks of this type occur occasionally | +| 2 | Low | Adversary has limited capability or motivation; attacks of this type occur rarely | +| 0 | Very Low | Adversary has very limited capability or motivation; attacks of this type are very rare | + +### Likelihood of Adverse Impact (Vulnerability Severity Predicate) — Table G-3 +| Value | Qualitative | Description | +|-------|-------------|-------------| +| 10 | Very High | Vulnerabilities are highly exploitable and widely present; controls are largely absent | +| 8 | High | Vulnerabilities are likely exploitable; controls are mostly absent or ineffective | +| 5 | Moderate | Vulnerabilities are somewhat exploitable; controls exist but have gaps | +| 2 | Low | Vulnerabilities are difficult to exploit; effective controls are in place | +| 0 | Very Low | Vulnerabilities are very difficult to exploit; comprehensive controls exist | + +### Impact Levels — Table H-3 +| Value | Level | Description | +|-------|-------|-------------| +| 10 | Very High | Multiple severe/catastrophic effects on operations, assets, individuals, national security | +| 8 | High | Severe degradation; major damage; major harm | +| 5 | Moderate | Significant degradation; significant damage; significant harm | +| 2 | Low | Limited degradation; minor damage; minor harm | +| 0 | Very Low | Negligible effects; negligible damage; negligible harm | + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +- `references/risk-assessment-process.md` — Detailed task-by-task process guide with all SP 800-30 tables +- `references/threat-taxonomy.md` — Complete threat source and threat event taxonomy from Appendices D and E +- `references/impact-likelihood-scales.md` — All qualitative and semi-quantitative scales for likelihood, impact, and risk determination + +**When to load:** +- Conducting a risk assessment → load `references/risk-assessment-process.md` +- Identifying threats → load `references/threat-taxonomy.md` +- Setting scales or scoring risks → load `references/impact-likelihood-scales.md` + +--- + +## Disclaimer + +This skill provides guidance based on NIST SP 800-30 Rev 1 (NIST, September 2012), a freely available public publication. This skill does not constitute legal, audit, or professional compliance advice. Organisations should engage qualified risk assessment professionals and consult current NIST publications and CISA advisories to validate their risk assessment approach, particularly for high-impact federal information systems. diff --git a/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/impact-likelihood-scales.md b/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/impact-likelihood-scales.md new file mode 100644 index 0000000..6ed5bb9 --- /dev/null +++ b/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/impact-likelihood-scales.md @@ -0,0 +1,143 @@ +# NIST SP 800-30 Rev 1 — Impact, Likelihood, and Risk Scales + +Source: NIST SP 800-30 Rev 1, Appendices G, H, and I (September 2012) + +--- + +## Likelihood Scales + +### Table G-2: Likelihood of Threat Event Initiation (Adversarial) + +Assesses the probability that an adversarial threat source will attempt the threat event against the target organisation during the assessment period. + +| Qualitative Value | Semi-Quantitative Score | Description | +|-------------------|------------------------|-------------| +| Very High | 96 – 100 | Adversary is highly capable and strongly motivated. The threat event is expected to be initiated. Historical precedent and current intelligence indicate near-certainty of occurrence. | +| High | 80 – 95 | Adversary is capable and motivated. It is highly likely the threat event will be initiated. Significant intelligence or historical evidence supports this rating. | +| Moderate | 21 – 79 | Adversary has some capability and motivation. The threat event is as likely to occur as not. Moderate intelligence evidence exists. | +| Low | 5 – 20 | Adversary has limited capability or motivation. The threat event is unlikely to be initiated. Limited evidence of adversary interest in this target type. | +| Very Low | 0 – 4 | Adversary capability or motivation is very limited. The threat event is highly unlikely to be initiated. No evidence of adversary interest. | + +### Table G-3: Likelihood of Adverse Impact (Given Threat Initiation) + +Assesses the probability that the threat event, if initiated, results in actual adverse impact. This is primarily driven by vulnerability severity and control effectiveness. + +| Qualitative Value | Semi-Quantitative Score | Description | +|-------------------|------------------------|-------------| +| Very High | 96 – 100 | Vulnerabilities are highly exploitable; controls are absent or wholly ineffective. Near certainty that initiation leads to adverse impact. | +| High | 80 – 95 | Vulnerabilities are likely exploitable; controls are mostly absent or largely ineffective. Adverse impact is highly likely if the threat is initiated. | +| Moderate | 21 – 79 | Vulnerabilities are somewhat exploitable; controls exist but have notable gaps. Adverse impact is possible but not certain. | +| Low | 5 – 20 | Vulnerabilities are difficult to exploit; effective controls reduce likelihood of adverse impact substantially. | +| Very Low | 0 – 4 | Vulnerabilities are very difficult to exploit; comprehensive and effective controls are in place. Adverse impact is highly unlikely even if the threat is initiated. | + +### Table G-4: Likelihood of Threat Event Occurrence (Non-Adversarial) + +Assesses the probability that a non-adversarial threat event occurs during the assessment period. + +| Qualitative Value | Semi-Quantitative Score | Description | +|-------------------|------------------------|-------------| +| Very High | 96 – 100 | Event is virtually certain to occur. (E.g., disk failure in multi-year operational systems without replacement cycles.) | +| High | 80 – 95 | Event is highly likely to occur. (E.g., user error in high-volume data entry environments.) | +| Moderate | 21 – 79 | Event may occur. (E.g., power outage in regions without robust utility infrastructure.) | +| Low | 5 – 20 | Event is unlikely to occur. (E.g., severe earthquake in a low-seismic region.) | +| Very Low | 0 – 4 | Event is highly unlikely to occur. (E.g., a Category 5 hurricane in an inland, non-coastal data centre.) | + +--- + +## Overall Likelihood Determination + +### Table I-2: Overall Likelihood Matrix + +Overall likelihood combines the likelihood of threat initiation (or occurrence) with the likelihood of adverse impact. + +| | Very Low Impact-Susceptibility | Low | Moderate | High | Very High | +|--|-------------------------------|-----|----------|------|-----------| +| **Very High Initiation** | Low | Moderate | High | Very High | Very High | +| **High Initiation** | Very Low | Low | Moderate | High | Very High | +| **Moderate Initiation** | Very Low | Low | Moderate | Moderate | High | +| **Low Initiation** | Very Low | Very Low | Low | Low | Moderate | +| **Very Low Initiation** | Very Low | Very Low | Very Low | Low | Low | + +--- + +## Impact Scales + +### Table H-2: Impact of Threat Events on Core Missions/Business Functions + +| Qualitative Value | Semi-Quantitative Score | Description | +|-------------------|------------------------|-------------| +| Very High | 96 – 100 | Multiple severe or catastrophic adverse effects on organisational operations, assets, or individuals. Loss of life or severe physical harm; loss of critically sensitive information; complete mission failure; catastrophic financial damage. | +| High | 80 – 95 | Severe degradation in mission capability; significant damage to major assets; major financial damage; major harm to individuals (not life-threatening). | +| Moderate | 21 – 79 | Significant degradation in mission capability; significant damage; significant financial loss; significant harm to individuals (not major or life-threatening). | +| Low | 5 – 20 | Limited degradation of mission capability; minor damage to assets; minor financial loss; minor harm to individuals. | +| Very Low | 0 – 4 | Negligible or no impact on mission capability; negligible damage; negligible financial loss; negligible harm to individuals. | + +### Table H-3: Impact Across CIA Triad and Operational Dimensions + +| Impact Dimension | Very High | High | Moderate | Low | Very Low | +|-----------------|-----------|------|----------|-----|---------| +| **Confidentiality** | Disclosure of critically sensitive information (CLAS, personal data at scale) | Disclosure of sensitive PII, financial records | Disclosure of information requiring protection | Limited disclosure; controlled data | Negligible; public information | +| **Integrity** | Catastrophic corruption of critical data; cannot be recovered | Major data corruption affecting critical transactions | Significant data modification affecting operations | Minor data alteration; detectable | Negligible alteration; no operational effect | +| **Availability** | Complete failure of critical infrastructure; unrecoverable | Extended loss (>24 hours) of critical services | Partial or temporary loss of important services | Brief or minor loss; quickly restored | Negligible interruption | + +--- + +## Risk Determination + +### Table I-4: Risk Level Matrix (Likelihood × Impact) + +Risk is determined by combining overall likelihood with magnitude of impact. + +| Likelihood ↓ / Impact → | Very Low | Low | Moderate | High | Very High | +|------------------------|---------|-----|----------|------|-----------| +| **Very High** | Low | Moderate | High | Very High | Very High | +| **High** | Low | Moderate | Moderate | High | Very High | +| **Moderate** | Low | Low | Moderate | High | High | +| **Low** | Very Low | Low | Low | Moderate | High | +| **Very Low** | Very Low | Very Low | Low | Low | Moderate | + +### Risk Level Definitions (Table I-5) + +| Risk Level | Definition | Required Action | +|-----------|------------|----------------| +| **Very High** | A threat event could be expected to have multiple severe or catastrophic adverse effects on mission operations, assets, or individuals if it occurs. | Corrective measures are urgently required. The risk is unacceptable. Immediate executive attention and remediation resources are required. | +| **High** | A threat event could be expected to have a severe or catastrophic adverse effect. | Corrective measures should be implemented within near-term (30–90 days). Senior leadership notification required. | +| **Moderate** | A threat event could be expected to have a serious adverse effect. | Corrective measures should be implemented within a reasonable period (90–180 days). Management attention and resource allocation required. | +| **Low** | A threat event could be expected to have a limited adverse effect. | Risk is acceptable with standard controls in place. Monitor and include in next assessment cycle. | +| **Very Low** | A threat event could be expected to have a negligible adverse effect. | Risk is acceptable. No additional action required at this time. | + +--- + +## Uncertainty Notation + +All risk determinations must include an **uncertainty** qualifier to indicate confidence in the assessment: + +| Uncertainty Level | Description | +|------------------|-------------| +| **Low** | Assessment is based on comprehensive threat intelligence, detailed vulnerability data, and well-characterised impact. High confidence in the risk determination. | +| **Moderate** | Assessment is based on adequate data but with some gaps in threat intelligence, vulnerability specifics, or impact quantification. | +| **High** | Assessment is based on limited data, significant assumptions, or rapidly changing conditions. Risk determination may shift substantially as more information becomes available. | + +--- + +## Vulnerability Severity Scale — Appendix F, Table F-2 + +| Qualitative Value | Semi-Quantitative Score | Description | +|-------------------|------------------------|-------------| +| Very High | 9 – 10 | Vulnerability is easily exploitable with widely available tools; no technical expertise required; no compensating controls in place | +| High | 7 – 8 | Vulnerability is exploitable with moderate skill; limited compensating controls exist | +| Moderate | 4 – 6 | Vulnerability is exploitable with significant skill; some compensating controls reduce risk but do not eliminate it | +| Low | 2 – 3 | Vulnerability is difficult to exploit; effective controls significantly reduce likelihood of successful exploitation | +| Very Low | 0 – 1 | Vulnerability is very difficult to exploit; comprehensive controls effectively eliminate exploitability | + +--- + +## Predisposing Condition Pervasiveness — Appendix F, Table F-3 + +| Qualitative Value | Description | +|-------------------|-------------| +| Very High | Predisposing condition exists throughout the environment; affects nearly all systems and processes | +| High | Predisposing condition is widespread; affects most systems or processes | +| Moderate | Predisposing condition is present in multiple areas but not pervasive | +| Low | Predisposing condition is limited to a few systems or processes | +| Very Low | Predisposing condition is isolated; affects only a single system or process | diff --git a/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/risk-assessment-process.md b/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/risk-assessment-process.md new file mode 100644 index 0000000..15a6103 --- /dev/null +++ b/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/risk-assessment-process.md @@ -0,0 +1,233 @@ +# NIST SP 800-30 Rev 1 — Risk Assessment Process (Detailed) + +Source: NIST Special Publication 800-30 Rev 1, September 2012 +https://doi.org/10.6028/NIST.SP.800-30r1 + +--- + +## Overview + +NIST SP 800-30 Rev 1 defines a structured four-step process for conducting risk assessments. The process supports all three tiers of risk management: organisation (Tier 1), mission/business process (Tier 2), and information system (Tier 3). + +--- + +## Step 1: Prepare for the Risk Assessment + +### Task 1-1: Identify the Purpose +Define why the risk assessment is being conducted. Common purposes include: +- Support an Authorisation to Operate (ATO) decision +- Inform control selection (RMF Step 2 — Select) +- Assess residual risk after remediation +- Evaluate a proposed system change +- Support annual risk review obligations + +### Task 1-2: Identify the Scope +Define boundaries for the risk assessment: +- **Organisational scope**: Which organisational units, functions, or assets are included +- **System scope**: Which information systems, components, or data types are in scope +- **Information scope**: How sensitive the system and information are (FIPS 199 categorisation) +- **Temporal scope**: Whether the assessment covers current state, future state, or both + +### Task 1-3: Identify Assumptions and Constraints +Document: +- Assessment assumptions (e.g., threat intel sources assumed current) +- Constraints: time, budget, access to systems, availability of data +- Dependencies: what the assessment results will feed into (ATO package, risk register) +- Stakeholder limitations: who can be interviewed or surveyed + +### Task 1-4: Identify Information Sources +Authoritative and supplementary sources include: + +| Category | Sources | +|----------|---------| +| Threat intelligence | CISA advisories, DHS reports, sector-specific ISACs, MS-ISAC, MITRE ATT&CK | +| Vulnerability data | NIST NVD, CISA KEV, CERT/CC, vendor security advisories | +| Organisational data | Previous risk assessments, audit reports, incident logs, POA&M | +| System data | System Security Plan (SSP), architecture diagrams, data flows | +| Regulatory | FIPS 199, SP 800-60, SP 800-53 control baseline | + +### Task 1-5: Identify the Risk Model and Analytic Approaches + +The risk model defines the risk factors and how they combine to produce a risk level. + +**Risk equation (simplified):** +> Risk = f(Likelihood of Threat Event, Magnitude of Impact) + +**Likelihood = f(Likelihood of Threat Initiation, Likelihood of Adverse Impact)** + +**Analytic approaches:** + +| Approach | Scale Type | Best For | +|----------|-----------|----------| +| Qualitative | Descriptive (Very Low – Very High) | Broad surveys; when data precision is low | +| Semi-quantitative | Numerical (0–10 or 1–100 mapped to descriptors) | Most federal assessments | +| Quantitative | Dollar values, probabilities | Financial impact analysis; when actuarial data exists | + +--- + +## Step 2: Conduct the Risk Assessment + +### Task 2-1: Identify Threat Sources + +**Adversarial Threat Sources (Appendix D, Table D-1):** + +| Threat Source | Description | Characteristics | +|---------------|-------------|----------------| +| Nation-State | Foreign intelligence entities with strategic objectives | High capability, specific targeting, patient adversary | +| Cyber Criminal | Organised criminal groups motivated by financial gain | High capability, broad targeting, rapid exploitation | +| Hacktivist | Groups/individuals motivated by ideology or notoriety | Variable capability, public targeting, disruptive methods | +| Insider (Malicious) | Current or former employees/contractors with authorised access | Privileged access, knows system internals, unpredictable motivation | +| Insider (Inadvertent) | Authorised users causing harm through error or negligence | No hostile intent, high frequency, broad impact | +| Business Competitor | Entities seeking competitive intelligence | Variable capability, targeted, economic motivation | +| Terrorist | Entities seeking to cause widespread harm or disruption | Variable capability, target critical infrastructure | +| Script Kiddie | Inexperienced individuals using available exploit tools | Low capability, opportunistic, broad targeting | + +**Non-Adversarial Threat Sources (Appendix D, Table D-2):** + +| Threat Source | Description | +|---------------|-------------| +| Accidental user action | Unintentional modification, deletion, or disclosure by authorised users | +| Hardware failure | Component failure (disk, memory, network hardware) through age or defect | +| Software failure | Application bugs, OS crashes, firmware issues | +| Environmental | Natural or man-made environmental events (weather, power, building) | + +### Task 2-2: Identify Threat Events + +**Adversarial Threat Events (Appendix E, Table E-2 — representative):** + +| Category | Event Examples | +|----------|---------------| +| Reconnaissance | Network scanning, open-source intelligence gathering, social engineering reconnaissance | +| Initial Access | Spear phishing, supply chain compromise, exploitation of public-facing application, use of valid accounts | +| Execution and Persistence | Malware installation, scheduled task creation, registry modification, remote access trojans | +| Privilege Escalation | Exploitation of misconfigured permissions, credential theft, pass-the-hash | +| Lateral Movement | Internal network scanning, use of stolen credentials across systems | +| Exfiltration | Data copying to removable media, upload to adversary-controlled cloud storage, covert channel | +| Impact | Ransomware deployment, data destruction, denial of service, corruption of critical data | +| Supply Chain | Malicious code in commercial software, hardware implants, compromised update mechanism | + +**Non-Adversarial Threat Events:** + +| Category | Event Examples | +|----------|---------------| +| Accidental destruction | Unintentional deletion of critical files, database corruption, accidental overwrite | +| Structural failure | Disk array failure, UPS failure, network switch hardware fault | +| Environmental disruption | Power outage, flooding of data centre, fire, physical access interruption | +| Human error | Misconfigured firewall rule, incorrect patch applied, wrong access level granted | + +### Task 2-3: Identify Vulnerabilities and Predisposing Conditions + +**Vulnerability Categories:** + +| Category | Examples | +|----------|---------| +| Software | Unpatched CVEs, insecure coding practices, missing input validation | +| Configuration | Default credentials, excessive permissions, open ports, disabled logging | +| Process | Inadequate change management, lack of security review in SDLC | +| Access control | Overly permissive access, missing MFA, shared accounts | +| Physical | Unlocked server rooms, unescorted visitors, inadequate CCTV | +| Supply chain | Unverified software components, insufficient vendor vetting | + +**Predisposing Conditions (Appendix F, Table F-5):** +Conditions that increase or decrease the likelihood that a threat event leads to adverse impact: +- Architectural decisions (e.g., flat network with no segmentation increases lateral movement risk) +- Organisational culture (e.g., high security awareness reduces social engineering success) +- Data sensitivity concentration (e.g., all PII in one system increases impact if compromised) +- Geographic exposure (e.g., coastal data centre increases flood risk) + +### Task 2-4: Determine Likelihood of Occurrence + +**Step 1 — Assess likelihood of threat initiation (Table G-2):** +Base this on adversary capability, intent, and current threat intelligence. + +**Step 2 — Assess likelihood that attack succeeds/causes impact (Table G-3):** +Based on vulnerability severity and effectiveness of current controls. + +**Overall Likelihood Matrix (Table I-2):** + +| | Very Low Impact-Susceptibility | Low | Moderate | High | Very High | +|--|-------------------------------|-----|----------|------|-----------| +| **Very High Initiation** | Low | Moderate | High | Very High | Very High | +| **High Initiation** | Very Low | Low | Moderate | High | Very High | +| **Moderate Initiation** | Very Low | Low | Moderate | Moderate | High | +| **Low Initiation** | Very Low | Very Low | Low | Low | Moderate | +| **Very Low Initiation** | Very Low | Very Low | Very Low | Low | Low | + +### Task 2-5: Determine Magnitude of Impact + +**Impact Areas per Appendix H:** + +Core impact considerations for federal systems: +1. **Mission/business effectiveness** — Can the organisation accomplish its mission? +2. **Reputation and trust** — Does the incident erode public confidence? +3. **Financial loss** — Direct costs (remediation, legal) and indirect costs (lost revenue) +4. **Legal/regulatory** — Violation of federal law, FISMA obligations, agency policy +5. **Physical harm** — Personal safety of individuals affected +6. **Critical infrastructure** — Impact on interdependent national-level systems + +**Mapping to FIPS 199 Impact Levels:** + +| Impact Level | Potential Impact | Description | +|-------------|-----------------|-------------| +| HIGH | Severe or catastrophic | Could cause severe degradation or loss of mission capability; major financial harm; severe harm to people | +| MODERATE | Serious | Could cause significant degradation; significant financial loss; significant harm | +| LOW | Limited | Could cause minor degradation; minor loss; minor harm | + +### Task 2-6: Determine Risk + +**Risk Score Matrix (Table I-4):** + +Use likelihood × impact to determine risk level: + +| Likelihood ↓ / Impact → | Very Low | Low | Moderate | High | Very High | +|------------------------|---------|-----|----------|------|-----------| +| Very High | Low | Moderate | High | Very High | Very High | +| High | Low | Moderate | Moderate | High | Very High | +| Moderate | Low | Low | Moderate | High | High | +| Low | Very Low | Low | Low | Moderate | High | +| Very Low | Very Low | Very Low | Low | Low | Moderate | + +--- + +## Step 3: Communicate Risk Assessment Results + +### Risk Assessment Report Template + +**Document Control Block:** +| Field | Value | +|-------|-------| +| Title | Risk Assessment Report — [System/Organisation Name] | +| Version | 1.0 | +| Date | [Date] | +| Classification | [e.g., For Official Use Only] | +| Author | [Name, Role] | +| Reviewed By | [Authorising Official / Risk Executive] | + +**Required Sections:** +1. Executive Summary +2. Scope and Methodology +3. Assumptions and Constraints +4. Risk Assessment Results (risk register table) +5. Summary and Priority Risk List +6. Recommended Risk Responses +7. Appendices + +### Risk Register Table Format + +| Risk ID | Threat Source | Threat Event | Vulnerability | Likelihood | Impact | Risk Level | Uncertainty | Risk Response | +|---------|--------------|-------------|--------------|-----------|--------|-----------|------------|--------------| +| RA-001 | | | | | | | | | + +--- + +## Step 4: Maintain the Risk Assessment + +### Refresh Triggers +- **Periodic**: Annually at minimum for all federal systems; more frequently for HIGH-impact systems +- **Event-driven**: Following a security incident; significant configuration change; system upgrade; new threat intelligence indicating active exploitation +- **RMF-driven**: Prior to ATO renewal; when continuous monitoring reveals degraded control effectiveness + +### Integration with SP 800-137 (Continuous Monitoring) +- Risk assessment provides baseline risk tolerance and accepted risk levels +- Continuous monitoring data (SIEM alerts, vulnerability scan results, control assessments) feeds back into risk factor updates per Task 4-1 +- Risk register maintained as a living document updated from monitoring output diff --git a/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/threat-taxonomy.md b/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/threat-taxonomy.md new file mode 100644 index 0000000..abd1cb6 --- /dev/null +++ b/plugins/nist-sp-800-30/skills/nist-sp-800-30/references/threat-taxonomy.md @@ -0,0 +1,135 @@ +# NIST SP 800-30 Rev 1 — Threat Source and Threat Event Taxonomy + +Source: NIST SP 800-30 Rev 1, Appendices D and E (September 2012) + +--- + +## Adversarial Threat Sources — Appendix D, Table D-1 + +| Threat Source | Tier | Capability | Characteristics | +|---------------|------|-----------|----------------| +| **Nation-State / APT** | 1, 2, 3 | High to Very High | Nation-states conduct sophisticated, persistent, targeted campaigns against government and critical infrastructure. Motivated by espionage, disruption, or sabotage. Employ zero-days, supply chain attacks, and insider recruitment. | +| **Organised Cyber Criminal** | 2, 3 | Moderate to High | Well-resourced criminal groups primarily motivated by financial gain. Conduct ransomware campaigns, business email compromise (BEC), credential theft, and fraud. Use affiliate models (Ransomware-as-a-Service). | +| **Hacktivist** | 2, 3 | Low to Moderate | Individuals or groups acting from ideological or political motivation. Primarily disruptive (DDoS, defacement, data leaks). Target organisations perceived as opposed to their cause. | +| **Insider — Malicious** | 1, 2, 3 | Low to High | Current or former employees, contractors, or partners with authorised access using that access intentionally to cause harm. Motivations include financial gain, grievance, coercion, or ideology. | +| **Insider — Inadvertent** | 1, 2, 3 | N/A | Authorised users who cause harm through error, negligence, or lack of awareness without malicious intent. Highest frequency of incidents; often triggered by phishing, mistakes, or policy non-compliance. | +| **Business Competitor** | 1, 2, 3 | Low to Moderate | Organisations or individuals seeking competitive advantage through corporate espionage, intellectual property theft, or market manipulation. | +| **Terrorist** | 1, 2, 3 | Low to Moderate | Entities seeking to cause widespread physical, social, or economic disruption. May target critical infrastructure systems controlling physical processes. | +| **Script Kiddie / Opportunist** | 3 | Very Low to Low | Inexperienced attackers using publicly available tools and exploits. Typically opportunistic; exploit known vulnerabilities without specific targeting. High volume, low sophistication. | +| **Supplier / Third Party** | 2, 3 | Variable | Entities with legitimate access to systems or data through business relationships. May introduce vulnerabilities through compromised software, hardware, or services, intentionally or by accident. | + +--- + +## Non-Adversarial Threat Sources — Appendix D, Table D-2 + +| Threat Source | Description | Examples | +|---------------|-------------|---------| +| **Authorised user (error)** | Unintentional actions by users with legitimate access | Accidental file deletion, misconfiguration, sending sensitive data to wrong recipient | +| **System / software failure** | Technical failure of hardware, operating systems, or applications | Disk failure, memory corruption, database crash, firmware bug | +| **Environmental — natural** | Natural physical events beyond organisational control | Flood, earthquake, hurricane, tornado, wildfire, extreme temperature | +| **Environmental — man-made** | Physical events caused by human activity in the vicinity | Power grid failure, construction disruption, HVAC malfunction, water pipe burst | + +--- + +## Adversarial Threat Events — Appendix E, Table E-2 + +### Reconnaissance and Intelligence Gathering + +| Event | Description | +|-------|-------------| +| Network/port scanning | Automated discovery of open ports and services on target networks | +| Open-source intelligence (OSINT) | Collection of publicly available information about personnel, infrastructure, and technology | +| Social engineering reconnaissance | Targeted interaction with employees to gather information about systems, processes, or credentials | +| Spear phishing for credentials | Targeted phishing to harvest authentication credentials | +| Physical surveillance | Observation of facilities, personnel, or equipment | + +### Initial Access + +| Event | Description | +|-------|-------------| +| Spear phishing with malicious attachment | Targeted email with malware-laden attachment exploiting user execution | +| Exploitation of public-facing application | Use of CVEs against internet-facing services (web apps, VPNs, email gateways) | +| Valid account abuse | Use of legitimately obtained credentials (purchased, phished, or stolen) | +| Supply chain compromise — software | Malicious code injected into legitimate software updates or development tools | +| Supply chain compromise — hardware | Counterfeit or tampered hardware components containing implants | +| Trusted relationship exploitation | Leveraging access of IT providers, MSPs, or auditors as initial access vector | + +### Execution and Persistence + +| Event | Description | +|-------|-------------| +| Malware installation | Deployment of trojans, backdoors, or remote access tools | +| Scheduled task / startup item creation | Establishing persistence in OS scheduling or startup mechanisms | +| Registry modification | Inserting malicious entries into Windows registry for persistence | +| Living-off-the-land (LOTL) | Abuse of legitimate system tools (PowerShell, WMI, certutil) to avoid detection | +| Web shell deployment | Installing server-side scripts on compromised web servers for persistent access | + +### Privilege Escalation + +| Event | Description | +|-------|-------------| +| Credential dumping | Extraction of hashed or plaintext credentials from memory or registry | +| Pass-the-hash / pass-the-ticket | Use of captured credential hashes or Kerberos tickets without knowing plaintext passwords | +| Exploitation of misconfigured permissions | Leveraging overly permissive ACLs, sudo rules, or service accounts | +| Token impersonation | Abusing Windows token privileges to escalate to SYSTEM | + +### Lateral Movement + +| Event | Description | +|-------|-------------| +| Remote service exploitation | Exploiting CVEs in internal services (SMB, RDP, databases) for lateral movement | +| Remote desktop protocol (RDP) abuse | Use of valid or stolen credentials to connect to other internal systems | +| Pass-the-hash lateral movement | Using captured NTLM hashes to authenticate to additional systems without cleartext passwords | +| Network enumeration | Discovery of internal hosts, services, and trust relationships | +| Active Directory attack | Kerberoasting, AS-REP roasting, DCSync, Golden/Silver Ticket attacks | + +### Exfiltration + +| Event | Description | +|-------|-------------| +| Data exfiltration to cloud storage | Upload of stolen data to attacker-controlled cloud services (S3 buckets, Google Drive, compromised SaaS) | +| Removable media exfiltration | Copying sensitive data to USB drives or other physical media | +| Covert channel exfiltration | Use of DNS tunnelling, ICMP, or encoded HTTP requests to exfiltrate data undetected | +| Email exfiltration | Sending bulk sensitive data as attachments to external accounts | + +### Impact + +| Event | Description | +|-------|-------------| +| Ransomware deployment | Encryption of critical systems and data; extortion demand for decryption key | +| Data destruction | Deletion or overwriting critical data or system files | +| Denial-of-service attack | Volumetric, protocol, or application-layer attacks to exhaust resources | +| System sabotage | Destruction or manipulation of physical systems through compromised control systems (OT/ICS) | +| Data modification | Subtle alteration of critical data to introduce errors or fraud without immediate detection | + +--- + +## Non-Adversarial Threat Events — Appendix E, Table E-3 + +| Event | Threat Source | Description | +|-------|--------------|-------------| +| Accidental deletion | Authorised user | Unintentional removal of production data or configuration files | +| Misconfiguration | Authorised user | Incorrect firewall rule, open S3 bucket, disabled logging | +| Disk array failure | Hardware | RAID failure causing data loss or unavailability | +| Database crash | Software | Application or database failure causing data corruption or unavailability | +| Power outage | Environmental | Loss of utility power causing system shutdown | +| Flooding | Environmental | Physical water intrusion into data centre or office affecting hardware | +| Fire | Environmental | Physical fire damaging equipment and data | +| HVAC failure | Environmental | Overheating of server rooms causing hardware shutdowns or damage | +| Network outage | Structural / Environmental | ISP or internal switching failure causing loss of connectivity | + +--- + +## MITRE ATT&CK Mapping to SP 800-30 Threat Events + +SP 800-30 threat events map to MITRE ATT&CK tactics for operational threat modelling: + +| SP 800-30 Category | MITRE ATT&CK Tactic | +|--------------------|--------------------| +| Reconnaissance | TA0043 — Reconnaissance | +| Initial Access | TA0001 — Initial Access | +| Execution and Persistence | TA0002 — Execution; TA0003 — Persistence | +| Privilege Escalation | TA0004 — Privilege Escalation; TA0006 — Credential Access | +| Lateral Movement | TA0008 — Lateral Movement | +| Exfiltration | TA0010 — Exfiltration | +| Impact | TA0040 — Impact | diff --git a/plugins/nist-sp-800-37/.claude-plugin/plugin.json b/plugins/nist-sp-800-37/.claude-plugin/plugin.json new file mode 100644 index 0000000..91f9542 --- /dev/null +++ b/plugins/nist-sp-800-37/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "nist-sp-800-37", + "description": "NIST SP 800-37 Rev 2 Risk Management Framework (RMF) advisor — all six RMF steps (Categorise, Select, Implement, Assess, Authorise, Monitor), roles and responsibilities, control tailoring, system security plans, authorization packages, and continuous monitoring strategy.", + "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": [ + "nist", + "nist-sp-800-37", + "rmf", + "risk-management-framework", + "ato", + "authorization", + "federal", + "fisma", + "cybersecurity", + "grc" + ] +} diff --git a/plugins/nist-sp-800-37/skills/nist-sp-800-37/SKILL.md b/plugins/nist-sp-800-37/skills/nist-sp-800-37/SKILL.md new file mode 100644 index 0000000..df864f4 --- /dev/null +++ b/plugins/nist-sp-800-37/skills/nist-sp-800-37/SKILL.md @@ -0,0 +1,427 @@ +--- +name: nist-sp-800-37 +description: > + Expert NIST SP 800-37 Rev 2 Risk Management Framework (RMF) advisor. Use this skill + whenever a user asks about the NIST RMF, the six RMF steps (Categorise, Select, Implement, + Assess, Authorise, Monitor), FISMA compliance, Authorisation to Operate (ATO), system + security plans (SSP), security assessment reports (SAR), plans of action and milestones + (POA&M), authorization packages, control tailoring, common control inheritance, continuous + monitoring strategies, RMF roles (ISSO, ISSM, SO, AO, CCP), privacy integration into the + RMF, or linking the RMF to the NIST Cybersecurity Framework (CSF). Also trigger for: + "how do I get an ATO?", "what is the RMF process?", "help me prepare an authorization + package", "what is a common control provider?", "how do I do control tailoring?", or + any federal system security authorisation question. +--- + +# NIST SP 800-37 Rev 2 — Risk Management Framework (RMF) Skill + +You are an expert RMF advisor and federal information security consultant specialising in **NIST Special Publication 800-37 Revision 2: Risk Management Framework for Information Systems and Organizations** (December 2018). You assist **federal agencies, contractors (under FISMA), and organisational risk management teams** in implementing and navigating the full RMF lifecycle. + +This skill is grounded exclusively in SP 800-37 Rev 2. All tasks, roles, inputs, outputs, and processes are drawn directly from that publication. + +--- + +## How to Respond + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| RMF step guidance | Structured step overview with tasks, inputs, outputs, and roles | +| System categorisation | FIPS 199 impact level table with rationale | +| Control baseline selection | Table: Control | Baseline | Tailoring Action | Justification | +| SSP assistance | SSP section templates and guidance | +| Authorization package checklist | Checklist: document | status | notes | +| POA&M guidance | Table: Weakness | Control | Severity | Remediation Plan | Milestones | Responsible Party | +| Continuous monitoring strategy | Structured strategy document | +| Role clarification | Narrative with responsibilities per role | +| General question | Clear, concise prose with SP 800-37 task citations | + +--- + +## RMF Overview + +### Purpose +SP 800-37 Rev 2 describes the **Risk Management Framework** — an integrated, system-level approach to managing information security and privacy risk. The RMF establishes a disciplined and structured process for integrating security, privacy, and cyber supply chain risk management activities into the SDLC. + +### Key Changes in Rev 2 (from Rev 1) +| Topic | Rev 1 | Rev 2 | +|-------|-------|-------| +| Privacy | Separate from security | Fully integrated | +| Supply chain | Not covered | Explicitly included (new Prepare step) | +| Step count | 6 steps | 7 steps (added Prepare) | +| CSF alignment | Implicit | Explicit mapping | +| Automation | Not addressed | Addressed in Prepare and Monitor | +| Missions/business | System-centric | Explicitly multi-tier | + +### The Seven RMF Steps + +| # | Step | Purpose | +|---|------|---------| +| 0 | **Prepare** | Establish context and priorities; assign roles; identify common controls; develop enterprise risk strategy | +| 1 | **Categorise** | Categorise the system and information processed, stored, transmitted based on adverse impact | +| 2 | **Select** | Select, tailor, and supplement security and privacy controls based on risk assessment | +| 3 | **Implement** | Implement controls; document in System Security Plan | +| 4 | **Assess** | Assess whether controls are implemented correctly, operating as intended, producing desired outcomes | +| 5 | **Authorise** | Authorise the system (or controls) based on a determination that residual risk is acceptable | +| 6 | **Monitor** | Continuously monitor control effectiveness; report security and privacy posture; conduct ongoing risk assessment | + +--- + +## Step 0 — Prepare + +### Purpose +Prepare the organisation for RMF execution by establishing roles, responsibilities, risk management strategies, and common control programs. This step is performed at both the **organisation level** and the **system level**. + +### Organisation-Level Tasks + +| Task | Description | Key Output | +|------|-------------|-----------| +| P-1 | Assign risk management roles | Senior Agency Official for Privacy (SAOP), AO, AODR, ISSO, System Owner roles assigned | +| P-2 | Establish risk management strategy and risk tolerance | Organisation-wide risk management strategy document | +| P-3 | Conduct organisation-wide risk assessment | Identifies high-priority threats and risks informing system-level decisions | +| P-4 | Establish organisation-wide control assignments | Common control register; common control providers identified | +| P-5 | Identify, align, and deduplicate missions and business functions | Mission/business function analysis | +| P-6 | Define information types and establish baseline | Organisation-wide information types catalogue aligned to SP 800-60 | +| P-7 | Identify and document common controls | Common control catalogue; inheritance register | +| P-8 | Build organisational-level tailoring guidance | Organisation-specific tailoring policies and scoping guidance | +| P-9 | Develop enterprise architecture | Security and privacy architecture; authorised technologies list | +| P-10 | Define requirements and capabilities | Security and privacy requirements derived from legislation, executive orders, directives | + +### System-Level Prepare Tasks + +| Task | Description | Key Output | +|------|-------------|-----------| +| P-11 | Identify stakeholders | Stakeholder register | +| P-12 | Assign system-level roles | ISSO, ISSM, system administrator, and other system-specific roles | +| P-13 | Identify assets needing protection | Asset inventory | +| P-14 | Conduct system-level risk assessment | System-specific risk assessment feeding categorisation | +| P-15 | Define authorisation boundary | System boundary documentation | +| P-16 | Register the system | System registered in the agency's ISCM/GRC tool | +| P-17 | Identify applicable laws and regulations | Legal, statutory, and policy requirements register | +| P-18 | Identify common control providers | Inheritance documentation | + +--- + +## Step 1 — Categorise + +### Purpose +Categorise the information system and the information processed, stored, and transmitted by the system based on an analysis of the potential impact if confidentiality, integrity, or availability is compromised. + +### Process (FIPS 199 / SP 800-60) + +1. Identify all information types processed, stored, or transmitted (refer to SP 800-60 taxonomy) +2. For each information type, determine provisional impact values for C, I, and A (Low / Moderate / High) +3. Adjust provisional values based on organisational factors (mission criticality, aggregation effects) +4. Determine the **system security category** = highest impact value across all information types (the "high-water mark") +5. Document in the **Security Categorisation document** and the **System Security Plan** + +### FIPS 199 Impact Level Definitions + +| Impact | Confidentiality | Integrity | Availability | +|--------|----------------|-----------|-------------| +| **LOW** | Limited adverse effect: minor mission degradation; minor financial loss; minor harm to individuals | Limited adverse effect | Limited adverse effect | +| **MODERATE** | Serious adverse effect: significant mission degradation; significant loss; significant harm | Serious adverse effect | Serious adverse effect | +| **HIGH** | Severe or catastrophic: severe mission impairment or loss; major financial damage; severe individual harm or loss of life | Severe or catastrophic | Severe or catastrophic | + +### Control Baselines (SP 800-53 Rev 5) +- **LOW system (SC = LOW)** → SP 800-53 Low Baseline +- **MODERATE system (SC = MODERATE)** → SP 800-53 Moderate Baseline +- **HIGH system (SC = HIGH)** → SP 800-53 High Baseline + +### Outputs +- Security Categorisation document +- System description update +- System registration update + +--- + +## Step 2 — Select + +### Purpose +Select, tailor, and supplement the initial set of security and privacy controls based on the categorisation and risk assessment results. + +### Process + +1. **Select baseline**: Map system categorisation to SP 800-53 baseline (Low/Moderate/High) +2. **Apply scoping considerations**: Eliminate controls that are not applicable given system environment/technology +3. **Apply tailoring**: Add/remove controls to address specific risk factors, technologies, or regulatory requirements +4. **Add overlays**: Apply sector-specific control overlays where applicable (e.g., Intelligence Community, DoD, healthcare) +5. **Document**: Record all tailoring decisions in the SSP with justifications +6. **Assign controls to system/common/hybrid**: Determine whether each control is system-specific, inherited (common), or hybrid + +### Tailoring Actions + +| Action | Description | Required Documentation | +|--------|-------------|----------------------| +| **Scoping** | Remove control where it does not apply (e.g., no wireless — remove wireless controls) | Documented rationale in SSP | +| **Parameterisation** | Fill in organisation-defined values for controls with parameters | SSP parameter table | +| **Compensating controls** | Alternative controls where standard controls are not feasible | SSP with compensating control justification | +| **Adding controls** | Add controls not in baseline but required by risk, law, or regulation | SSP with addition rationale | +| **Overlays** | Community-defined control modifications for specific environments | Overlay documentation | + +### Control Assignment Types +| Type | Description | +|------|-------------| +| **System-specific** | Implemented and managed by the system owner for this system only | +| **Common (Inherited)** | Provided by an external organisation or common control provider; system inherits this control | +| **Hybrid** | Part common (inherited), part system-specific | + +### Outputs +- Completed SSP (control selection section) +- Privacy Plan (if applicable) +- Supply Chain Risk Management Plan (if applicable) + +--- + +## Step 3 — Implement + +### Purpose +Implement the security and privacy controls in the information system and in the environment of operation. + +### Process + +1. Implement each selected control (or confirm inheritance) +2. Document implementation details in the SSP for each control: + - Control narrative: how the control is implemented + - Responsible entity + - Implementation status (implemented/planned/not applicable/inherited) +3. Update system architecture documentation if implementation requires changes +4. Address supply chain risk management requirements during acquisition/development +5. Document deviations or compensating implementations + +### SSP Control Implementation Documentation Format + +For each control in the SSP: +``` +Control ID: [e.g., AC-2] +Control Name: [e.g., Account Management] +Assignment: [System-specific / Common / Hybrid] +Status: [Implemented / Planned / Not Applicable / Inherited] +Implementation: [Narrative describing HOW the control is implemented] +Responsible: [Org unit or role responsible] +Evidence: [Location of evidence/audit artefacts] +Inherited From: [Common control provider name, if applicable] +``` + +### Outputs +- Updated SSP (implementation details) +- Security and privacy plans +- Procurement documents with security requirements + +--- + +## Step 4 — Assess + +### Purpose +Assess whether security and privacy controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security and privacy requirements. + +### Process (per SP 800-53A) + +1. **Develop Security Assessment Plan (SAP)**: Define scope, methods, depth/coverage, and timeline +2. **Conduct assessments**: Use assessment procedures from SP 800-53A for each control +3. **Analyse results**: Identify deficiencies and weaknesses +4. **Initial risk assessment**: Determine risk posed by identified weaknesses +5. **Produce Security Assessment Report (SAR)**: Document findings, deficiencies, and recommendations +6. **Develop/update POA&M**: Document weaknesses that are not immediately remediated + +### Assessment Methods (SP 800-53A) + +| Method | Description | +|--------|-------------| +| **Examine** | Review documentation, specifications, mechanisms, and activities | +| **Interview** | Conduct discussions with individuals or groups responsible for controls | +| **Test** | Execute mechanisms and follow activities to compare actual with expected behaviour | + +### Assessment Depth and Coverage + +| Attribute | Values | +|-----------|--------| +| Depth | Basic / Focused / Comprehensive | +| Coverage | Representative sample / All instances | + +### Security Assessment Report (SAR) Contents +1. Assessment scope and methodology +2. Control-by-control findings (Satisfied / Other Than Satisfied / Not Applicable) +3. Weaknesses identified (with severity: Critical/High/Moderate/Low/Informational) +4. Risk determination per weakness +5. Recommendations for remediation + +### Plan of Action and Milestones (POA&M) +POA&M columns: + +| Column | Description | +|--------|-------------| +| POA&M ID | Unique identifier | +| Weakness | Description of the control deficiency | +| Related Control | SP 800-53 control ID(s) | +| Weakness Severity | Critical / High / Moderate / Low | +| Source | Assessment finding, audit, incident, or self-identified | +| Responsible POC | Individual or team responsible for remediation | +| Estimated Completion | Target remediation date | +| Milestones | Intermediate milestones with dates | +| Status | Open / In Progress / Completed / Risk Accepted | +| Resources Required | Staff, budget, tools needed | + +### Outputs +- Security Assessment Plan (SAP) +- Security Assessment Report (SAR) +- Plan of Action and Milestones (POA&M) +- Updated SSP + +--- + +## Step 5 — Authorise + +### Purpose +Provide accountability by requiring a senior official (Authorising Official) to formally accept the risk to organisational operations, assets, individuals, and the nation based on the implementation of an agreed-upon set of security and privacy controls. + +### Authorization Types + +| Type | Description | +|------|-------------| +| **Authorization to Operate (ATO)** | Full authorisation for a specific period (typically 3 years) | +| **Authorization to Use (ATU)** | Authorisation to use an external common control or service | +| **Ongoing Authorization** | Continuous ATO maintained through real-time security posture monitoring (replaces periodic reauthorisation) | +| **Denial of Authorization to Operate (DATO)** | System must cease operation; unacceptable risk level | + +### Authorization Package Contents + +| Document | Description | +|----------|-------------| +| System Security Plan (SSP) | Complete system description, boundary, categorisation, controls, and implementation narratives | +| Security Assessment Report (SAR) | Assessment findings and deficiency determination | +| Plan of Action and Milestones (POA&M) | Open weaknesses and remediation plans | +| Executive Summary | Brief risk posture summary for AO decision-making | +| (Optional) Risk Assessment Report | If conducted as separate artefact | +| (Optional) Privacy Plan + Assessment | Required if processing PII | + +### Authorisation Decision Factors +The AO considers: +1. Completeness of the authorization package +2. Level of residual risk (from SAR + risk assessment) +3. Acceptability of POA&M milestones +4. Organisational risk tolerance +5. Legal, regulatory, and policy obligations + +### Outputs +- Authorization Decision document +- Authorization Decision memo (signed by AO) +- Updated SSP, SAR, POA&M +- Risk acceptance documentation + +--- + +## Step 6 — Monitor + +### Purpose +Maintain ongoing awareness of security and privacy posture through continuous monitoring; assess control effectiveness as the system and threat environment change; report on security and privacy status; and conduct ongoing risk assessments to support authorisation decisions. + +### Continuous Monitoring Tasks + +| Task | Description | Frequency | +|------|-------------|-----------| +| M-1 | Define continuous monitoring strategy | Initial setup + annual review | +| M-2 | Establish monitoring program | Initial setup | +| M-3 | Analyse and report security and privacy posture | Per monitoring strategy (typically monthly/quarterly) | +| M-4 | Ongoing control assessments | Per monitoring strategy (subset of controls at each cycle) | +| M-5 | Ongoing risk response | As needed based on monitoring findings | +| M-6 | Authorisation updates | When significant changes trigger reauthorisation consideration | +| M-7 | System disposal | When system is decommissioned | + +### Continuous Monitoring Strategy Elements +1. **Metrics**: Define security and privacy metrics to collect +2. **Assessment frequencies**: Which controls are assessed at which intervals +3. **Reporting**: How and to whom security posture is reported +4. **Triggers**: Events that trigger immediate notification or reauthorisation (significant changes, incidents) +5. **Automation**: Tools used for automated collection (SIEM, SCAP, vulnerability scanners) + +### Significant Change Definition +Events that may require reauthorisation consideration: +- Changes to system boundary (new components, services, interconnections) +- Changes to authorisation environment (new hosting location, new provider) +- Changes to threat environment (new applicable threat intelligence) +- Performance or functionality changes affecting the SP 800-53 control baselines +- Agency policy changes + +--- + +## RMF Roles and Responsibilities + +| Role | Full Name | Key Responsibilities | +|------|-----------|---------------------| +| **AO** | Authorising Official | Signs the ATO; accepts organisational risk; has budget/mission authority over the system | +| **AODR** | AO Designated Representative | Acts on behalf of AO for day-to-day RMF activities | +| **SO** | System Owner | Responsible for the system's procurement, development, integration, and operation | +| **ISSO** | Information System Security Officer | Day-to-day security oversight; maintains SSP and POA&M; coordinates assessment activities | +| **ISSM** | Information System Security Manager | Manages the ISSO function across multiple systems; escalation point for security issues | +| **CCP** | Common Control Provider | Provides and maintains common inherited controls; documents in a Common Control Plan | +| **SAOP/CPO** | Senior Agency Official for Privacy / Chief Privacy Officer | Privacy integration into RMF; privacy impact assessments | +| **Mission/Business Owner** | Mission/Business Process Owner | Defines mission requirements and risk tolerance | +| **Risk Executive (Function)** | Enterprise Risk Management | Ensures system-level risks are consistent with organisational risk tolerance | +| **SCA** | Security Control Assessor | Independent assessor conducting Step 4 assessments; should be organisationally independent of ISSO | +| **CISO** | Chief Information Security Officer | Agency-wide information security program; FISMA reporting | + +--- + +## Core Workflows + +### 1. Preparing an Authorization Package +When helping to build an ATO package: +1. Verify SSP completeness (boundary, environment, all controls with implementation narratives) +2. Confirm SAR has been completed by an independent SCA +3. Verify POA&M covers all open findings from SAR with realistic milestones +4. Prepare AO briefing package with executive summary and risk summary +5. Include or reference risk assessment report +6. Check that all interconnection and common control inheritance agreements are current + +Checklist format: +| Document | Status | Notes | +|----------|--------|-------| +| SSP — complete with all control narratives | | | +| SSP — categorisation section (FIPS 199) | | | +| SAR — signed by SCA | | | +| POA&M — all SAR findings addressed | | | +| Risk assessment report | | | +| Privacy plan (if PII processed) | | | +| Interconnection Security Agreements (ISAs) | | | +| Memoranda of Understanding/Agreement (MOU/MOA) | | | + +### 2. Control Tailoring Guidance +When asked to tailor a control baseline: +1. Start with the applicable baseline (Low/Moderate/High) from SP 800-53 +2. Apply scoping guidance from SP 800-53 Appendix D +3. Remove controls that are genuinely not applicable (with documented justification) +4. Set all organisation-assigned parameter values +5. Add controls required by applicable law, regulation, or executive directive +6. Identify common/inherited controls and document inheritance agreements +7. Review NIST guidance document for the technology type (cloud, mobile, ICS/OT in separate overlays) + +### 3. Continuous Monitoring Strategy Development +1. Define the organisation's monitoring tier and automation capability +2. Select metrics aligned to the 17 SP 800-53 control families +3. Assign monitoring frequencies: monthly (high-risk controls), quarterly (standard), annual (low-change controls) +4. Define reporting: automated dashboards, monthly security posture briefs to AO, annual reviews +5. Define triggers for reauthorisation or escalation +6. Document in a Continuous Monitoring Strategy document + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +- `references/rmf-steps-tasks.md` — All RMF steps with complete task tables, inputs, outputs, and role assignments +- `references/authorization-package.md` — Complete authorization package guidance, SSP template, SAR structure, POA&M format, and ATO decision criteria +- `references/roles-and-responsibilities.md` — All RMF roles with detailed responsibilities, appointment requirements, and organisational relationships + +**When to load:** +- Working through an RMF step → load `references/rmf-steps-tasks.md` +- Building or reviewing an authorization package → load `references/authorization-package.md` +- Clarifying roles or assigning responsibilities → load `references/roles-and-responsibilities.md` + +--- + +## Disclaimer + +This skill provides guidance based on NIST SP 800-37 Rev 2 (NIST, December 2018), a freely available public publication. This skill does not constitute legal, audit, or professional compliance advice. Federal agencies are bound by FISMA and agency-specific policies that may impose additional requirements beyond this publication. Organisations should engage qualified FISMA/RMF specialists to validate their authorisation approach for high-impact systems. diff --git a/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/authorization-package.md b/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/authorization-package.md new file mode 100644 index 0000000..2f3a0fb --- /dev/null +++ b/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/authorization-package.md @@ -0,0 +1,187 @@ +# NIST SP 800-37 Rev 2 — Authorization Package, SSP, SAR, and POA&M + +Source: NIST Special Publication 800-37 Rev 2, December 2018 + +--- + +## Authorization Package Overview + +The **authorization package** is the collection of documents presented to the Authorising Official (AO) to support an ATO decision. Per SP 800-37 Rev 2, Task R-1, the package must include: + +| Required Document | Owner | Description | +|------------------|-------|-------------| +| System Security Plan (SSP) | SO / ISSO | Complete system description, boundary, categorisation, environment, interconnections, and all control implementation narratives | +| Security Assessment Report (SAR) | SCA | Findings from independent assessment of all selected controls | +| Plan of Action and Milestones (POA&M) | ISSO / SO | All open weaknesses with remediation plans and milestones | +| Executive Summary | ISSO | Brief risk posture summary for AO decision-making | + +**Optional/conditional documents:** +| Document | When Required | +|----------|--------------| +| Privacy Plan | When system processes PII or is subject to the Privacy Act | +| Privacy Impact Assessment (PIA) | When system processes PII (E-Government Act requirement) | +| Supply Chain Risk Management Plan | When system acquisition involves significant supply chain risk | +| Risk Assessment Report | When conducted as a separate artefact | +| Interconnection Security Agreements (ISAs) | For each system interconnection | +| MOU/MOA | When the system depends on another organisation's resources | +| Contingency Plan | For systems with operational continuity requirements | +| Contingency Plan Test Results | For systems with tested continuity plans | + +--- + +## System Security Plan (SSP) — Document Template + +### Required SSP Sections (per SP 800-37 Rev 2 and NIST template) + +**Section 1 — System Identification** +| Field | Content | +|-------|---------| +| System Name | | +| System Identifier | | +| Responsible Organisation | | +| System Owner | Name, title, organisation, contact | +| ISSO | Name, title, organisation, contact | +| Authorising Official | Name, title, organisation | +| System Operational Status | Operational / Under Development / Major Modification | +| System Type | Major Application / General Support System / Minor Application | +| System Environment | Cloud (CSP, service model, deployment model) / On-premises / Hybrid | + +**Section 2 — System Description** +- System purpose and functions +- System architecture (narrative + diagrams) +- System boundary description +- Information types processed, stored, transmitted + +**Section 3 — System Categorisation** +``` +Security Category: SC = {Confidentiality: [LOW/MODERATE/HIGH], + Integrity: [LOW/MODERATE/HIGH], + Availability: [LOW/MODERATE/HIGH]} +Overall Impact Level: [LOW / MODERATE / HIGH] +Basis: [SP 800-60 information type analysis — summarise here] +``` + +**Section 4 — System Environment** +- Description of physical and technical environment +- Locations of system components +- Network topology and boundary diagrams +- System interconnections table + +| Connected System | Org | Direction | Data Types | ISA/MOU Status | +|-----------------|-----|-----------|-----------|----------------| + +**Section 5 — Users and Roles** +| Role | Description | Access Level | Training Required | +|------|-------------|-------------|------------------| + +**Section 6 — Security Control Implementation** +For each selected control: +``` +Control: [ID] [Name] +Baseline: [Low / Moderate / High] +Implementation Status: [Implemented / Planned / Inherited / Not Applicable] +Control Type: [System-Specific / Common (Inherited) / Hybrid] +Inherited From: [CCP name, if applicable] +Implementation Description: [How the control is implemented] +Responsible Party: [Organisation unit] +``` + +**Section 7 — Authorisation Date and Signature** +- ATO date +- ATO expiry date (or statement of ongoing authorisation) +- AO signature + +--- + +## Security Assessment Report (SAR) — Structure + +Per SP 800-53A and SP 800-37 Task A-4: + +**Section 1 — Executive Summary** +- System name, boundary, and categorisation +- Overall security posture summary +- Count of findings by severity (Critical / High / Moderate / Low / Informational) +- Key risks requiring AO attention + +**Section 2 — Assessment Scope and Methodology** +- Controls assessed +- Assessment period +- Assessment methods used (examine, interview, test) +- Depth and coverage +- Limitations and constraints + +**Section 3 — Assessment Findings** + +For each control assessed: +``` +Control ID: [e.g., AC-2] +Control Name: [Account Management] +Finding: [Satisfied / Other Than Satisfied / Not Applicable] +Method: [Examine / Interview / Test] +Artefacts: [List of evidence reviewed] +Deficiency: [Description of what is missing or not working correctly] +Severity: [Critical / High / Moderate / Low / Informational] +Risk Level: [Very High / High / Moderate / Low / Very Low] +Recommendation: [Specific remediation recommendation] +``` + +**Section 4 — Summary of Risks** +Table of all findings rated High or above with risk determination. + +--- + +## Plan of Action and Milestones (POA&M) — Format + +Per OMB Memorandum M-02-01 and NIST SP 800-37 Task A-5: + +| Field | Description | +|-------|-------------| +| POA&M ID | Unique sequential identifier (e.g., P-001) | +| System Name | System this applies to | +| Control ID | SP 800-53 control(s) this weakness relates to | +| Weakness Description | Clear description of the identified deficiency | +| Category | Technical / Operational / Management | +| Weakness Severity | Critical / High / Moderate / Low | +| Detection Source | SAR / Audit / Incident / Self-Identified / Pen Test | +| Date Identified | When the weakness was first identified | +| Scheduled Completion Date | Target date for full remediation | +| Milestones | Intermediate milestones with dates | +| Milestone # | Milestone description | Target date | +| Status | Open / In Progress / Partially Completed / Completed / Risk Accepted | +| Responsible POC | Name and contact for remediation owner | +| Resources Required | Budget, staff, tools | +| Comments | Additional context, dependencies, risk acceptance notes | + +### POA&M Management Requirements +- All findings from SAR with status "Other Than Satisfied" must appear in the POA&M +- POA&M must be reviewed and updated at minimum quarterly +- Critical/Very High risk findings require AO attention within 15 days +- All POA&M items must have realistic, achievable milestone dates +- Completed items retained for at least 3 years + +--- + +## Authorization Decision Documentation + +### ATO Memo Contents +1. System name, identifier, and boundary description +2. Security categorisation result +3. Summary of residual risks accepted +4. Open POA&M items and their risk status +5. Conditions placed on the authorisation (if any) +6. Authorization term (date of issue to expiry date, or statement of ongoing authorisation) +7. AO signature and date + +### Authorization Conditions +The AO may place conditions on authorization, such as: +- Specific POA&M items must be resolved within X days +- Specific monitoring metrics must be reported monthly +- No additional external connections without AO approval +- Penetration test required within 180 days + +### Risk Acceptance Statement +When accepting residual risk, the AO documents: +- The specific risk(s) being accepted +- Rationale for acceptance (operational necessity, compensating controls, low exploitability) +- Any compensating controls in place +- Review date when acceptance will be reconsidered diff --git a/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/rmf-steps-tasks.md b/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/rmf-steps-tasks.md new file mode 100644 index 0000000..d2acdcd --- /dev/null +++ b/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/rmf-steps-tasks.md @@ -0,0 +1,170 @@ +# NIST SP 800-37 Rev 2 — RMF Steps and Tasks Reference + +Source: NIST Special Publication 800-37 Rev 2, December 2018 +https://doi.org/10.6028/NIST.SP.800-37r2 + +--- + +## Step 0 — Prepare + +### Organisation-Level Tasks + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| P-1 | Risk Management Roles | Laws, EOs, directives, policies | Documented assignment of risk management roles | HO, SO, SAOP, CISO, AO | +| P-2 | Risk Management Strategy | Mission/business needs, risk tolerance | Risk management strategy; risk tolerance statements | HO, SAOP, CISO, AO | +| P-3 | Risk Assessment (Org) | Threat info, mission info, system inventory | Org-level risk assessment | CISO, Risk Executive | +| P-4 | Org-Wide Control Assignments | Risk assessment, enterprise architecture | Control allocation decisions | CISO, AO | +| P-5 | Mission/Business Functions | Stakeholder needs, mission statements | Mission/business function descriptions | SO, Mission/Business Owner | +| P-6 | Information Types | SP 800-60 Vol I & II | Information type taxonomy for the organisation | SO, SAOP | +| P-7 | Common Controls | Enterprise architecture, security plan templates | Common control register; CCP assignments | CISO, CCP | +| P-8 | Tailoring Guidance | SP 800-53, organisational policy | Org-specific tailoring policies | CISO, AO | +| P-9 | Enterprise Architecture | SP 800-160; security/privacy principles | Security and privacy architecture | SO, Enterprise Architect | +| P-10 | Requirements and Capabilities | Applicable laws, regulations, standards | Security and privacy requirements register | CISO, SAOP, Legal | + +### System-Level Tasks + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| P-11 | Stakeholders | Mission analysis | Stakeholder register | SO | +| P-12 | System-Level Roles | Org-level assignments | Documented system-level role assignments | SO, AO, CISO | +| P-13 | Assets | System description | Asset inventory | SO, ISSO | +| P-14 | System-Level Risk Assess. | P-3 output, system information | System-level risk assessment | ISSO, SCA | +| P-15 | Auth. Boundary | Architecture, data flows | System boundary documentation | SO, ISSO | +| P-16 | System Registration | Boundary, categorisation | System registered in agency ISCM tool | SO, ISSO | +| P-17 | Laws and Regulations | Applicable legal framework | Legal requirements register | ISSO, Legal | +| P-18 | Common Control Providers | CCP register | Inheritance register; signed agreements | ISSO, CCP | + +--- + +## Step 1 — Categorise + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| C-1 | System Description | SDLC documentation, contracts | Documented system description | SO | +| C-2 | Security Categorisation | FIPS 199, SP 800-60; system description | Security categorisation (SC = {C, I, A}) using FIPS 199; registered in ISCM | SO, ISSO, SAOP | + +### FIPS 199 Categorisation Steps +1. Identify information types using SP 800-60 Vol II categories +2. Assign provisional C, I, A values for each type +3. Adjust based on mission criticality or aggregation (document all adjustments) +4. Apply the high-water mark: SC = {max(C values), max(I values), max(A values)} +5. Assign overall system impact level = max(SC.C, SC.I, SC.A) +6. Map to baseline: LOW = Low baseline; MODERATE = Moderate baseline; HIGH = High baseline + +--- + +## Step 2 — Select + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| S-1 | Control Selection | SP 800-53 baselines; categorisation result | Initial control baseline selected | ISSO, SO | +| S-2 | Tailoring | Scoping guidance, risk assessment, overlays | Tailored control baseline; documented decisions | ISSO, SO, AO | +| S-3 | Control Assignment | Common control register | Control assignment (system/common/hybrid) per control | ISSO, CCP | +| S-4 | Monitoring Strategy | Org monitoring policy | Initial monitoring strategy integrated into SSP | ISSO | +| S-5 | SSP Approval | Completed SSP | Signed SSP | SO, AO | + +### SP 800-53 Rev 5 Control Families +| ID | Family | +|----|--------| +| AC | Access Control | +| AT | Awareness and Training | +| AU | Audit and Accountability | +| CA | Assessment, Authorization, and Monitoring | +| CM | Configuration Management | +| CP | Contingency Planning | +| IA | Identification and Authentication | +| IR | Incident Response | +| MA | Maintenance | +| MP | Media Protection | +| PE | Physical and Environmental Protection | +| PL | Planning | +| PM | Program Management | +| PS | Personnel Security | +| PT | Personally Identifiable Information Processing and Transparency | +| RA | Risk Assessment | +| SA | System and Services Acquisition | +| SC | System and Communications Protection | +| SI | System and Information Integrity | +| SR | Supply Chain Risk Management | + +--- + +## Step 3 — Implement + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| I-1 | Control Implementation | Approved SSP; design documentation | Implemented controls; updated SSP | SO, ISSO | +| I-2 | Update SSP | Implementation evidence | SSP implementation narratives completed | ISSO | + +--- + +## Step 4 — Assess + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| A-1 | Assessment Preparation | SSP; SP 800-53A | Security Assessment Plan (SAP) | SCA, ISSO | +| A-2 | Control Assessment | SAP; SP 800-53A assessment procedures | SAR with findings | SCA | +| A-3 | Remediations | SAR findings | Remediated weaknesses (where feasible); updated SSP | ISSO, SO | +| A-4 | Assessment Report | Post-remediation assessment | Final SAR | SCA | +| A-5 | POA&M | SAR findings | Plan of Action and Milestones | ISSO, SO | + +### Assessment Independence Requirements +- SCA must be **organisationally independent** of the ISSO/SO for HIGH-impact systems +- For MODERATE: independence is strongly encouraged +- For LOW: independence is preferred but an independent self-assessment may be acceptable with documented justification + +--- + +## Step 5 — Authorise + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| R-1 | Authorization Package | SSP, SAR, POA&M | Complete authorization package | ISSO, SO | +| R-2 | Risk Determination | Authorization package; risk tolerance | Risk determination (residual risk assessment) | AO, AODR | +| R-3 | Risk Response | Risk determination | Risk response decision (accept/mitigate/transfer/avoid) | AO | +| R-4 | Authorization Decision | Risk response | Signed ATO (or DATO); authorization memo | AO | +| R-5 | Authorization Reporting | Authorization decision | OMB/FISMA reporting; agency dashboards updated | CISO, AO | + +### ATO Decision Factors + +The AO considers: +1. Completeness and quality of the authorization package +2. Overall residual risk level vs. organisational risk tolerance +3. Acceptability of POA&M timelines and milestones for open findings +4. Whether critical/high findings are resolved or have accepted risk with justification +5. Legal and regulatory compliance status +6. Prior ATO history and operational need + +--- + +## Step 6 — Monitor + +| Task # | Task Name | Primary Inputs | Key Outputs | Roles | +|--------|-----------|---------------|-------------|-------| +| M-1 | Monitoring Strategy | Org ISCM strategy | System monitoring strategy | ISSO | +| M-2 | Configuration Management | Baseline configuration | Configuration baselines; change management records | ISSO, SO | +| M-3 | Ongoing Assessments | Monitoring strategy | Ongoing assessment results | SCA, ISSO | +| M-4 | Ongoing Risk Response | Assessment results | Updated risk response decisions | AO, AODR | +| M-5 | Authorisation Updates | Significant change notification; ongoing assessments | Updated authorization decision; reauthorisation if required | AO | +| M-6 | Security Posture Reporting | Monitoring data | Security posture reports to AO and CISO | ISSO | +| M-7 | System Disposal | Decommission plans | Media sanitisation records; disposal documentation | SO, ISSO | + +### Ongoing Authorisation Model +The **ongoing authorisation** model replaces fixed 3-year reauthorisation cycles with continuous monitoring. Requirements: +1. Real-time or near-real-time security posture data +2. Automated reporting dashboards accessible to AO +3. Defined triggers that escalate to AO review outside of normal reporting cycles +4. Monitoring program that provides sufficient coverage and confidence to support ongoing authorisation decisions + +--- + +## RMF and SDLC Integration + +| SDLC Phase | Relevant RMF Tasks | +|-----------|-------------------| +| Initiation | P-11 through P-18 (System-level Prepare) | +| Development/Acquisition | C-1, C-2, S-1 through S-5 | +| Implementation | I-1, I-2 | +| Operations/Maintenance | A-1 through A-5; R-1 through R-5; M-1 through M-6 | +| Disposal | M-7 | diff --git a/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/roles-and-responsibilities.md b/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/roles-and-responsibilities.md new file mode 100644 index 0000000..1f36ae9 --- /dev/null +++ b/plugins/nist-sp-800-37/skills/nist-sp-800-37/references/roles-and-responsibilities.md @@ -0,0 +1,205 @@ +# NIST SP 800-37 Rev 2 — Roles and Responsibilities + +Source: NIST Special Publication 800-37 Rev 2, Appendix D (December 2018) + +--- + +## Overview + +SP 800-37 Rev 2 defines a set of roles necessary to execute the RMF. Key principle: **accountability must be clearly assigned** and roles must be appointed in writing. Some roles may be combined in smaller organisations. + +--- + +## Authorising Official (AO) + +**Also known as**: Designated Approving Authority (DAA) in some agency contexts + +**Appointment**: Senior executive with authority, accountability, and mission ownership over the information system. Must have the authority to accept risk on behalf of the organisation. + +**Responsibilities**: +- Authorise (or deny authorisation to) information systems and common controls +- Accept organisational risk for systems under their purview +- Review and approve the System Security Plan +- Sign the Authorization Decision document +- Receive ongoing security posture reports +- Determine when significant changes require reauthorisation +- Ensure adequate funding for security and privacy + +**Key constraint**: The AO must have sufficient authority that their acceptance of residual risk is meaningful — they must be held accountable if that risk materialises. + +--- + +## Authorising Official Designated Representative (AODR) + +**Appointment**: Designated in writing by the AO. + +**Responsibilities**: +- Act on behalf of the AO for day-to-day RMF activities +- Coordinate review of the authorization package +- Brief the AO on security posture and risk determinations +- Cannot sign the final Authorization Decision (that remains with the AO) + +--- + +## Senior Agency Official for Privacy (SAOP) / Chief Privacy Officer (CPO) + +**Responsibilities**: +- Ensure integration of privacy requirements into the RMF +- Review and approve Privacy Plans +- Oversee Privacy Impact Assessments (PIAs) +- Ensure compliance with the Privacy Act, E-Government Act, and OMB guidance on privacy +- Designate a privacy point of contact for each system processing PII + +--- + +## Chief Information Security Officer (CISO) / Senior Agency Information Security Officer (SAISO) + +**Responsibilities**: +- Establish and maintain the organisation's information security program +- Develop and maintain organisational security policies and procedures +- Coordinate the RMF implementation across the organisation +- Report FISMA compliance status to OMB and Congress (for federal agencies) +- Oversee the continuous monitoring strategy +- Serve as the Risk Executive function (or delegate) + +--- + +## Risk Executive (Function) + +**Note**: This is a function, not necessarily a single named individual. Often fulfilled by the CISO, a risk governance board, or an enterprise risk committee. + +**Responsibilities**: +- Establish organisation-wide risk tolerance +- Ensure individual system risk decisions are consistent with organisation risk tolerance +- Facilitate information sharing across authorising officials +- Identify common threats that affect multiple systems +- Define the risk management strategy documented in the Prepare step + +--- + +## System Owner (SO) + +**Appointment**: Appointed by mission/business owner or head of organisation. + +**Responsibilities**: +- Responsible for the overall procurement, development, integration, modification, operation, maintenance, and disposal of the system +- Ensure the system is operated in accordance with the agreed security controls +- Develop and maintain the System Security Plan (with ISSO assistance) +- Ensure security requirements are included in contracts and service agreements +- Coordinate interconnection agreements (ISAs, MOUs) +- Ensure appropriate resources are allocated for security + +--- + +## Information System Security Officer (ISSO) + +**Responsibilities**: +- Day-to-day responsibility for the security of the information system +- Develop, implement, and maintain the System Security Plan +- Manage the POA&M and track remediation progress +- Coordinate security assessments with the SCA +- Respond to security incidents involving the system +- Conduct (or coordinate) ongoing monitoring activities +- Report security status to the AO and ISSM +- Ensure security training and awareness for system users + +--- + +## Information System Security Manager (ISSM) + +**Note**: Not all organisations have this role; it is typically used in organisations with many information systems. + +**Responsibilities**: +- Oversee the ISSO function across multiple systems +- Establish security policies and procedures for a portfolio of systems +- Escalation point for security issues requiring senior management attention +- Ensure consistent application of the RMF across the portfolio +- Support CISO in organisational security program management + +--- + +## Security Control Assessor (SCA) + +**Key requirement**: The SCA must be **organisationally independent** from the ISSO and SO for High-impact systems, and this independence is strongly encouraged for Moderate systems. Independence means the SCA should not assess controls that they themselves implemented. + +**Responsibilities**: +- Prepare the Security Assessment Plan (SAP) based on the SSP and SP 800-53A +- Conduct independent assessment of security and privacy controls +- Produce the Security Assessment Report (SAR) +- Identify control deficiencies, weaknesses, and associated risks +- Provide remediation recommendations +- Validate remediations (as applicable) + +**Assessor types**: +- **Internal**: Organisation's internal audit or assessment team (must be independent of SO/ISSO) +- **Third party (3PAO)**: Independent assessment organisation (required for FedRAMP; common for federal High-impact systems) + +--- + +## Common Control Provider (CCP) + +**Responsibilities**: +- Implement and maintain security controls that are provided to and inherited by multiple systems +- Maintain a **Common Control Plan** (analogous to an SSP for inherited controls) +- Ensure common controls are assessed per the RMF +- Provide authorisation documentation to systems inheriting controls +- Notify system owners of changes to common controls that may affect inherited systems + +**Examples of common controls**: +- Enterprise identity management (Active Directory, SSO, MFA) +- Physical security of data centres +- Enterprise SIEM and monitoring +- Patch management infrastructure +- Enterprise backup and recovery services +- Network perimeter firewall and IDS/IPS + +--- + +## Mission/Business Owner + +**Responsibilities**: +- Define mission/business objectives and requirements driving the information system +- Provide input on mission risk tolerance +- Participate in risk acceptance decisions +- Ensure system security budget is adequate for the mission risk level + +--- + +## System Administrator / Information System Administrator + +**Responsibilities**: +- Implement technical security controls +- Maintain system configuration in accordance with the approved baseline +- Execute change management procedures +- Support monitoring and assessment activities with technical evidence +- Participate in incident response for system-level events + +--- + +## Role Assignment Table Summary + +| Role | Who Assigns | Can Be Combined With | +|------|-------------|---------------------| +| AO | Head of organisation or delegating executive | Cannot be combined with ISSO, SCA, or SO | +| AODR | AO | May support CISO function | +| SAOP/CPO | Agency head | CISO in some smaller organisations | +| CISO/SAISO | Agency head | Risk Executive function | +| Risk Executive | Agency head | CISO function | +| System Owner | Mission owner / program office | May support ISSM in limited cases | +| ISSO | SO or CISO | May serve as ISSM for small portfolios | +| ISSM | CISO | May serve as ISSO for individual systems | +| SCA | AO or CISO | Must be independent of SO/ISSO for assessment scope | +| CCP | CISO or enterprise services team | May act as SO for common services | + +--- + +## Role Conflicts to Avoid + +SP 800-37 Rev 2 flags the following combinations as problematic (conflict of interest or lack of independence): + +| Combination | Issue | +|-------------|-------| +| ISSO + SCA for the same system | Assessor assessing their own work — lack of independence | +| SO + AO for the same system | Owner authorising their own system — no independent risk check | +| Developer + SCA | Developer assessing security of code they wrote | +| CCP + SCA for common controls | Provider assessing their own controls | diff --git a/plugins/nist-sp-800-39/.claude-plugin/plugin.json b/plugins/nist-sp-800-39/.claude-plugin/plugin.json new file mode 100644 index 0000000..e4246da --- /dev/null +++ b/plugins/nist-sp-800-39/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "nist-sp-800-39", + "description": "NIST SP 800-39 Enterprise Risk Management advisor — three-tier risk management hierarchy, risk framing, risk assessment, risk response, risk monitoring, organisational risk tolerance, and integration with the NIST RMF.", + "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": [ + "nist", + "nist-sp-800-39", + "enterprise-risk-management", + "erm", + "risk-framing", + "risk-governance", + "federal", + "fisma", + "cybersecurity", + "grc" + ] +} diff --git a/plugins/nist-sp-800-39/skills/nist-sp-800-39/SKILL.md b/plugins/nist-sp-800-39/skills/nist-sp-800-39/SKILL.md new file mode 100644 index 0000000..0802975 --- /dev/null +++ b/plugins/nist-sp-800-39/skills/nist-sp-800-39/SKILL.md @@ -0,0 +1,298 @@ +--- +name: nist-sp-800-39 +description: > + Expert NIST SP 800-39 enterprise risk management advisor. Use this skill whenever a user + asks about managing information security risk at the enterprise or organisational level + using NIST SP 800-39, including: the three-tier risk management hierarchy (organisation, + mission/business process, information system), risk framing, risk assessment at the + enterprise level, risk response strategies, risk monitoring, establishing organisational + risk tolerance, building an enterprise risk management programme, integrating risk across + tiers, or governance of information security risk. Also trigger for: "how do I build an + enterprise risk management programme?", "what is the NIST three-tier risk model?", + "how do I establish risk tolerance?", "what is risk framing?", "how does SP 800-39 relate + to the RMF?", or any question about enterprise-level information security governance and + risk management strategy. This skill covers the overarching framework; for system-level + risk assessments use the nist-sp-800-30 skill, and for the RMF lifecycle use nist-sp-800-37. +--- + +# NIST SP 800-39 — Managing Information Security Risk Skill + +You are an expert enterprise risk management advisor specialising in **NIST Special Publication 800-39: Managing Information Security Risk — Organization, Mission, and Information System View** (March 2011). You assist **senior executives, CISOs, risk executives, mission/business owners, and enterprise security architects** in building and operating an organisation-wide risk management programme aligned to NIST guidance. + +This skill is grounded in SP 800-39. All guidance on risk management organisation, processes, and integration is drawn directly from that publication. + +--- + +## How to Respond + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| ERM programme design | Structured programme design: governance, tiers, processes, communication | +| Risk framing | Risk framing document outline with all required components | +| Risk tolerance definition | Risk tolerance statement table with dimensions and descriptors | +| Risk response strategy | Table: Risk | Response Option | Rationale | Residual Risk | +| Tier mapping | Three-tier hierarchy diagram in table form with functions and artefacts | +| Integration guidance | Narrative mapping SP 800-39 to RMF steps and SP 800-30 tasks | +| General question | Clear, concise prose with SP 800-39 section citations | + +--- + +## SP 800-39 Overview + +### Purpose +SP 800-39 provides guidance for an **integrated, organisation-wide programme** for managing information security risk. It describes the organisational structure, processes, communication mechanisms, and context needed to govern information security risk across all levels. It is the highest-level publication in the NIST risk management hierarchy and provides the overarching framework within which SP 800-30 (risk assessments) and SP 800-37 (RMF for systems) operate. + +### Position in the NIST Risk Management Hierarchy + +| Publication | Level | Purpose | +|-------------|-------|---------| +| **SP 800-39** | Enterprise | Organisational risk management programme and governance | +| **SP 800-37** | System lifecycle | RMF for individual information systems | +| **SP 800-30** | Assessment | Conducting risk assessments for Tiers 1, 2, and 3 | +| **SP 800-137** | Monitoring | Continuous monitoring of security controls | + +--- + +## The Three-Tier Risk Management Hierarchy + +SP 800-39 organises risk management around three tiers that represent different organisational perspectives: + +### Tier 1 — Organisation + +**Focus**: Strategic; organisation-wide risk strategy, governance, and risk tolerance. + +| Function | Description | Outputs | +|----------|-------------|---------| +| Risk governance | Establish risk executive function; assign accountability | Risk Executive designation; risk governance structure | +| Risk strategy | Define organisation-wide risk management strategy | Risk management strategy document | +| Risk tolerance | Establish risk tolerance and appetite | Risk tolerance statements | +| Policy | Develop organisation-wide information security policies | Security policy framework | +| Priorities | Define mission-critical assets and functions | Mission-critical asset register | +| Investment | Align security investment with risk priorities | Security investment strategy | + +**Key outputs at Tier 1:** +- Organisation's risk management strategy +- Risk tolerance level (explicit risk acceptance threshold) +- Organisational security policies and directives +- Risk executive function (individual or committee) + +### Tier 2 — Mission/Business Process + +**Focus**: Operational; business process-level risk decisions that translate Tier 1 strategy into process-specific protections. + +| Function | Description | Outputs | +|----------|-------------|---------| +| Enterprise architecture | Define security architecture supporting business processes | Security architecture with residual risk assessment | +| Business process mapping | Identify which information systems support which processes | System-to-mission mapping | +| Risk context | Apply Tier 1 risk tolerance to business process decisions | Process-level risk context documents | +| Common controls | Identify common controls applicable enterprise-wide | Common control register | +| Supply chain | Establish supply chain risk governance | SCRM policy and strategy | + +**Key outputs at Tier 2:** +- Enterprise security architecture +- Business impact analysis linking systems to mission functions +- Tier 2 risk assessments for business processes +- Common control programme +- Supply chain risk management policy + +### Tier 3 — Information System + +**Focus**: Technical; individual information system risk management executed through the RMF. + +| Function | Description | Outputs | +|----------|-------------|---------| +| System categorisation | Categorise system per FIPS 199 | System security category | +| Control selection | Select, tailor, implement controls per SP 800-53 | SSP | +| Assessment | Assess control effectiveness per SP 800-53A | SAR, POA&M | +| Authorisation | Authorise system per SP 800-37 | ATO | +| Monitoring | Continuously monitor per SP 800-137 | Security posture reports | + +--- + +## The Four Risk Management Components + +SP 800-39 defines four interdependent components that together constitute the risk management process. These apply across all three tiers. + +### Component 1 — Frame Risk + +**Purpose**: Establish the context — the risk assumptions, constraints, tolerance, and priorities — that shape how risk assessments are conducted and responses are selected. + +**Framing outputs:** + +| Output | Description | +|--------|-------------| +| Risk assumptions | What is assumed about threats, vulnerabilities, consequences, and likelihood | +| Risk constraints | Legal, regulatory, mission, or resource constraints on risk response options | +| Risk tolerance | Explicit level of risk the organisation is willing to accept | +| Priorities and trade-offs | What the organisation prioritises when balancing cost, capability, and security | +| Risk management strategy | How risk management is conducted, resourced, and governed | +| Organisational risk context | Industry, sector, threat environment, and operational context | + +**Risk framing document structure:** +1. Organisational context and mission statement +2. Known threats and adversaries relevant to the organisation +3. Risk assumptions (basis for risk assessments) +4. Risk constraints (what cannot or will not be done) +5. Risk tolerance (explicit boundaries — what level is acceptable) +6. Risk priorities (what is protected first) +7. Governance and accountability + +### Component 2 — Assess Risk + +**Purpose**: Identify threats, vulnerabilities, and adverse impacts; determine likelihood and magnitude; produce actionable risk information for decision-makers. + +**Integration with SP 800-30:** +- SP 800-39 defines *what* risk assessments do; SP 800-30 defines *how* to conduct them +- Risk assessments at all three tiers feed back into the framing and response components + +**Scope of risk assessment by tier:** + +| Tier | Scope | Assessment Type | +|------|-------|----------------| +| Tier 1 | Organisation-wide strategic risks | Threat environment analysis; sector-level risk | +| Tier 2 | Mission/business process risks | Process criticality; systemic vulnerabilities; cross-system risk | +| Tier 3 | Information system technical risks | System-level threat/vulnerability/impact per SP 800-30 | + +**Risk aggregation:** +Risk information flows upward: Tier 3 assessments inform Tier 2 process risk; Tier 2 aggregates into Tier 1 strategic risk picture. The risk executive uses aggregated risk information to inform policy and investment. + +### Component 3 — Respond to Risk + +**Purpose**: Develop and implement risk response strategies consistent with the organisation's risk tolerance and the risk framing context. + +**Four risk response options:** + +| Option | Description | When to Use | +|--------|-------------|------------| +| **Accept** | Acknowledge the risk and take no additional action | Risk is within tolerance; cost of mitigation exceeds benefit; operational necessity | +| **Avoid** | Eliminate the risk by eliminating the activity or system | Risk is intolerable and the activity is not mission-critical | +| **Mitigate** | Reduce likelihood or impact through controls, processes, or architecture | Risk exceeds tolerance but activity is essential; controls exist that are cost-effective | +| **Transfer / Share** | Shift some or all of the risk to another party | Cyber insurance; outsourcing; shared responsibility (e.g., cloud provider CSP responsibility) | + +**Risk response prioritisation:** +When multiple risks require response, prioritise based on: +1. Risk level (Very High first) +2. Mission criticality of affected asset or function +3. Cost-effectiveness of available response options +4. Regulatory or legal obligations that mandate specific responses +5. Dependencies (one risk response may address multiple risks) + +**Risk response plan components:** +- Risk ID and description +- Selected response option (Accept/Avoid/Mitigate/Transfer) +- Rationale for selection +- Specific mitigating controls or actions (if mitigate/avoid) +- Expected residual risk after response +- Responsible party +- Timeline +- Cost estimate +- Monitoring metric to validate effectiveness + +### Component 4 — Monitor Risk + +**Purpose**: Verify that risk responses are effective; monitor changes in the risk environment; maintain the currency of risk information. + +**Monitoring activities:** + +| Activity | Description | Frequency | +|----------|-------------|-----------| +| Control effectiveness monitoring | Are implemented controls working as intended? | Continuous or periodic (per SP 800-137) | +| Risk environment monitoring | Have threat sources, vulnerabilities, or impacts changed? | Ongoing; triggered by threat intel | +| Compliance monitoring | Are policies and procedures being followed? | Regular (quarterly/annual) | +| Risk posture reporting | Report aggregated risk status to senior leaders | Periodic (monthly/quarterly) | +| Risk acceptance review | Are previously accepted risks still within tolerance? | Annual or triggered by change | +| Emerging risk identification | Identify new risks not previously considered | Continuous; organisational scanning | + +--- + +## Organisational Risk Management Governance + +### Risk Executive Function +The **risk executive (function)** is the enterprise-level governance body responsible for: +- Ensuring that risk-related considerations for individual systems are viewed across the full enterprise +- Developing organisation-wide risk management strategy +- Setting risk tolerance +- Facilitating information sharing among authorising officials +- Providing governance oversight of the risk management programme + +This function may be: +- An individual executive (Chief Risk Officer, CISO with enterprise risk scope) +- A governance committee (Risk Management Council, Information Security Steering Committee) +- An embedded function of the CISO/CIO office + +### Risk Communication Architecture + +Effective risk management requires structured communication across all three tiers: + +| Direction | What Flows | Mechanism | +|-----------|-----------|-----------| +| Tier 1 → Tier 2 → Tier 3 | Risk strategy, tolerance, priorities, policies | Published policy; briefings; risk guidance documents | +| Tier 3 → Tier 2 → Tier 1 | Risk assessment results, control deficiencies, incidents | Risk posture reports; aggregated dashboards; escalation | +| Horizontal (within tier) | Shared threat data, common vulnerabilities, lessons learned | Risk working groups; shared intelligence feeds | + +### Accountability and Responsibility Model + +| Level | Accountable Party | Responsible Parties | +|-------|------------------|---------------------| +| Tier 1 | Head of organisation / Board | Risk executive, CISO, legal, compliance | +| Tier 2 | Mission/business owners | Enterprise architects, process owners, CCP | +| Tier 3 | Authorising Officials | SO, ISSO, SCA, system administrators | + +--- + +## Core Workflows + +### 1. Building an Enterprise Risk Management Programme +When asked to design or assess an ERM programme: +1. Establish the risk executive function and governance structure +2. Develop the risk management strategy (framing document) +3. Define explicit risk tolerance across all three tiers +4. Establish common control programme +5. Define risk communication mechanisms (reporting cadence, escalation triggers) +6. Integrate with RMF for system-level risk management (SP 800-37) +7. Establish continuous monitoring strategy (SP 800-137) +8. Define risk posture review cycle (at minimum annual for Tier 1) + +### 2. Developing Risk Tolerance Statements +Structure risk tolerance in terms of: +- **Risk threshold**: The level above which risk must be reported to the next tier up +- **Acceptable residual risk**: What level is acceptable after controls are applied +- **Time-bound acceptance**: For accepted risks, when must acceptance be reviewed + +**Example table structure:** +| Risk Dimension | Risk Tolerance Statement | Threshold for Escalation | +|---------------|------------------------|--------------------------| +| Confidentiality of national security info | Zero tolerance for unauthorised disclosure | Immediately escalate to AO | +| Availability of mission-critical services | Tolerate up to 4-hour outage; >4 hours requires AO notification | >4 hour impact | +| Contractor supply chain risk | Medium risk acceptable with SCRM controls; high risk requires AO approval | High or Very High | + +### 3. Integrating Tier Risk Information +When helping to aggregate risk across tiers: +1. Collect Tier 3 risk assessment results (risk register outputs from SP 800-30) +2. Map Tier 3 risks to the mission/business processes they affect (Tier 2 view) +3. Identify systemic patterns: which processes have disproportionate risk concentration? +4. Assess Tier 2 cross-cutting risks not visible at Tier 3 (e.g., shared infrastructure, common credentials) +5. Produce a Tier 1 strategic risk view for executive decision-making + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +- `references/three-tier-model.md` — Detailed three-tier hierarchy with functions, artefacts, roles, and information flows +- `references/risk-framing.md` — Risk framing component guidance with document templates and example outputs +- `references/risk-response-monitoring.md` — Risk response options, prioritisation criteria, risk response plan format, and monitoring activities + +**When to load:** +- Understanding or explaining the tier model → load `references/three-tier-model.md` +- Developing a risk framing document or risk strategy → load `references/risk-framing.md` +- Selecting risk responses or designing monitoring → load `references/risk-response-monitoring.md` + +--- + +## Disclaimer + +This skill provides guidance based on NIST SP 800-39 (NIST, March 2011), a freely available public publication. Organisations should engage qualified enterprise risk management professionals to validate their ERM programme design, particularly for programmes with federal FISMA obligations or high-stakes mission functions. diff --git a/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/risk-framing.md b/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/risk-framing.md new file mode 100644 index 0000000..a22d0ff --- /dev/null +++ b/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/risk-framing.md @@ -0,0 +1,150 @@ +# NIST SP 800-39 — Risk Framing + +Source: NIST Special Publication 800-39, Section 3.1 (March 2011) + +--- + +## What is Risk Framing? + +Risk framing establishes the **context and environment** in which risk-based decisions are made across the organisation. Without explicit framing, risk assessments and responses may be conducted inconsistently, with different assumptions, different standards for what is acceptable, and different priorities. The risk frame is the output of the Prepare step in SP 800-37 at the organisation level. + +Risk framing is the responsibility of **Tier 1** (organisation-level) governance but informs all risk management activities at Tiers 2 and 3. + +--- + +## Components of the Risk Frame + +### 1. Risk Assumptions + +Risk assumptions define what the organisation accepts as true for purposes of risk management. They enable consistent analysis across the organisation. + +**Categories of risk assumptions:** + +| Category | Examples | +|----------|---------| +| Threat assumptions | Which threat actors are considered relevant; what capabilities are assumed | +| Vulnerability assumptions | Assumed baseline vulnerability level; assumed patching lag time | +| Impact assumptions | Which impact types are considered (only CIA, or also financial, reputational, safety) | +| Environmental assumptions | Data classification scheme assumed; interconnection types in scope | +| Temporal assumptions | Assessment period; how long data is considered current | + +**Documenting assumptions:** +Each assumption should be stated explicitly so that any user of a risk assessment can understand the basis on which the risk determination was made, and so that if an assumption is found to be incorrect the risk assessment can be updated accordingly. + +Example: +> "Threat assumption 1: Nation-state adversaries are assumed to have high capability and high motivation to target [Agency X] given its mission. This assumption is based on [threat intelligence source] current as of [date] and will be reviewed quarterly." + +--- + +### 2. Risk Constraints + +Risk constraints are factors that limit the organisation's ability to respond to risks. Constraints may be: + +| Constraint Type | Examples | +|----------------|---------| +| Legal / regulatory | Restrictions on data handling; FISMA compliance requirements; export controls | +| Policy | Internal policies restricting certain architectures or vendors | +| Mission / operational | Controls that would degrade mission performance are not acceptable | +| Budget | Financial limits on security investment | +| Technology | Legacy systems that cannot support modern controls | +| Workforce | Insufficient trained staff to implement certain controls | +| Contractual | Existing contracts restricting changes to systems or data handling | + +**Documenting constraints:** +Constraints must be documented so that risk responses do not propose actions that are not feasible. A risk response that violates a constraint is not a valid option. + +--- + +### 3. Risk Tolerance + +Risk tolerance is the **explicit level of risk that the organisation is willing to accept**. It defines the threshold between risks that are acceptable and risks that require response. + +**Dimensions of risk tolerance:** + +| Dimension | Description | Example Statement | +|-----------|-------------|-------------------| +| Overall level | Maximum overall risk level acceptable | "Very High risk is never acceptable. High risk requires AO-level acceptance and is accepted only for defined operational requirements." | +| Confidentiality | Risk to information confidentiality | "No risk of unauthorised disclosure of classified or controlled unclassified information (CUI) is acceptable without executive approval." | +| Integrity | Risk to information integrity | "Risks to critical data integrity in financial or safety-critical systems are tolerated only at Low level." | +| Availability | Risk to system availability | "Downtime risk for Tier 1 mission-critical systems must be maintained at Low or below." | +| Privacy | Risk to personal information | "Any risk to PII beyond Low requires SAOP review." | +| Supply chain | Risk from suppliers | "Medium supply chain risk is tolerated with SCRM controls; High or Very High requires case-by-case AO approval." | +| Time | Duration of risk acceptance | "Accepted risks are reviewed annually or upon any significant change to the system or threat environment." | + +**Expressing risk tolerance numerically:** +Some organisations express tolerance using the 5-tiered scale from SP 800-30 (Very Low / Low / Moderate / High / Very High) with explicit thresholds for escalation and mandatory treatment. + +--- + +### 4. Risk Priorities and Trade-offs + +Risk priorities define what the organisation protects first when resources are constrained. + +**Priority considerations:** +- Mission-critical systems and information (those without which the mission fails) +- Regulatory and legal obligations (those that create legal liability if breached) +- High-concentration risks (single points of failure or aggregated sensitive data) +- Public trust and reputation (for public-facing agencies) +- Personnel safety (for systems controlling physical infrastructure or processes) + +**Trade-off acknowledgements:** +Risk framing should explicitly acknowledge trade-offs. For example: +- Cost vs. risk reduction: Investing $X in control Y reduces risk from High to Moderate — this is/is not within our security budget +- Mission performance vs. security: Encrypting field device communications adds latency — the mission impact is acceptable/not acceptable + +--- + +## Risk Framing Document Template + +### Document Control + +| Field | Value | +|-------|-------| +| Document Title | Organisation-Wide Risk Framing Document | +| Version | | +| Date | | +| Owner | Risk Executive / CISO | +| Review Cycle | Annual or upon significant change | +| Classification | | + +### Sections + +**Section 1 — Organisational Context** +- Organisation mission statement +- Key mission functions and services +- Regulatory and legislative environment +- Industry and sector context +- Critical information types and assets + +**Section 2 — Threat Environment** +- Applicable threat sources (adversarial, non-adversarial) +- Current threat intelligence summary +- Sector-specific threat actors and campaigns +- Historical incidents relevant to framing + +**Section 3 — Risk Assumptions** +Table: +| Assumption ID | Category | Assumption Statement | Basis | Review Date | +|--------------|----------|---------------------|-------|------------| + +**Section 4 — Risk Constraints** +Table: +| Constraint ID | Type | Constraint Description | Impact on Risk Response | Owner | +|--------------|------|----------------------|------------------------|-------| + +**Section 5 — Risk Tolerance** +Table: +| Dimension | Risk Tolerance Level | Escalation Threshold | Notes | +|-----------|---------------------|---------------------|-------| + +**Section 6 — Risk Priorities** +Numbered list of prioritised risk protection areas with rationale. + +**Section 7 — Risk Management Strategy** +- How risk assessments will be conducted (tiered; methodology; frequency) +- How risk responses are decided and by whom +- How risk information flows between tiers +- How the risk framing will be reviewed and updated + +**Section 8 — Approvals** +Signatures of: Head of Organisation (or delegate), Risk Executive, CISO, SAOP (if applicable) diff --git a/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/risk-response-monitoring.md b/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/risk-response-monitoring.md new file mode 100644 index 0000000..383cb95 --- /dev/null +++ b/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/risk-response-monitoring.md @@ -0,0 +1,220 @@ +# NIST SP 800-39 — Risk Response and Risk Monitoring + +Source: NIST Special Publication 800-39, Sections 3.3 and 3.4 (March 2011) + +--- + +## Risk Response + +### Overview + +Risk response involves identifying, evaluating, and implementing appropriate courses of action to address identified risks in a manner consistent with the organisation's risk framing (tolerance, assumptions, constraints, and priorities). Risk response decisions are made at all three tiers. + +--- + +### Risk Response Options + +SP 800-39 defines four risk response options: + +#### Accept + +The organisation acknowledges the risk but takes no additional action to address it. + +**When to use:** +- Risk level is within the organisation's stated risk tolerance +- Cost of mitigation exceeds the expected benefit +- No feasible mitigation exists (e.g., natural disaster risk to a fixed facility) +- Operational necessity requires accepting the risk temporarily + +**Documentation required:** +- Explicit written acceptance by the appropriate authority (AO for Tier 3; mission owner for Tier 2; Risk Executive for Tier 1) +- Rationale for acceptance +- Risk level accepted (to confirm it is within tolerance) +- Review date (when acceptance will be reconsidered) +- Any compensating conditions in place + +**Risk acceptance authority by tier:** + +| Tier | Risk Level | Accepting Authority | +|------|-----------|---------------------| +| Tier 3 | Low / Very Low | ISSO / SO | +| Tier 3 | Moderate | Authorising Official | +| Tier 3 | High / Very High | Authorising Official with Risk Executive notification | +| Tier 2 | Any | Mission/Business Owner with Risk Executive review | +| Tier 1 | Any | Risk Executive / Head of Organisation | + +--- + +#### Avoid + +The organisation eliminates the risk by discontinuing the activity, process, or capability that creates the risk. + +**When to use:** +- Risk level is unacceptable (intolerable) +- The activity creating the risk is not essential to the mission +- No effective mitigation exists and transfer is not feasible + +**Examples:** +- Shutting down a legacy system with critical unpatched vulnerabilities that cannot be patched or replaced quickly +- Deciding not to store certain categories of highly sensitive data +- Discontinuing use of a third-party service with unacceptable supply chain risk + +**Documentation required:** +- Decision and rationale +- Who made the decision +- Mission impact of avoidance +- Residual risk after avoidance + +--- + +#### Mitigate + +The organisation implements controls, changes processes, or modifies architecture to reduce the likelihood or magnitude of the risk. + +**When to use:** +- Risk exceeds tolerance but cannot be avoided +- Effective controls exist that are cost-proportionate to the risk +- Risk must be reduced to an acceptable residual level + +**Mitigation strategies at each tier:** + +| Tier | Mitigation Mechanisms | +|------|--------------------| +| Tier 1 | Policy changes; governance improvements; investment reallocation; supply chain controls | +| Tier 2 | Architecture changes; cross-system controls; business process redesign; shared service security improvements | +| Tier 3 | SP 800-53 controls (technical, operational, management); configuration hardening; network segmentation; encryption; monitoring | + +**Mitigation plan components:** +| Field | Description | +|-------|-------------| +| Mitigation action | Specific control or process change | +| Expected effect | How the mitigation changes likelihood or impact | +| Expected residual risk | Risk level after applying mitigation | +| Implementation timeline | Target completion date | +| Cost | Estimated resource requirement | +| Dependencies | What else must be in place for this mitigation to work | +| Responsible party | Who will implement and operationalise | +| Verification method | How effectiveness will be confirmed | + +--- + +#### Transfer / Share + +The organisation shifts some or all of the financial, operational, or reputational burden of the risk to a third party. + +**When to use:** +- Risk exceeds financial tolerance but can be substantially covered by insurance or contract +- Outsourcing a function to a provider who accepts responsibility for security outcomes +- Contractually assigning liability for data breaches to a vendor processing on the organisation's behalf + +**Common transfer mechanisms:** +- Cyber liability insurance +- Contract clauses with financial penalties for vendor breaches +- Cloud service provider shared responsibility model (where the CSP is contractually responsible for infrastructure security) +- Indemnification clauses + +**Important limitation:** +Transfer or sharing reduces financial impact but does not eliminate reputational, legal, or mission impact. Organisations remain accountable to regulators and the public even if a vendor bears financial liability. + +--- + +### Risk Response Plan Format + +| Field | Description | +|-------|-------------| +| Risk ID | Unique identifier (linked to risk register) | +| Risk Description | The identified risk | +| Risk Level | Current assessed level (Very Low to Very High) | +| Response Option | Accept / Avoid / Mitigate / Transfer | +| Rationale | Why this response was selected | +| Mitigation Actions | Specific actions if mitigate is selected | +| Transfer Mechanism | Insurance, contract, etc. if transfer selected | +| Acceptance Authority | Named individual with authority to accept (if accept) | +| Residual Risk | Expected risk level after response | +| Timeline | When the response will be implemented | +| Responsible Party | Who owns implementation | +| Resources Required | Staff, budget, technology | +| Success Metric | How effectiveness will be measured | + +--- + +## Risk Monitoring + +### Purpose + +Risk monitoring supports the other three risk management components by: +1. Verifying that risk responses are implemented correctly and operating as intended +2. Detecting changes in the risk environment (threat, vulnerability, impact) that may require re-assessment or revised responses +3. Maintaining currency of risk information so that decisions are based on accurate data +4. Supporting continuous authorisation decisions at Tier 3 + +--- + +### Monitoring Activities + +#### Control Effectiveness Monitoring + +Verifies that implemented mitigating controls continue to operate effectively. + +| Activity | Description | Frequency | +|----------|-------------|-----------| +| Security control assessment | Formal assessment of controls per SP 800-53A | Annual or per SAP schedule | +| Automated tool scanning | Vulnerability scanners, configuration compliance tools | Continuous / weekly | +| SIEM monitoring | Real-time monitoring of security events | Continuous | +| Penetration testing | Adversarial testing of controls | Annual or more frequently for high-impact systems | +| Control metrics collection | Tracking key performance indicators (patching rates, open findings, training completion) | Monthly / quarterly | + +#### Risk Environment Monitoring + +Detects changes in the environment that may affect risk levels even if controls have not changed. + +| Activity | Description | Sources | +|----------|-------------|---------| +| Threat intelligence | Track emerging threats relevant to the organisation | CISA advisories; sector ISACs; NIST NVD; open-source intelligence | +| Vulnerability monitoring | Track new CVEs affecting in-use technologies | NIST NVD; vendor advisories; CISA KEV | +| Incident monitoring | Monitor for security incidents at peers or in the sector | ISAC reporting; media; government bulletins | +| Regulatory monitoring | Track changes in applicable law and regulation | Federal Register; OMB memos; agency policy updates | + +#### Risk Acceptance Review + +Periodically re-examines previously accepted risks to confirm they remain within tolerance. + +| Trigger | Action | +|---------|--------| +| Annual review cycle | All previously accepted risks reviewed | +| Significant system change | Accepted risks for the affected system reviewed | +| Significant threat change | Accepted risks with that threat source reviewed | +| Security incident | Accepted risks in the same category reviewed | +| Policy change | Accepted risks that relied on the prior policy reviewed | + +--- + +### Risk Posture Reporting + +Risk posture reports communicate the current state of risk across the organisation to leadership. Reporting must flow up through the tier structure. + +**Tier 3 to Tier 2 reporting (system-level):** +- Monthly or quarterly (defined in monitoring strategy) +- Content: ATO status; POA&M status; high/critical finding count; recent incidents; control failure notifications + +**Tier 2 to Tier 1 reporting (business process level):** +- Quarterly (minimum) +- Content: Aggregated risk by mission function; cross-system risks; supply chain risk status; emerging risks + +**Tier 1 executive reporting:** +- FISMA annual report to OMB (for federal agencies) +- Executive dashboard (automated where possible) +- Risk posture summary for Head of Organisation / Board +- Event-driven escalation for Very High risk discoveries + +### Monitoring Triggers for Immediate Escalation + +The following events must be immediately escalated rather than waiting for the regular reporting cycle: + +| Trigger | Required Response | +|---------|-----------------| +| Discovery of a Very High risk | Immediate notification to AO and Risk Executive | +| Active exploitation of a known vulnerability in the organisation's systems | Incident response activation + AO notification | +| Significant compromise of a common control | All inheriting systems assessed for impact | +| Discovery that an accepted risk has materially increased | Risk acceptance re-evaluated by appropriate authority | +| Critical change to the threat environment (e.g., new APT campaign targeting the sector) | Risk framing review triggered; risk assessments updated | diff --git a/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/three-tier-model.md b/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/three-tier-model.md new file mode 100644 index 0000000..3a52869 --- /dev/null +++ b/plugins/nist-sp-800-39/skills/nist-sp-800-39/references/three-tier-model.md @@ -0,0 +1,155 @@ +# NIST SP 800-39 — Three-Tier Risk Management Model + +Source: NIST Special Publication 800-39, March 2011 +https://doi.org/10.6028/NIST.SP.800-39 + +--- + +## Overview + +NIST SP 800-39 organises information security risk management into a **three-tier hierarchy** representing the organisational, mission/business, and information system perspectives. Risk management activities flow both downward (strategy and direction) and upward (risk information and reporting). + +--- + +## Tier 1 — Organisation View + +### Purpose +Establish the governance, strategy, and culture for organisation-wide information security risk management. All decisions at Tiers 2 and 3 occur within the context and boundaries established at Tier 1. + +### Primary Functions + +| Function | Description | Key Artefact | +|----------|-------------|-------------| +| Risk governance | Establish accountable leadership and governance structure for risk management | Risk governance charter; risk executive designation | +| Risk strategy | Develop and maintain the organisation's risk management strategy | Risk management strategy document | +| Risk tolerance | Establish explicit risk tolerance and risk appetite | Risk tolerance statement | +| Security policy | Develop and maintain organisation-wide security policies | Information security policy framework | +| Investment alignment | Ensure security investment is proportional to risk | Security investment portfolio | +| Threat awareness | Maintain awareness of the organisation-wide threat environment | Threat assessment (organisation level) | + +### Tier 1 Artefacts + +| Artefact | Description | +|----------|-------------| +| Risk Executive Function | Governance body (individual or committee) accountable for enterprise risk management | +| Risk Management Strategy | Document defining how risk management is conducted across the organisation | +| Risk Tolerance Statement | Explicit statements of acceptable and unacceptable risk levels by type and dimension | +| Information Security Policy | Top-level security policy signed by organisational head | +| Mission-Critical Asset Register | Identifies the organisation's most critical information, systems, and functions | +| Organisational Risk Framing Document | Defines all context for how risk assessments and responses are conducted | + +### Tier 1 Roles + +| Role | Responsibility | +|------|---------------| +| Head of Organisation / Board | Ultimate accountability for risk acceptance; approves risk strategy | +| Risk Executive (Function) | Day-to-day governance of the enterprise risk programme | +| CISO / Senior Agency Information Security Officer (SAISO) | Executes security programme; reports risk status to leadership | +| Senior Agency Official for Privacy (SAOP) | Integrates privacy risk into enterprise risk | +| Legal / General Counsel | Advises on legal risk, privacy law, and regulatory obligations | + +--- + +## Tier 2 — Mission/Business Process View + +### Purpose +Translate Tier 1 risk strategy and tolerance into specific risk decisions for mission and business processes. Identify which information systems and capabilities are critical to mission success and ensure proportionate protection. + +### Primary Functions + +| Function | Description | Key Artefact | +|----------|-------------|-------------| +| Enterprise architecture | Define security and privacy architecture supporting all business processes | Security architecture baseline | +| Business process mapping | Map information systems to mission/business processes to understand operational dependencies | System-to-mission dependency map | +| Risk context | Apply Tier 1 risk tolerance to specific business process risk decisions | Process-level risk context documents | +| Common controls | Identify and implement controls applicable across multiple systems | Common control register and CCP assignment | +| Supply chain governance | Establish governance for acquisition risk and vendor/supplier risk management | SCRM policy; supplier risk assessment | +| Business continuity | Ensure critical processes can continue under adverse conditions | BIA; continuity plans | + +### Tier 2 Artefacts + +| Artefact | Description | +|----------|-------------| +| Enterprise Security Architecture | Logical and physical architecture showing security zones, data flows, and control coverage | +| System-to-Mission Mapping | Table linking each information system to the mission functions it supports | +| Business Impact Analysis (BIA) | Assessment of the impact to mission if each system or process is unavailable or compromised | +| Common Control Register | List of all common controls provided enterprise-wide with their providers | +| Supply Chain Risk Management Policy | Policy governing vendor selection, contract requirements, and supplier monitoring | +| Tier 2 Risk Assessment | Risk assessment covering mission/business processes, cross-system dependencies, and systemic risks | + +### Tier 2 Roles + +| Role | Responsibility | +|------|---------------| +| Mission/Business Owner | Accountable for mission outcomes; defines process requirements and risk priorities | +| Enterprise Architect | Designs and maintains security architecture | +| Common Control Provider (CCP) | Implements and maintains common/inherited controls | +| Supply Chain Risk Manager | Manages third-party and supplier risk | +| Business Continuity Manager | Plans and tests operational continuity | + +--- + +## Tier 3 — Information System View + +### Purpose +Execute system-level risk management through the NIST Risk Management Framework (SP 800-37). All Tier 3 activity occurs within the context, boundaries, and constraints established by Tiers 1 and 2. + +### Primary Functions + +| Function | RMF Step | Key Artefact | +|----------|----------|-------------| +| System categorisation | Categorise (Step 1) | Security category per FIPS 199 | +| Control selection and tailoring | Select (Step 2) | Tailored SSP control list | +| Control implementation | Implement (Step 3) | SSP implementation narratives | +| Control assessment | Assess (Step 4) | SAR, POA&M | +| Authorisation | Authorise (Step 5) | ATO | +| Continuous monitoring | Monitor (Step 6) | Security posture reports | + +### Tier 3 Artefacts + +| Artefact | Description | +|----------|-------------| +| System Security Plan (SSP) | Complete system description, boundary, and control implementation | +| Security Assessment Report (SAR) | Findings from independent control assessment | +| Plan of Action and Milestones (POA&M) | Open weaknesses with remediation plans | +| Security Categorisation Document | FIPS 199 impact determination | +| Authorisation to Operate (ATO) | Signed decision accepting residual risk | +| Security Posture Report | Ongoing monitoring output | + +--- + +## Information Flows Between Tiers + +### Top-Down (Direction and Context) +| From | To | What Flows | +|------|----|-----------| +| Tier 1 | Tier 2 | Risk management strategy; policy; risk tolerance; priorities | +| Tier 1 | Tier 3 | Enterprise-wide policies; minimum control baselines; risk framing context | +| Tier 2 | Tier 3 | Process-specific risk context; common control inheritance; architecture requirements | + +### Bottom-Up (Risk Information) +| From | To | What Flows | +|------|----|-----------| +| Tier 3 | Tier 2 | System risk assessment results; control assessment findings; ATO status; incidents | +| Tier 3 | Tier 1 | Aggregated risk posture; POA&M status; security metrics | +| Tier 2 | Tier 1 | Business process risk assessments; systemic risk patterns; supply chain risks | + +### Horizontal (Within-Tier Sharing) +| Within | What Is Shared | +|--------|---------------| +| Tier 1 | Organisation-wide threat intelligence; policy decisions | +| Tier 2 | Common vulnerabilities shared across processes; architecture standards | +| Tier 3 | Known vulnerabilities across similar systems; common control deficiencies | + +--- + +## Relationship Between SP 800-39, SP 800-37, and SP 800-30 + +| Aspect | SP 800-39 | SP 800-37 | SP 800-30 | +|--------|-----------|-----------|-----------| +| Scope | Enterprise (all tiers) | System lifecycle (Tier 3) | Risk assessment (all tiers) | +| Focus | Governance, strategy, and programme | RMF lifecycle steps | Assessment process and methodology | +| Risk framing | Defined here | Inputs consumed from here | Frames the assessment context | +| Risk assessment | Directed from here | Step 1 (categorise), Step 4 (assess) inform | How to conduct the assessment | +| Risk response | Defined here at enterprise level | Authorisation step accepts/mitigates | Informs response selection | +| Risk monitoring | Directed from here | Step 6 (monitor) | Updates risk registers | diff --git a/plugins/nist-sp-800-53a/.claude-plugin/plugin.json b/plugins/nist-sp-800-53a/.claude-plugin/plugin.json new file mode 100644 index 0000000..bc849cc --- /dev/null +++ b/plugins/nist-sp-800-53a/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "nist-sp-800-53a", + "description": "NIST SP 800-53A Rev 5 Control Assessment advisor — assessment procedures, assessment methods (examine, interview, test), depth and coverage, Security Assessment Plan (SAP), Security Assessment Report (SAR), finding severity, and integration with the RMF Assess step.", + "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": [ + "nist", + "nist-sp-800-53a", + "control-assessment", + "security-assessment", + "sap", + "sar", + "examine-interview-test", + "federal", + "fisma", + "grc" + ] +} diff --git a/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/SKILL.md b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/SKILL.md new file mode 100644 index 0000000..2dfe439 --- /dev/null +++ b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/SKILL.md @@ -0,0 +1,360 @@ +--- +name: nist-sp-800-53a +description: > + Expert NIST SP 800-53A Rev 5 security and privacy control assessment advisor. Use this + skill whenever a user asks about assessing security or privacy controls, including: + assessment procedures, assessment methods (examine, interview, test), depth and coverage + parameters, Security Assessment Plans (SAP), Security Assessment Reports (SAR), finding + classification, determination values (Satisfied, Other Than Satisfied, Not Applicable), + assessor independence, assessment objectives, assessment boundaries, RMF Assess step + (Step 4), control-family-specific assessment guidance, or building an internal audit + or third-party assessment programme for federal information systems. Also trigger for: + "how do I assess AC-2?", "what is an assessment objective?", "what is the difference + between examine, interview, and test?", "how do I write a SAP?", "how do I determine + if a control is satisfied?", or any question about evaluating security control effectiveness. +--- + +# NIST SP 800-53A Rev 5 — Security and Privacy Control Assessment Skill + +You are an expert security control assessor and assessment programme advisor specialising in **NIST Special Publication 800-53A Revision 5: Assessing Security and Privacy Controls in Information Systems and Organizations** (January 2022). You assist **Security Control Assessors (SCAs), ISSOs, authorising officials, and audit teams** in planning, conducting, and documenting assessments of SP 800-53 Rev 5 security and privacy controls. + +This skill is grounded in SP 800-53A Rev 5. All assessment procedures, methods, objectives, and structures are from that publication. + +--- + +## How to Respond + +Match your output to the task type: + +| Task | Output Format | +|------|--------------| +| Assessment procedure for a specific control | Structured: Control ID | Assessment Objective | Method | Objects | Expected Evidence | +| SAP development | Structured SAP outline with all required components | +| SAR structure | SAR outline with findings template | +| Finding classification | Narrative explanation with determination value | +| Depth/coverage guidance | Table: Level | Definition | When to Use | +| Assessment planning | Scoping questions followed by tailored assessment plan | +| General question | Clear, concise prose with SP 800-53A section citations | + +--- + +## SP 800-53A Rev 5 Overview + +### Purpose and Scope +SP 800-53A Rev 5 provides guidance for building effective security and privacy assessment plans, conducting assessments, and producing consistent, accurate assessment results. It supports **RMF Step 4 (Assess)** and the ongoing control effectiveness evaluation required in **RMF Step 6 (Monitor)**. + +Assessment results feed: +- Authorization to Operate (ATO) decisions (SP 800-37) +- Plan of Action and Milestones (POA&M) development +- Continuous monitoring security posture reports +- Risk determinations for the risk assessment (SP 800-30) + +### Relationship to SP 800-53 Rev 5 +- **SP 800-53 Rev 5**: Defines the controls (what needs to be done) +- **SP 800-53A Rev 5**: Defines how to determine whether those controls are implemented and effective (how to assess them) + +Every SP 800-53 Rev 5 control has corresponding assessment procedures in SP 800-53A. The assessment procedures define: +1. **Assessment objectives**: Specific determinations that must be made +2. **Assessment methods**: Examine, Interview, or Test +3. **Assessment objects**: What specifically is examined, interviewed, or tested + +--- + +## Assessment Methods + +SP 800-53A defines three assessment methods. All three may be used for a single control. + +### Examine + +**Definition**: Review, inspect, observe, study, or analyse one or more assessment objects to facilitate understanding, achieve clarification, or obtain evidence. + +**Objects examined:** +- Policies and procedures +- Plans, processes, and procedures +- System documentation (SSP, architecture diagrams, data flow diagrams) +- Configuration settings and documentation +- Logs and records +- Security architecture artefacts + +**Example — AC-2 Examine:** +- Information security policy +- Access control policy and procedures +- SSP (AC-2 implementation narrative) +- Account management records (lists of authorised accounts, recent account reviews) +- Automated account management tool configuration + +### Interview + +**Definition**: Conduct discussions with individuals or groups within an organisation to facilitate understanding, achieve clarification, or obtain evidence. + +**Objects interviewed:** +- Personnel with information security responsibilities (ISSO, system administrators) +- Information system owners +- Personnel who manage or operate the assessed control + +**Example — AC-2 Interview:** +- ISSO or ISSM: How are account requests, approvals, and terminations managed? +- System administrator: How are privileged accounts created and reviewed? +- Information system owner: How frequently are account access reviews conducted? + +### Test + +**Definition**: Exercise one or more assessment objects under specified conditions to compare actual behaviour with expected or required behaviour, with results that are observed and recorded. + +**Objects tested:** +- Automated mechanisms, tools, or devices +- System components +- Activities, processes, and procedures (where testing means executing them under observation) + +**Example — AC-2 Test:** +- Execute an account creation request for a test user and verify the workflow matches the documented procedure +- Verify that a terminated test account is disabled within the required timeframe +- Review output of automated account management tool showing current account status + +--- + +## Assessment Depth and Coverage + +### Depth + +Assessment depth determines the **rigour and level of detail** of each assessment procedure. + +| Depth Level | Definition | When to Use | +|------------|------------|------------| +| **Basic** | Minimum depth: review high-level documentation; limited interviews to confirm general approach; test only primary functions under normal conditions | Initial or very short assessment; LOW-impact systems; resource-constrained reviews | +| **Focused** | More thorough: review detailed documentation; broader interviews including operational staff; test multiple paths/conditions | Standard depth for MODERATE-impact systems; typical initial ATO assessment | +| **Comprehensive** | Maximum depth: systematic review of all relevant documentation; broad interviews with multiple stakeholders; extensive testing of many paths, conditions, edge cases, and failure modes | HIGH-impact systems; sensitive or critical systems; systems with known problems; re-assessments following significant incidents | + +### Coverage + +Assessment coverage determines the **breadth of the assessment** — how many instances, components, or configurations within a category are assessed. + +| Coverage Level | Definition | When to Use | +|---------------|------------|------------| +| **Representative** | A statistically or informationally representative sample of assessment objects | Large systems with many similar instances; initial assessments | +| **Focused** | A subset selected based on known risk factors or importance | When specific areas are higher risk | +| **Comprehensive** | Every instance of the assessment object is assessed | HIGH-impact systems; targeted re-assessment; post-incident | + +### Selecting Depth and Coverage + +| System Categorisation | Recommended Depth | Recommended Coverage | +|----------------------|-------------------|---------------------| +| LOW | Basic | Representative | +| MODERATE | Focused | Focused or Representative | +| HIGH | Comprehensive | Comprehensive | +| National Security / Critical Infra | Comprehensive | Comprehensive | + +--- + +## Assessment Objectives and Determinations + +### Assessment Objectives + +Each SP 800-53 control has one or more **assessment objectives** — specific determinations that the assessor must make to conclude whether the control is satisfied. Assessment objectives are formulated as: + +> "Determine if the system, component, or mechanism [specific action or property]." + +Example for AC-2(a): +> "Determine if: (a) the types of accounts allowed and/or specifically disallowed for use within the system are identified and specified." + +### Determination Values + +For each assessment objective, the assessor records one determination: + +| Value | Meaning | +|-------|---------| +| **Satisfied** | The assessment objective is met — the control or portion of the control is fully implemented | +| **Other Than Satisfied** | The assessment objective is not met — the control or portion is not implemented, partially implemented, or not operating as intended | +| **Not Applicable** | The assessment objective does not apply to the system given its documented scope (must be justified) | + +**Overall control determination:** +If all objectives are Satisfied → control is Satisfied. +If any objective is Other Than Satisfied → control is Other Than Satisfied. +If objectives are mixed Satisfied/NA → may be Satisfied if NA is justified. + +### Finding Severity Classification + +When a control is Other Than Satisfied, the finding is classified by severity: + +| Severity | Definition | Example | +|---------|-----------|---------| +| **Critical** | Immediate, severe risk to the system; active exploitation possible; fundamental control absent | No authentication on an internet-facing system; unauthenticated admin access | +| **High** | Significant risk; substantial weaknesses that could be directly exploited | MFA not enforced for privileged accounts; audit logging disabled | +| **Moderate** | Moderate risk; weakness requires additional steps to exploit or has compensating controls reducing impact | Incomplete account review process; audit records not reviewed regularly | +| **Low** | Limited risk; minor deficiency with minimal security impact | Account naming convention not followed; minor documentation gap | +| **Informational** | No direct risk; observation or recommendation for improvement | Best practice not followed; process improvement possible | + +--- + +## Security Assessment Plan (SAP) + +### SAP Purpose +The SAP defines what will be assessed, how it will be assessed, and what constitutes a satisfactory result. It is the contract between the assessor and the system owner for conducting the assessment. + +### SAP Required Sections + +**Section 1 — System Identification** +- System name, identifier, and boundary +- System security categorisation (impact level) +- Date assessment is planned and expected duration +- Names of the assessment team and their roles + +**Section 2 — Assessment Scope** +- List of controls to be assessed (typically all controls in the SSP) +- Any controls excluded from this assessment and justification +- System components within scope +- Interconnected systems (if any are in scope) + +**Section 3 — Assessment Team** +- Names, roles, and qualifications of each assessor +- Organisational independence statement +- Statement of conflict of interest review + +**Section 4 — Assessment Approach and Methods** +- Selected depth (Basic / Focused / Comprehensive) with justification +- Selected coverage (Representative / Focused / Comprehensive) with justification +- For each control family: methods to be used (Examine / Interview / Test) + +**Section 5 — Assessment Schedule and Logistics** +- Planned assessment activities timeline +- Required resources (access to systems, documentation, personnel) +- Points of contact for coordination +- Rules of engagement for system testing (to avoid disruption) + +**Section 6 — Reporting Requirements** +- Format of findings (how Other Than Satisfied findings are documented) +- Reporting recipients +- Timeline for SAR delivery +- Handling of sensitive findings + +**Section 7 — Approved By** +- System Owner signature +- Authorising Official (or AODR) review acknowledgement + +--- + +## Security Assessment Report (SAR) + +### SAR Purpose +The SAR documents the results of the assessment, identifying control deficiencies, their severity, associated risks, and recommendations for remediation. + +### SAR Required Sections + +**Section 1 — Executive Summary** +- System name, boundary, and impact level +- Assessment period +- Overall security posture assessment +- Finding summary by severity: Critical X | High X | Moderate X | Low X | Informational X +- Key risks requiring immediate AO attention + +**Section 2 — Assessment Scope and Methodology** +- Controls assessed +- Methods used (Examine / Interview / Test) +- Depth and coverage levels +- Limitations or constraints encountered + +**Section 3 — Assessment Findings** + +For each control assessed, document: + +``` +Control ID: [e.g., AC-2] +Control Name: [Account Management] +Baseline: [Low / Moderate / High] +Assessment Objective [a]: Satisfied / Other Than Satisfied / Not Applicable +Assessment Objective [b]: Satisfied / Other Than Satisfied / Not Applicable +[... all objectives listed] +Overall Determination: Satisfied / Other Than Satisfied / Not Applicable + +Finding (if Other Than Satisfied): + Severity: [Critical / High / Moderate / Low / Informational] + Description: [What specifically is not working or missing] + Evidence Reviewed: [Documents, interviews, tests conducted] + Risk Determination: [What risk this creates per SP 800-30 scale] + Recommendation: [Specific remediation recommended] +``` + +**Section 4 — Risk Summary** +Table of all Other Than Satisfied findings rated High or above with risk determination. + +**Section 5 — Assessor Attestation** +Signed by the assessment team lead; statement of independence; date. + +--- + +## Control-Family Assessment Guidance + +### Key Assessment Patterns by Control Family + +| Family | ID | Primary Assessment Method | Key Evidence | +|--------|----|--------------------------|-------------| +| Access Control | AC | Examine, Test | Account lists, access reviews, IAM tool configuration, SSP narratives | +| Awareness and Training | AT | Examine, Interview | Training records, completion rates, training content, role-based training evidence | +| Audit and Accountability | AU | Examine, Test | Log configurations, log samples, SIEM rules, audit review records | +| Assessment, Authorization, Monitoring | CA | Examine, Interview | SSP, SAR, POA&M, ATO memo, continuous monitoring strategy | +| Configuration Management | CM | Examine, Test | Baseline configurations, change records, CMDB, approved software lists, vulnerability scan results | +| Contingency Planning | CP | Examine, Interview, Test | BCP/DR plan, BIA, test results, backup verification | +| Identification and Authentication | IA | Examine, Test | Authentication mechanism configs, MFA evidence, password policy enforcement | +| Incident Response | IR | Examine, Interview, Test | IR plan, IR team records, tabletop exercise reports, incident log | +| Maintenance | MA | Examine, Interview | Maintenance logs, remote maintenance records, sanitisation records | +| Media Protection | MP | Examine, Interview | Media handling procedures, media sanitisation records, encryption at rest | +| Physical and Environmental | PE | Examine, Interview, Test | Physical access logs, visitor records, environmental monitoring data, badge access records | +| Planning | PL | Examine, Interview | SSP, privacy plan, rules of behaviour, central management plan | +| Program Management | PM | Examine, Interview | ISCM strategy, risk exec appointment, enterprise architecture | +| Personnel Security | PS | Examine, Interview | Background check records, onboarding/offboarding procedures, personnel agreements | +| PII Processing and Transparency | PT | Examine, Interview | PIA, privacy notice, consent records, PII inventory | +| Risk Assessment | RA | Examine, Interview | Risk assessment reports, vulnerability scan results, CVE remediation log | +| System and Services Acquisition | SA | Examine, Interview | Acquisition policies, contracts with security requirements, developer security testing | +| System and Communications Protection | SC | Examine, Test | Network diagrams, firewall rules, encryption configurations, TLS settings | +| System and Information Integrity | SI | Examine, Test | AV/EDR status, patch scan results, SIEM flaw remediation records | +| Supply Chain Risk Management | SR | Examine, Interview | SCRM policy, supplier risk assessments, provenance documentation | + +--- + +## Core Workflows + +### 1. Planning an Assessment +When helping to plan a security assessment: +1. Identify system impact level and scope of controls to assess +2. Determine assessor independence requirements +3. Select depth and coverage based on impact level +4. Develop the SAP with all required sections +5. Identify evidence types to collect per control family +6. Define rules of engagement for system testing + +### 2. Conducting a Specific Control Assessment +When asked to provide assessment guidance for a specific control (e.g., "how do I assess AC-2?"): +1. State the control title and number +2. List all assessment objectives from SP 800-53A +3. For each method (Examine/Interview/Test): specify exactly what objects to assess and what to look for +4. Describe what "Satisfied" looks like (expected evidence) +5. Describe common "Other Than Satisfied" findings and their typical severity + +### 3. Classifying a Finding +When a weakness is identified: +1. Map to the specific assessment objective(s) not met +2. Determine severity using the 5-level scale (Critical through Informational) +3. Perform a risk determination per SP 800-30 (what is the risk posed by this deficiency?) +4. Formulate a clear, actionable recommendation +5. Confirm whether a compensating control reduces the risk level + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +- `references/assessment-procedures.md` — Assessment procedure patterns for all 20 SP 800-53 control families with assessment objectives, methods, and evidence guidance +- `references/sap-sar-templates.md` — Full SAP and SAR document templates with field-level guidance and examples +- `references/finding-severity.md` — Finding severity classification criteria, risk mapping, and remediation prioritisation guidance + +**When to load:** +- Assessing a specific control or control family → load `references/assessment-procedures.md` +- Building a SAP or SAR → load `references/sap-sar-templates.md` +- Classifying a finding or determining remediation priority → load `references/finding-severity.md` + +--- + +## Disclaimer + +This skill provides guidance based on NIST SP 800-53A Rev 5 (NIST, January 2022), a freely available public publication. This skill does not constitute legal, audit, or professional compliance advice. Federal agencies are bound by FISMA and agency-specific policies. Specific assessment procedures are defined at the control level in SP 800-53A; this skill provides representative guidance and should be validated against the current published version. diff --git a/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/assessment-procedures.md b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/assessment-procedures.md new file mode 100644 index 0000000..f5272df --- /dev/null +++ b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/assessment-procedures.md @@ -0,0 +1,374 @@ +# Assessment Procedures Reference — NIST SP 800-53A Rev 5 + +This reference file provides assessment procedure guidance for all 20 SP 800-53 Rev 5 control families. For each family, the key assessment objectives, methods, evidence objects, and expected findings are described. + +Source: NIST SP 800-53A Rev 5, January 2022 + +--- + +## How to Use This Reference + +Each control family entry describes: +- **Assessment objectives**: What determination(s) must be made +- **Examine**: What documents and artefacts to review +- **Interview**: Which roles to speak with and what to ask +- **Test**: What mechanisms, processes, or activities to exercise +- **Satisfied evidence**: What makes a control Satisfied +- **Common OTS findings**: Frequent Other Than Satisfied patterns + +--- + +## AC — Access Control + +### Key Assessment Focus +Verify that access to the system is limited to authorised users, processes, and devices; that least privilege is enforced; and that accounts are managed through a defined lifecycle. + +### AC-1 Policy and Procedures +**Objectives**: Formal access control policy exists, covers required elements, is disseminated, reviewed, and updated per stated frequency. +**Examine**: Access control policy, procedures, revision history, distribution records +**Interview**: ISSO, system owner — how is the policy maintained and communicated? +**Satisfied if**: Current policy exists, reviewed within the defined period, distributed to all relevant personnel + +### AC-2 Account Management +**Objectives**: Account types defined; accounts created, enabled, modified, disabled, and removed per procedures; account reviews conducted; inactive accounts disabled; temporary/emergency accounts expire +**Examine**: Account management policy, SSP narrative, account listings (privileged and non-privileged), recent account review records, ticketing records for account requests +**Interview**: System administrator — account creation workflow; ISSO — frequency and evidence of account reviews +**Test**: Submit test account request and verify workflow; verify a terminated account is disabled/removed; check for accounts without recent logins + +### AC-3 Access Enforcement +**Objectives**: System enforces approved authorisations for access to system resources +**Examine**: Access control mechanism configuration (Active Directory, IAM tool, RBAC configs), SSP control implementation description +**Test**: Attempt to access a resource without authorisation (from a non-privileged test account); verify access is denied and logged + +### AC-6 Least Privilege +**Objectives**: Principle of least privilege employed; users given only the access required for their role; separation of duties enforced +**Examine**: Role definitions, privilege assignment matrix, privileged account justifications +**Test**: Review current privilege assignments against documented role requirements; check for accounts with privileges beyond documented role + +--- + +## AT — Awareness and Training + +### Key Assessment Focus +Verify that all users (including privileged users) receive security awareness training and that role-based training specific to security responsibilities is provided and documented. + +### AT-1 Policy and Procedures +**Examine**: Awareness and training policy, training procedures, revision history +**Interview**: Training coordinator — how is training tracked? + +### AT-2 Literacy Training and Awareness +**Objectives**: Security awareness training provided to all users before access and recurring per defined frequency; training covers required topics (phishing, social engineering, password security) +**Examine**: Training completion records (by user), training content, training completion reports, evidence of annual refresher +**Interview**: User personnel — have you completed security awareness training? ISSO — How is training completion enforced? +**Satisfied if**: 100% of current users have completed training within the last period; training content addresses required topics + +### AT-3 Role-Based Training +**Objectives**: Individuals with significant security responsibilities receive role-specific training before assigned duties and annually +**Examine**: Role-based training curriculum, completion records by role, training materials specific to each security-sensitive role +**Interview**: System administrator, ISSO — what role-specific security training have you completed? + +--- + +## AU — Audit and Accountability + +### Key Assessment Focus +Verify that the system generates audit records for required events, that records are protected and retained, and that they are reviewed for anomalies. + +### AU-2 Event Logging +**Objectives**: System generates audit records for organisationally defined events; events include required categories (logon/logoff, admin activity, object access, policy changes) +**Examine**: Audit event configuration (SIEM correlation rules, OS audit policy, application logging settings), SSP narrative +**Test**: Trigger an auditable event (e.g., failed logon, account change) and verify the record is generated with required fields + +### AU-3 Audit Record Content +**Objectives**: Audit records contain date/time, event type, subject identity, object, outcome, source address +**Examine**: Sample audit records from the SIEM or log management system +**Test**: Review 20+ sample log entries across different event types and verify all required fields are present in each + +### AU-9 Protection of Audit Information +**Objectives**: Audit records protected from unauthorised access, modification, and deletion; audit tools protected +**Examine**: ACLs on log repositories, SIEM access controls, log forwarding configuration +**Test**: Attempt to modify or delete audit records from a standard user account; verify the attempt is denied + +--- + +## CA — Assessment, Authorization, and Monitoring + +### Key Assessment Focus +Verify that the system has been formally assessed, authorised, is under continuous monitoring, and that the SSP and authorisation package are current. + +### CA-2 Control Assessments +**Objectives**: Periodic security assessments conducted by assessors with required independence; assessment results documented; deficiencies addressed +**Examine**: Most recent SAR, SAP, assessor qualifications and independence attestation, POA&M updating records showing deficiency remediation +**Interview**: ISSO — when was the last assessment? How are findings tracked? + +### CA-5 Plan of Action and Milestones +**Objectives**: POA&M developed for the system; POA&M documents deficiencies, resources, milestones; POA&M updated per defined frequency +**Examine**: Current POA&M, POA&M update history, evidence that closed items have been verified +**Satisfied if**: POA&M reflects current SAR findings; milestone dates are being met or have justified extensions + +### CA-7 Continuous Monitoring +**Objectives**: Continuous monitoring strategy defined; security controls monitored per defined frequency; security status reported to AO; ongoing authorisation maintained +**Examine**: ISCM strategy document, monitoring frequency table, automated monitoring tool reports, status reports to AO + +--- + +## CM — Configuration Management + +### Key Assessment Focus +Verify that the system has a documented and enforced baseline configuration, that changes go through a controlled process, and that only authorised software is installed. + +### CM-2 Baseline Configuration +**Objectives**: Baseline configuration for the system is established, documented, reviewed, and updated +**Examine**: Approved baseline configuration documents (per OS/application version), change records showing update of baseline after approved changes +**Interview**: System administrator — where is the baseline configuration documented? How is it maintained? + +### CM-3 Configuration Change Control +**Objectives**: All configuration changes go through an approved change control process including impact analysis, testing, and approval before implementation +**Examine**: Change management policy, sample change requests (approved and denied), change advisory board records, emergency change records +**Test**: Review 10 recent changes in the change management system and verify each has documented request, approval, and optionally rollback plan + +### CM-6 Configuration Settings +**Objectives**: Configuration settings for technology components implement the most restrictive settings consistent with operational requirements; settings are documented and enforced +**Examine**: Approved configuration settings (CIS Benchmarks, DISA STIGs, or equivalent), system scans against baseline, vulnerability scan results showing configuration compliance +**Test**: Run a configuration compliance scan (CIS benchmark or STIG check) and compare results to the approved baseline; document any deviations + +--- + +## CP — Contingency Planning + +### Key Assessment Focus +Verify that the organisation can recover from disruptions and that the contingency plan has been tested. + +### CP-2 Contingency Plan +**Objectives**: Contingency plan developed; covers all required elements (BIA, recovery objectives, roles and responsibilities, procedures); reviewed and updated per defined frequency +**Examine**: Contingency plan document, BIA, most recent plan review and update record +**Interview**: Contingency plan coordinator — when was the last plan review? How often are recovery objectives validated? + +### CP-9 System Backup +**Objectives**: System backup performed per defined frequency; backup copies stored at alternate location; backup integrity verified; restoration tested +**Examine**: Backup policy, backup job logs (confirming completion per schedule), offsite/cloud storage records, restoration test records +**Test**: Review backup job logs for the past 30 days and verify completion at required frequency; request evidence of a recent restoration test + +--- + +## IA — Identification and Authentication + +### Key Assessment Focus +Verify that all users are uniquely identified and authenticated using mechanisms meeting the required assurance level, including multi-factor authentication for privileged accounts. + +### IA-2 Identification and Authentication (Org Users) +**Objectives**: System uniquely identifies and authenticates all organisational users; MFA enforced for network access, privileged accounts, and non-privileged accounts per applicable baseline +**Examine**: Authentication mechanism configuration (MFA settings, LDAP/AD configuration), SSP IA narrative +**Test**: Verify MFA is enforced by attempting to access the system with only a password from a test privileged account; confirm MFA prompt appears + +### IA-5 Authenticator Management +**Objectives**: Organisation manages system authenticators; initial authenticator content meets requirements; administrative procedures for lost/compromised authenticators; password minimum/complexity/expiration enforced +**Examine**: Password policy configuration, evidence of secure initial distribution of credentials, authenticator recovery procedures +**Test**: Verify password minimum complexity and length enforcement via account settings; review recent password resets for proper procedure adherence + +--- + +## IR — Incident Response + +### Key Assessment Focus +Verify that the organisation has a tested incident response capability including detection, handling, and reporting. + +### IR-1 Policy and Procedures +**Examine**: Incident response policy, procedures, revision history + +### IR-4 Incident Handling +**Objectives**: Incident handling capability established covering preparation, detection, analysis, containment, eradication, and recovery; incidents tracked and documented; lessons learned incorporated +**Examine**: IR plan, incident tracking log (with real incidents), post-incident reviews +**Interview**: ISSO or IR team lead — walk through the last significant incident response +**Test**: Tabletop exercise results; verify team knows who to notify and within what timeframe for each category of incident + +### IR-6 Incident Reporting +**Objectives**: Personnel report incidents within defined timeframe; incidents reported to US-CERT within 1 hour of discovery (for federal agencies per OMB M-20-04) +**Examine**: Incident reporting logs, evidence of US-CERT notifications, internal escalation records + +--- + +## MA — Maintenance + +### Key Assessment Focus +Verify that system maintenance is performed in a controlled manner and that remote maintenance is properly authorised, logged, and terminated. + +### MA-2 Controlled Maintenance +**Objectives**: System maintenance scheduled, performed, documented, and records reviewed; maintenance requires approval; maintenance activities logged +**Examine**: Maintenance logs, approved maintenance schedules, work orders or ticketing records for maintenance activities +**Interview**: System administrator — how is scheduled and unscheduled maintenance authorised? + +### MA-4 Nonlocal Maintenance +**Objectives**: Remote maintenance and diagnostic activities authorised and monitored; remote maintenance sessions authenticated via MFA; sessions terminated after completion +**Examine**: Remote maintenance policy, logs of remote maintenance sessions, VPN/jump server configuration +**Test**: Verify remote maintenance session recordings exist for recent sessions; confirm sessions are terminated after use + +--- + +## MP — Media Protection + +### Key Assessment Focus +Verify that media containing sensitive information is properly marked, stored, transported, sanitised, and destroyed. + +### MP-6 Media Sanitisation +**Objectives**: System media sanitised before disposal or reuse; sanitisation implemented per NIST SP 800-88 guidelines; sanitisation actions documented +**Examine**: Media sanitisation policy, sanitisation records (by device serial number), data destruction certificates, contracts with sanitisation vendors +**Interview**: IT staff responsible for media sanitisation — what tool or method is used? How are records kept? + +--- + +## PE — Physical and Environmental Protection + +### Key Assessment Focus +Verify that physical access to the facility and system is controlled, monitored, and logged. + +### PE-2 Physical Access Authorisations +**Objectives**: List of individuals authorised for physical access maintained and reviewed per defined frequency; access removed when no longer required +**Examine**: Physical access authorisation list, badge access configuration, recent review records showing verification and update of the list +**Test**: Review access list against current HR roster to identify terminated employees or contractors with active physical access + +### PE-6 Monitoring Physical Access +**Objectives**: Physical access to the facility monitored; intrusion alarms and surveillance equipment monitored; physical access logs reviewed +**Examine**: Physical access log (badge in/out), surveillance system configuration, alert monitoring logs, visitor logs + +--- + +## PL — Planning + +### Key Assessment Focus +Verify that the system has a complete, current, and approved System Security Plan. + +### PL-2 System Security Plan +**Objectives**: SSP developed for the system; SSP includes all required sections; SSP reviewed and updated per defined frequency; SSP protects from unauthorised disclosure +**Examine**: Current SSP with all sections (boundary, data types, control narratives, interconnections), SSP revision history, distribution controls +**Interview**: ISSO — when was the SSP last reviewed and updated? + +--- + +## PM — Program Management + +### Key Assessment Focus +Verify that organisation-wide security programme management controls exist at the enterprise level (not system-specific). + +### PM-1 Information Security Program Plan +**Objectives**: Enterprise information security programme plan exists, covers required organisational areas, is reviewed and updated +**Examine**: Information security programme plan, governance documentation, risk executive appointment + +--- + +## PS — Personnel Security + +### Key Assessment Focus +Verify that background investigations are conducted and that access is terminated promptly when personnel leave. + +### PS-3 Personnel Screening +**Objectives**: Individuals screened prior to system access; re-screening performed based on position sensitivity +**Examine**: Background investigation records or adjudication confirmations, position sensitivity designations +**Interview**: HR security coordinator — what background check is required before access? How are contractors handled? + +### PS-4 Personnel Termination +**Objectives**: Access terminated upon separation; final exit checklist completed; credentials revoked; return of equipment confirmed +**Examine**: Exit checklist (with completed items), termination date vs. access revocation date records; ideally same-day revocation for sensitive systems +**Test**: Identify the 5 most recent terminations and compare termination date to account disable date in the identity management system + +--- + +## PT — PII Processing and Transparency (Privacy) + +### Key Assessment Focus +Verify that the organisation identifies, maps, and governs PII processing and provides transparency to affected individuals. + +### PT-1 Policy and Procedures +**Examine**: Privacy policy, PII processing procedures + +### PT-3 Personally Identifiable Information Processing Purposes +**Objectives**: PII processing limited to documented, authorised purposes; individuals notified of PII processing purposes +**Examine**: Privacy impact assessment (PIA), data flow diagrams showing PII, data inventory/PII inventory, privacy notice(s) + +--- + +## RA — Risk Assessment + +### Key Assessment Focus +Verify that the system risk assessment is current and that vulnerabilities are identified and remediated in a timely manner. + +### RA-3 Risk Assessment +**Objectives**: Risk assessment conducted; risk assessment documents threats, vulnerabilities, likelihood, and impact; risk assessment reviewed and updated per defined frequency or trigger events +**Examine**: Current risk assessment report, risk assessment methodology, evidence of review and update after significant changes + +### RA-5 Vulnerability Monitoring and Scanning +**Objectives**: Vulnerability scans conducted per defined frequency; high/critical vulnerabilities remediated within defined timeframe; vulnerability scan results shared with appropriate personnel +**Examine**: Vulnerability scan reports (most recent), scan schedule, remediation tracking records +**Test**: Review the last 3 scan reports; calculate the percentage of critical vulnerabilities remediated within the required timeframe; compare to the POA&M + +--- + +## SA — System and Services Acquisition + +### Key Assessment Focus +Verify that security requirements are included in acquisitions and that developer security testing is required. + +### SA-4 Acquisition Process +**Objectives**: Security functional requirements, assurance requirements, and documentation requirements included in contracts and acquisition documents +**Examine**: Sample contracts or statements of work (SOWs), system requirements documents, security addenda to contracts + +### SA-11 Developer Testing and Evaluation +**Objectives**: Developer required to conduct security testing including unit tests, integration tests, and regression tests; test results provided; flaws identified and remediated +**Examine**: Developer testing requirements in contracts, test plans and results from developers, flaw remediation records + +--- + +## SC — System and Communications Protection + +### Key Assessment Focus +Verify that the system boundary is defined and enforced, communications are encrypted, and network traffic is controlled. + +### SC-5 Denial of Service Protection +**Objectives**: System protects against denial-of-service attacks or limits their effects +**Examine**: DDoS protection configuration (rate limiting, CDN/WAF settings), SSP SC narrative +**Test**: Review network device configurations for rate limiting settings; verify DDoS protection service is active + +### SC-7 Boundary Protection +**Objectives**: System implements a managed interface at each external boundary; network traffic controlled; only approved ports, protocols, and services allowed +**Examine**: Network diagrams (showing boundary devices), firewall rule sets, router/switch ACLs, data flow diagrams +**Test**: Verify that the firewall rule set contains a default deny; review open ports and services against the approved list in the SSP; check for any "any-any" rules + +### SC-28 Protection of Information at Rest +**Objectives**: Information at rest is protected via encryption or equivalent mechanism +**Examine**: Encryption configuration for storage (full disk encryption, database encryption, file-level encryption), key management documentation +**Test**: Verify encryption is enabled on storage volumes and databases per configuration artifacts; confirm encryption standard meets current requirements (AES-256 or equivalent) + +--- + +## SI — System and Information Integrity + +### Key Assessment Focus +Verify that the system detects and remediates flaws, is protected from malicious code, and monitors for security alerts. + +### SI-2 Flaw Remediation +**Objectives**: System flaws identified, reported, and corrected; software updates provided, tested, and installed within defined timeframes; security alerts and advisories issued +**Examine**: Patch management policy, patch scan results (most recent), patch completion metrics, POA&M entries for deferred patches +**Test**: Run or review a patch scan for the past 30 days; verify critical patches are installed within the required timeframe (typically 30 days for Critical, 90 days for High) + +### SI-3 Malicious Code Protection +**Objectives**: Malicious code protection mechanisms at entry/exit points and on endpoints; updated per defined frequency; scanning actions defined +**Examine**: AV/EDR solution configuration and coverage reports, definition update frequency configuration, scan logs +**Test**: Verify AV/EDR definitions are current (within 24 hours for signature-based), confirm coverage of all endpoints per inventory + +--- + +## SR — Supply Chain Risk Management + +### Key Assessment Focus +Verify that the organisation identifies, manages, and monitors supply chain risks for the information system. + +### SR-1 Policy and Procedures +**Examine**: SCRM policy, supply chain risk management procedures, revision history + +### SR-2 Supply Chain Risk Management Plan +**Objectives**: SCRM plan developed for the system; plan considers risks from suppliers, developers, and service providers; plan reviewed and updated +**Examine**: SCRM plan, supplier risk assessments, approved supplier/developer list + +### SR-11 Component Authenticity +**Objectives**: Anti-counterfeit controls employed; provenance of components tracked; counterfeit components prevented, detected, and disposed of +**Examine**: Hardware procurement records showing authorised suppliers, SBOM (if applicable), component inventory with provenance tracking diff --git a/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/finding-severity.md b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/finding-severity.md new file mode 100644 index 0000000..600905a --- /dev/null +++ b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/finding-severity.md @@ -0,0 +1,170 @@ +# Finding Severity Classification — NIST SP 800-53A Rev 5 + +This reference file defines the severity classification criteria for security control assessment findings. It draws on NIST SP 800-53A Rev 5, NIST SP 800-30 Rev 1 risk determination scales, and FedRAMP/FISMA programme guidance. + +--- + +## Severity Scale Overview + +When a control is assessed as **Other Than Satisfied (OTS)**, the finding must be assigned a severity level. Severity is determined by combining: (a) the impact of exploiting the vulnerability introduced by the deficiency, and (b) the likelihood that the deficiency could be exploited. + +| Severity | Risk Level (SP 800-30) | Definition | +|---------|----------------------|-----------| +| **Critical** | Very High | A control is absent or fundamentally broken; exploitation is trivially easy and could result in complete loss of confidentiality, integrity, or availability; requires immediate remediation | +| **High** | High | A significant control deficiency exists; exploitation is feasible and would result in major adverse impact; remediation required before next ATO period | +| **Moderate** | Moderate | A meaningful deficiency; exploitation would require additional steps or has partial mitigations; remediation required within an acceptable timeframe | +| **Low** | Low | A minor deficiency with limited impact; compensating controls reduce risk to an acceptable level; remediation recommended | +| **Informational** | Very Low | No direct security risk; an observation or best practice recommendation; no POA&M required | + +--- + +## Severity Criteria by Impact Area + +### Assessing the Impact Component + +| Impact | Description | Example | +|--------|-------------|---------| +| **Catastrophic** | Complete mission failure; loss of life possible; loss of major assets or resources; severe financial loss | Unencrypted Top Secret data exposed publicly; critical infrastructure control lost | +| **Severe** | Mission significantly degraded; major financial loss; major privacy breach | PII of thousands of individuals disclosed; critical system unavailable >72 hours | +| **Moderate** | Some mission degradation; significant operational disruption; limited financial loss | Sensitive internal data accessed unauthorisedly; critical system unavailable 8–72 hours | +| **Minor** | Noticeable degradation but mission continues; limited operational impact; minor financial loss | Internal non-sensitive data disclosed; system unavailable <8 hours | +| **Negligible** | Minimal or no impact on operations, assets, or individuals | No operational disruption; reputation impact only; minor inconvenience | + +### Assessing the Likelihood Component + +| Likelihood | Description | Conditions | +|-----------|-------------|-----------| +| **Very High** | Near certainty; uncontrolled deficiency actively exploitable; no barriers to exploitation | Known public exploitation; no authentication required; internet-facing | +| **High** | Highly probable; deficiency is exploitable by an adversary with standard capabilities | Publicly known vulnerability; low technical barrier; limited access controls | +| **Moderate** | Realistic possibility; requires some capability but achievable by determined adversary | Technical skill required; some access controls present but insufficient | +| **Low** | Unlikely but possible; significant barriers exist | High technical skill required; strong compensating controls in place | +| **Very Low** | Remote; deficiency only exploitable under very specific, unlikely conditions | Multiple strong compensating controls; very limited access; no known exploitation | + +### Risk Determination Matrix (SP 800-30 Rev 1, Table I-2) + +| | **Negligible** | **Minor** | **Moderate** | **Severe** | **Catastrophic** | +|---------------------|--------------|---------|------------|----------|----------------| +| **Very High** | Low | Moderate | High | Very High | Very High | +| **High** | Low | Moderate | Moderate | High | Very High | +| **Moderate** | Very Low | Low | Moderate | Moderate | High | +| **Low** | Very Low | Very Low | Low | Low | Moderate | +| **Very Low** | Very Low | Very Low | Very Low | Low | Low | + +Map the risk level to severity: +- Very High → **Critical** +- High → **High** +- Moderate → **Moderate** +- Low → **Low** +- Very Low → **Informational** + +--- + +## Severity Examples by Control Area + +### Critical Severity Examples + +| Control | Finding | +|---------|---------| +| IA-2 | No authentication required to access an internet-facing administrative interface | +| AC-3 | Any unauthenticated user can access all system data (no access enforcement) | +| SC-28 | Sensitive PII stored in plaintext; no encryption at rest; publicly accessible storage | +| AU-2 | Audit logging completely disabled; no record of any access or actions | +| SI-3 | No malware protection on any endpoint; known malware present on active systems | + +### High Severity Examples + +| Control | Finding | +|---------|---------| +| IA-2(1) | Multi-factor authentication not enforced for privileged accounts | +| AC-2 | Numerous accounts for terminated employees remain active and unreviewed | +| SI-2 | Critical-rated CVEs from 12+ months ago unpatched on internet-facing systems | +| AU-9 | Audit logs can be modified or deleted by standard user accounts | +| CM-6 | Default passwords or manufacturer credentials in use on network devices | +| PE-3 | Physical access to the server room is uncontrolled; no badge readers | + +### Moderate Severity Examples + +| Control | Finding | +|---------|---------| +| AC-6 | Several non-privileged accounts have excessive permissions beyond role requirements; no documented justification | +| CP-9 | Backup restoration has not been tested in over 12 months; backups assumed working but unverified | +| RA-5 | Vulnerability scans are conducted but findings from 90+ days ago remain unaddressed without POA&M | +| AT-2 | 25% of users have not completed their annual security awareness training | +| CM-3 | Emergency changes are implemented without post-change documentation consistently | + +### Low Severity Examples + +| Control | Finding | +|---------|---------| +| PL-2 | SSP was last reviewed 14 months ago; policy requires review every 12 months | +| AT-3 | Role-based training for one non-critical role group is 2 months overdue | +| MA-2 | Maintenance logs exist but do not include technician identification in 20% of entries | +| PS-5 | Transfer checklist requires 2 days but documented completion in 3 of 10 reviewed cases showed 3-day completion | +| CM-1 | Configuration management procedure references a superseded NIST document | + +### Informational Examples + +| Control | Finding | +|---------|---------| +| AC-2 | Account naming convention is documented but inconsistently applied; no security impact | +| CM-6 | Some non-security-impacting settings deviate from baseline; deviations documented and accepted | +| AT-2 | Training content covers all required topics but could be enhanced with more interactive scenarios | + +--- + +## Compensating Controls and Risk Reduction + +When assigning severity, consider whether effective compensating controls reduce the actual risk posed by the deficiency: + +| If the OTS finding is offset by... | Risk reduction | +|-----------------------------------|---------------| +| Strong detective controls (e.g., SIEM alert configured for the same attack vector) | May reduce severity by one level | +| Physical controls compensating for logical gaps | Evaluate proportionally | +| Mitigating network isolation (internal network only, no external exposure) | May reduce likelihood component | +| Continuous monitoring detecting exploitation quickly | May reduce impact estimate | + +**Important**: Compensating controls reduce but do not eliminate a finding. Document the compensating control and the adjusted risk determination. + +--- + +## Remediation Timeframes + +Federal agencies generally follow these remediation timeframes, derived from OMB M-21-31 and CISA Known Exploited Vulnerabilities (KEV) guidance: + +| Severity | Recommended Remediation Timeframe | POA&M Required? | +|---------|----------------------------------|----------------| +| Critical | Immediate to 15 days | Yes — immediate escalation to AO | +| High | 30 days | Yes | +| Moderate | 90 days | Yes | +| Low | 180 days | Yes | +| Informational | Best effort / next cycle | No — optional observation in SAR | + +**POA&M milestone requirements**: +- Critical/High: Initial milestone within 7 days of SAR delivery; interim milestones monthly +- Moderate: Initial milestone within 30 days; quarterly updates +- Low: Annual review sufficient + +--- + +## Aggregated Risk Considerations + +Individual findings at a lower severity may collectively represent a higher risk where: +1. Multiple Moderate findings in the same control family indicate a systemic programme failure +2. Multiple Low findings in access control + audit + incident response together suggest an inability to detect and respond to incidents +3. A finding marked "Not Applicable" that is incorrectly justified should be flagged as a finding + +When presenting aggregated risk to the AO, note: +- "This system has no Critical or High findings, but 8 Moderate findings in AC and AU create a combined elevated risk for [specific threat scenario]." + +--- + +## AO Risk Decision Support + +The SAR risk summary should enable the Authorising Official to make a risk-based authorization decision: + +| Risk Profile | AO Options | +|-------------|-----------| +| No Critical/High findings, Moderate and below | Likely to support ATO with POA&M items | +| High findings with near-term POA&M milestones | ATO with conditions (POA&M milestones as conditions of authorisation) | +| Critical findings or multiple High findings without near-term remediation | May delay ATO until Critical/High findings remediated; or reject ATO | +| Critical findings that pose immediate risk | Immediate remediation required; system operation may need to be restricted pending fix | diff --git a/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/sap-sar-templates.md b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/sap-sar-templates.md new file mode 100644 index 0000000..ab52968 --- /dev/null +++ b/plugins/nist-sp-800-53a/skills/nist-sp-800-53a/references/sap-sar-templates.md @@ -0,0 +1,409 @@ +# SAP and SAR Templates — NIST SP 800-53A Rev 5 + +This reference file contains document templates and field-level guidance for the Security Assessment Plan (SAP) and Security Assessment Report (SAR) as defined in NIST SP 800-53A Rev 5. + +Source: NIST SP 800-53A Rev 5, January 2022; NIST RMF Quick Start Guide; OMB guidance + +--- + +## Security Assessment Plan (SAP) Template + +--- + +### [SYSTEM NAME] Security Assessment Plan + +**Document Classification**: [e.g., For Official Use Only (FOUO) / Sensitive] +**Version**: 1.0 +**Date**: [DATE] +**Prepared By**: [Assessment Organisation or Individual Assessor Name] + +--- + +#### Section 1 — System Identification + +| Field | Value | +|-------|-------| +| System Name | | +| System Identifier (FISMA UID or similar) | | +| System Acronym | | +| Agency / Component | | +| Responsible Organisation | | +| System Owner (Name, Title, Phone, Email) | | +| ISSO (Name, Title, Phone, Email) | | +| Authorising Official (Name, Title) | | +| System Security Categorisation | LOW / MODERATE / HIGH (per FIPS 199) | +| Privacy Overlay Required? | YES / NO | +| Assessment Type | Initial / Reauthorisation / Annual Assessment / Significant Change | +| Planned Assessment Start Date | | +| Planned Assessment End Date | | + +--- + +#### Section 2 — Assessment Scope + +**2.1 Controls in Scope** + +List all security and privacy controls to be assessed. Controls in scope are typically those specified in the approved System Security Plan (SSP). + +| Control Family | Control(s) in Scope | Notes | +|---------------|--------------------|----| +| AC — Access Control | AC-1 through AC-25 (as applicable) | | +| AT — Awareness and Training | AT-1 through AT-6 | | +| AU — Audit and Accountability | AU-1 through AU-16 | | +| CA — Assessment, Authorization, Monitoring | CA-1 through CA-9 | | +| CM — Configuration Management | CM-1 through CM-14 | | +| CP — Contingency Planning | CP-1 through CP-13 | | +| IA — Identification and Authentication | IA-1 through IA-13 | | +| IR — Incident Response | IR-1 through IR-10 | | +| MA — Maintenance | MA-1 through MA-6 | | +| MP — Media Protection | MP-1 through MP-8 | | +| PE — Physical and Environmental | PE-1 through PE-23 | | +| PL — Planning | PL-1 through PL-11 | | +| PM — Program Management | PM-1 through PM-33 | | +| PS — Personnel Security | PS-1 through PS-9 | | +| PT — PII Processing and Transparency | PT-1 through PT-8 | | +| RA — Risk Assessment | RA-1 through RA-10 | | +| SA — System and Services Acquisition | SA-1 through SA-23 | | +| SC — System and Communications Protection | SC-1 through SC-51 | | +| SI — System and Information Integrity | SI-1 through SI-23 | | +| SR — Supply Chain Risk Management | SR-1 through SR-12 | | + +**2.2 Controls Excluded from This Assessment** + +| Control ID | Justification for Exclusion | +|-----------|--------------------------| +| [e.g., PM-3] | [e.g., Assessed at organisational level, not system-level] | + +**2.3 System Components in Scope** + +| Component | Type | IP / Hostname | Environment | +|-----------|------|--------------|-------------| +| | | | | + +**2.4 System Boundary Description** +[Describe the authorisation boundary — what is inside and outside the boundary; reference the SSP boundary diagram] + +**2.5 Interconnected Systems** +[List any interconnected systems and whether they are in scope for this assessment; if not in scope, note how trust in the interconnection is established] + +--- + +#### Section 3 — Assessment Team + +**3.1 Assessment Team Members** + +| Name | Organisation | Role | Qualifications | +|------|-------------|------|--------------| +| | | Assessment Team Lead | | +| | | Security Assessor | | +| | | Technical Assessor | | + +**3.2 Organisational Independence Statement** + +[State whether the assessment team is organisationally independent from the system owner and ISSO. For HIGH-impact systems, the assessor must have a degree of independence that provides confidence that findings are objective. Describe the nature of any relationship to the system owner.] + +Under SP 800-53A Rev 5, for HIGH-impact systems, independent third-party or separate internal team assessors are strongly preferred. For MODERATE-impact systems, semi-independence (different division or chain of command) is acceptable. For LOW-impact systems, the ISSO may assist in assessments but should not self-assess. + +**3.3 Conflict of Interest** +[State that the team members have reviewed for conflicts of interest and identified none, or identify any conflicts and mitigations] + +--- + +#### Section 4 — Assessment Approach + +**4.1 Assessment Depth and Justification** + +Selected depth level: ________________ + +| Depth Level | Description | Selected? | +|------------|-------------|----------| +| Basic | High-level review; limited testing; appropriate for LOW-impact systems | | +| Focused | Thorough review of key controls; standard testing; appropriate for MODERATE-impact | | +| Comprehensive | Systematic, detailed review and testing of all aspects; HIGH-impact systems | | + +Justification: [Explain why this depth level was chosen based on impact level, risk posture, and assessment purpose] + +**4.2 Assessment Coverage and Justification** + +Selected coverage level: ________________ + +| Coverage Level | Description | Selected? | +|---------------|-------------|----------| +| Representative | Statistically or informationally representative sample | | +| Focused | Subset selected based on risk | | +| Comprehensive | All instances of each assessment object type | | + +Justification: [Explain the coverage choice] + +**4.3 Methods to be Used by Control Family** + +| Control Family | Examine | Interview | Test | +|---------------|---------|----------|------| +| AC | X | X | X | +| AT | X | X | | +| AU | X | | X | +| CA | X | X | | +| CM | X | X | X | +| CP | X | X | X | +| IA | X | X | X | +| IR | X | X | X | +| MA | X | X | | +| MP | X | X | | +| PE | X | X | X | +| PL | X | X | | +| PM | X | X | | +| PS | X | X | | +| PT | X | X | | +| RA | X | X | | +| SA | X | X | | +| SC | X | | X | +| SI | X | | X | +| SR | X | X | | + +--- + +#### Section 5 — Assessment Schedule and Logistics + +**5.1 Schedule** + +| Activity | Planned Date | Lead | +|----------|-------------|------| +| SAP finalisation and approval | | | +| Kickoff meeting with system owner and ISSO | | | +| Document collection and review | | | +| Onsite interviews | | | +| Technical testing | | | +| Preliminary findings review with system owner | | | +| SAR draft delivery | | | +| SAR final delivery | | | + +**5.2 Required Resources and Access** + +| Resource | Purpose | Point of Contact | +|----------|---------|----------------| +| SSP, authorisation package | Document review | ISSO | +| Read-only access to [system/admin console] | Configuration review | System administrator | +| Access to log management system | Audit log review | Security operations | +| Sample list of user accounts (active and recently terminated) | Account management testing | System administrator | +| Vulnerability scan results (last 30 days) | RA-5 assessment | System administrator | +| Firewall rule export | SC-7 assessment | Network administrator | + +**5.3 Rules of Engagement** + +[IMPORTANT: Define what testing activities are and are not permitted to prevent disruption] + +The following rules of engagement govern all testing activities: +1. All active testing (Test method) shall be limited to [non-production / production] environments +2. Account testing shall be performed using designated test accounts only (no real user accounts) +3. Penetration-style testing is [in scope / out of scope] for this assessment +4. The assessment team shall notify [POC name/role] immediately if a critical finding is identified during testing +5. Testing hours: [e.g., normal business hours only / after hours only for system-impacting tests] + +--- + +#### Section 6 — Reporting Requirements + +**6.1 Finding Documentation Format** +Findings shall be documented using the SAR template format (see SAR Section 3). Each finding shall include: control ID, assessment objective, determination value, severity, description, evidence, risk determination, and recommendation. + +**6.2 Reporting Recipients** + +| Recipient | Role | Report Sensitivity | +|----------|------|--------------------| +| | Authorising Official | Unredacted | +| | System Owner | Unredacted | +| | ISSO | Unredacted | +| | CISO / Risk Executive | Summary only | + +**6.3 Reporting Timeline** +- Preliminary findings briefing: Within [X] business days of assessment completion +- SAR draft: Within [X] business days of preliminary briefing +- SAR final: Within [X] business days of receiving system owner comments + +**6.4 Handling Sensitive Findings** +Critical and High severity findings shall be communicated verbally and via secure channel to the Authorising Official within 24 hours of identification. The SAR itself shall be handled as [FOUO / CONFIDENTIAL]. + +--- + +#### Section 7 — Approvals + +| Role | Name | Signature | Date | +|------|------|----------|------| +| Assessment Team Lead | | | | +| System Owner | | | | +| ISSO | | | | +| Authorising Official (or AODR) | | | | + +--- + +--- + +## Security Assessment Report (SAR) Template + +--- + +### [SYSTEM NAME] Security Assessment Report + +**Document Classification**: [FOUO / Sensitive] +**Version**: 1.0 +**Date**: [DATE] +**Prepared By**: [Assessment Organisation] + +--- + +#### Section 1 — Executive Summary + +| Field | Value | +|-------|-------| +| System Name | | +| System Categorisation | LOW / MODERATE / HIGH | +| Assessment Period | [Start Date] to [End Date] | +| Assessment Type | Initial / Reauthorisation / Annual | +| Assessment Team | | +| Number of Controls Assessed | | +| Number of Controls Satisfied | | +| Number of Controls Other Than Satisfied | | +| Number of Controls Not Applicable | | + +**Finding Summary by Severity** + +| Severity | Count | +|---------|-------| +| Critical | | +| High | | +| Moderate | | +| Low | | +| Informational | | +| **Total** | | + +**Overall Posture Statement** +[Provide a narrative statement (3–5 sentences) describing the overall security posture, key risk areas, and recommended course of action for the Authorising Official] + +--- + +#### Section 2 — Assessment Scope and Methodology + +**2.1 Scope** +[Confirm what was and was not assessed, by reference to the SAP; note any scope changes during the assessment] + +**2.2 Depth and Coverage** +Assessment conducted at **[depth level]** depth and **[coverage level]** coverage. + +**2.3 Assessment Limitations and Constraints** +[Document any limitations that affected the assessment, e.g., access denied to certain logs, system unavailability, time constraints, inability to perform certain tests] + +| Limitation | Impact on Assessment | Affected Controls | +|-----------|---------------------|-------------------| +| | | | + +--- + +#### Section 3 — Assessment Findings + +For each control assessed, document the finding using the format below. Controls assessed as "Satisfied" require minimal documentation. Controls assessed as "Other Than Satisfied" require full finding documentation. + +--- + +**Control Finding Template** + +``` +Control ID: [e.g., AC-2] +Control Name: [e.g., Account Management] +SP 800-53 Rev 5 Baseline: LOW / MODERATE / HIGH / Privacy +Privacy Control: YES / NO + +Assessment Objective [a]: [Description of objective] + Determination: Satisfied / Other Than Satisfied / Not Applicable + Evidence: [Brief description of evidence reviewed/tested] + +Assessment Objective [b]: [Description of objective] + Determination: Satisfied / Other Than Satisfied / Not Applicable + Evidence: [Brief description of evidence reviewed/tested] + +[... repeat for each objective ...] + +Overall Control Determination: Satisfied / Other Than Satisfied / Not Applicable + +FINDING (complete only if Other Than Satisfied): + Finding ID: [SAR-YYYY-NNN] + Severity: Critical / High / Moderate / Low / Informational + Description: [Clear, factual description of what is missing, insufficent, + or not operating as intended. State what was observed and how + it deviates from the SP 800-53 Rev 5 requirement.] + Evidence Summary: [Documents reviewed, individuals interviewed, tests conducted + and their results that support this determination] + Risk Determination: [Using SP 800-30 risk scale: Very High / High / Moderate / + Low / Very Low — state the overall risk this finding poses, + referencing likelihood and impact] + Recommendation: [Specific, actionable remediation recommendation] +``` + +--- + +**Assessment Findings Log — Summary Table** + +| Finding ID | Control | Control Name | Severity | Determination | Recommendation Summary | +|-----------|---------|-------------|---------|--------------|----------------------| +| SAR-[Y]-001 | | | Critical | OTS | | +| SAR-[Y]-002 | | | High | OTS | | +| SAR-[Y]-003 | | | Moderate | OTS | | + +--- + +#### Section 4 — Risk Summary + +List all Other Than Satisfied findings rated High or Critical, with associated risk determinations. This section informs the Authorising Official's risk acceptance decision. + +| Finding ID | Control | Severity | Risk Level | Risk Description | Recommendation | +|-----------|---------|---------|-----------|-----------------|---------------| +| | | Critical | Very High | | | +| | | High | High | | | + +--- + +#### Section 5 — Assessor Attestation + +The undersigned assessment team members attest that this SAR accurately represents the results of the assessment conducted of [SYSTEM NAME]. The assessment was conducted in accordance with NIST SP 800-53A Rev 5, at [DEPTH] depth and [COVERAGE] coverage. Assessment team members have no undisclosed conflicts of interest with the system owner or the information system assessed. + +| Role | Name | Signature | Date | +|------|------|----------|------| +| Assessment Team Lead | | | | +| Security Assessor | | | | +| Technical Assessor | | | | + +--- + +## SAP-to-SAR Consistency Checklist + +Before finalising a SAR, verify the following against the SAP: + +| Check | Status | +|-------|--------| +| All controls in SAP scope are in the SAR | | +| Depth and coverage levels match SAP | | +| Team composition matches SAP | | +| All SAP-listed assessment objects were reviewed | | +| Any deviations from the SAP are documented in SAR Section 2.3 | | +| Every OTS finding has: Finding ID, Severity, Description, Evidence, Risk, Recommendation | | +| Severity assignments follow the 5-level scale | | +| POA&M action items align with OTS findings | | + +--- + +## POA&M Linkage + +Every "Other Than Satisfied" finding in the SAR must generate a POA&M entry. The SAR Finding ID becomes the POA&M Item ID. Required POA&M fields per OMB M-02-01 and NIST SP 800-37: + +| POA&M Field | Source | +|------------|--------| +| POA&M Item ID | SAR Finding ID | +| System Name and ID | From SAR header | +| Control Number | From SAR finding | +| Finding Description | SAR finding description | +| Weakness/Deficiency | SAR evidence summary | +| Risk Level | SAR risk determination | +| Resources Required | Assessor's recommendation, system owner estimate | +| Scheduled Completion Date | System owner determination | +| Milestones | System owner creates milestone schedule | +| Responsible Point of Contact | Assigned by system owner | +| Status | Open (until remediated and verified) | diff --git a/plugins/nist-sp-800-63/.claude-plugin/plugin.json b/plugins/nist-sp-800-63/.claude-plugin/plugin.json new file mode 100644 index 0000000..f5133b9 --- /dev/null +++ b/plugins/nist-sp-800-63/.claude-plugin/plugin.json @@ -0,0 +1,25 @@ +{ + "name": "nist-sp-800-63", + "version": "1.0.0", + "description": "NIST SP 800-63 Rev 3 Digital Identity Guidelines skill for guidance on identity assurance levels, authenticator assurance levels, federation assurance levels, identity proofing, credential management, and federation protocols.", + "author": { + "name": "Simon Jackson", + "email": "sjackson0109@gmail.com" + }, + "homepage": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "repository": "https://github.com/sjackson0109/Claude-Skills-Governance-Risk-and-Compliance", + "license": "MIT", + "keywords": [ + "nist-sp-800-63", + "digital-identity", + "identity-assurance", + "authenticator-assurance", + "federation-assurance", + "identity-proofing", + "IAL", + "AAL", + "FAL", + "MFA", + "FISMA" + ] +} diff --git a/plugins/nist-sp-800-63/skills/nist-sp-800-63/SKILL.md b/plugins/nist-sp-800-63/skills/nist-sp-800-63/SKILL.md new file mode 100644 index 0000000..63b2d4a --- /dev/null +++ b/plugins/nist-sp-800-63/skills/nist-sp-800-63/SKILL.md @@ -0,0 +1,285 @@ +--- +name: nist-sp-800-63 +description: > + Expert NIST SP 800-63 Rev 3 Digital Identity Guidelines advisor. Use this skill + whenever a user asks about digital identity, identity assurance levels (IAL1, IAL2, + IAL3), authenticator assurance levels (AAL1, AAL2, AAL3), federation assurance levels + (FAL1, FAL2, FAL3), identity proofing, credential service providers (CSPs), verifiers, + relying parties, multi-factor authentication, phishing-resistant authenticators, + TOTP, FIDO2/WebAuthn, PIV, CAC, federation protocols (OIDC, SAML), identity + verification for online services, remote or in-person identity proofing, binding + of authenticators, digital identity risk assessment, selecting identity assurance + levels, or building an identity and access management (IAM) programme aligned to + NIST standards. Also trigger for questions about: "what IAL do I need?", "does MFA + satisfy AAL2?", "what is identity proofing?", "how do I verify a user's identity + remotely?", "what authenticator types are allowed at AAL2?", "what is a CSP?", + "how do I federate identity?", or any NIST identity, authentication, or digital + credential question. +--- + +# NIST SP 800-63 Rev 3 — Digital Identity Guidelines Skill + +You are an expert digital identity advisor specialising in **NIST Special Publication 800-63 Revision 3: Digital Identity Guidelines** (June 2017, with errata as of March 2020). This suite comprises four volumes: SP 800-63-3 (the overarching guideline), **SP 800-63A** (Enrollment and Identity Proofing), **SP 800-63B** (Authentication and Lifecycle Management), and **SP 800-63C** (Federation and Assertions). + +You assist **federal agencies, identity architects, IAM engineers, security architects, and application developers** in selecting appropriate assurance levels, implementing identity proofing, choosing and deploying authenticators, and building federation architectures. + +--- + +## How to Respond + +| Task | Output Format | +|------|--------------| +| Assurance level selection | Table: Level | Requirements Met | Recommendation | +| Identity proofing requirements | Structured list per IAL level | +| Authenticator type guidance | Table: Type | AAL | Phishing Resistance | FIPS 140 | Notes | +| Federation/assertion guidance | Protocol comparison or structured requirements list | +| Risk assessment for identity | Structured risk table: xAL | Impact | Confidence | Recommended level | +| General question | Concise prose with SP 800-63 section citations | + +--- + +## SP 800-63 Rev 3 Overview + +### Purpose + +SP 800-63 Rev 3 establishes technical requirements for federal agencies implementing digital identity services. It defines three assurance dimensions and the technical requirements for each level: + +- **Identity Assurance Level (IAL)**: Confidence in the binding between the claimed identity and the real person +- **Authenticator Assurance Level (AAL)**: Strength of the authentication process itself (how confident are we that the person holds the claimed authenticator) +- **Federation Assurance Level (FAL)**: Strength of assertions passed between identity providers and relying parties in a federated system + +These three dimensions are **selected independently** — an application may require IAL2 but only AAL1, or IAL1 with AAL2. + +### Key Roles (SP 800-63-3) + +| Role | Definition | +|------|-----------| +| **Claimant** | An individual whose identity is being asserted | +| **Credential Service Provider (CSP)** | An entity that issues credentials and manages authenticators | +| **Verifier** | An entity that verifies the claimant's identity through a protocol | +| **Relying Party (RP)** | An entity that uses authentication assertions to provide services | +| **Identity Provider (IdP)** | In a federated model, the entity that manages the subscriber's identity | +| **Subscriber** | A party that has undergone identity proofing and received credentials from the CSP | +| **Applicant** | A party undergoing the enrolment and identity proofing process | + +--- + +## Identity Assurance Levels (IAL) — SP 800-63A + +IAL defines the level of confidence in the claimed identity of the subscriber. + +### IAL1 — No Identity Proofing Required + +**Requirements**: No identity proofing. Self-asserted attributes accepted. +**Use when**: The application has no need to bind a real-world identity to the digital identity (e.g., anonymous access, low-risk applications where the service can be accessed by anyone). +**Acceptable evidence**: None required +**Proofing method**: None + +### IAL2 — In-Person or Remote Proofing with Documentary Evidence + +**Requirements**: Identity proofing required; real-world existence of the claimed identity verified. Attributes are verified against authoritative sources or documentary evidence. +**Use when**: The service relies on the subscriber's identity (e.g., accessing government benefits, e-signature, court filings). +**Acceptable evidence**: +- **Superior evidence** (1 sufficient): Passport (US or foreign with MRZ), Real ID driver's licence or state ID, military ID +- **Strong evidence** (2 sufficient, or 1 strong + 2 fair): Driver's licence (non-Real ID), state ID, national ID card, military retiree ID, Permanent Resident Card +- **Fair evidence** (2 required in combination): Voter registration card, utility bills (current), bank statement, government-issued document with photo + +**Proofing methods** (IAL2): +1. **In-person proofing**: Present original documents to trained operator; operator verifies authenticity; biometric binding optional +2. **Supervised remote proofing**: Live video session with a trained operator; document scan verified via automated and/or human review; biometric comparison against AAMVA/DMV records or passport chip + +**Biometric**: Optional at IAL2; if collected, must be used to prevent duplicate enrolment + +### IAL3 — In-Person Proofing with Biometric Binding + +**Requirements**: In-person proofing with a trained representative. Physical inspection of original documents. Biometric collection required and bound to the subscriber's identity record. +**Use when**: The highest confidence in identity is required; national security systems; issuing physical identity credentials. +**Acceptable evidence**: Superior evidence OR strong + biometric comparison against a government authoritative database +**Proofing method**: In-person only; biometric capture (fingerprint, facial image) bound to the enrolment record + +--- + +## Authenticator Assurance Levels (AAL) — SP 800-63B + +AAL defines the strength of the authentication process. + +### Authenticator Types and AAL Eligibility + +| Authenticator Type | Description | AAL1 | AAL2 | AAL3 | +|-------------------|-------------|------|------|------| +| Memorised Secret (Password/PIN) | Something the user knows | Yes | No (alone) | No (alone) | +| Look-Up Secrets (backup codes) | Static codes from a printed list | Yes | No (alone) | No | +| Out-of-Band (SMS/PSTN) | One-time code sent via SMS or voice | Yes | Restricted (see below) | No | +| Single-Factor OTP (TOTP app) | Time-based or HMAC-based OTP | Yes | Yes (as 2nd factor) | No | +| Multi-Factor OTP Device | Hardware OTP with PIN | Yes | Yes | No | +| Single-Factor Cryptographic Software | Private key in software (e.g., browser key) | Yes | No (alone) | No | +| Single-Factor Cryptographic Device | Hardware key (e.g., FIDO2 security key) | Yes | Yes (as 2nd factor) | Yes (with PIN) | +| Multi-Factor Cryptographic Software | Software private key with memorised secret | Yes | Yes | No | +| Multi-Factor Cryptographic Device (hardware) | PIV card, CAC, FIDO2 hardware key with PIN | Yes | Yes | Yes | + +**AAL1**: Single-factor authentication. Any permitted authenticator type. Memorised secrets acceptable alone. +**AAL2**: Multi-factor authentication required. At least two of: something you know, something you have, something you are. Phishing resistance not required but recommended. +**AAL3**: Phishing-resistant hardware-based multi-factor authentication. Cryptographic device (hardware) required. Verifier impersonation resistance required. In-person verification of hardware bond may be required. + +### Phishing Resistance at AAL + +- **AAL1**: No phishing resistance required +- **AAL2**: Phishing resistance not required but recommended; SMS OTP is "restricted" at AAL2 (agencies must document risk) +- **AAL3**: Verifier impersonation resistance required — only hardware cryptographic authenticators that bind to the specific verifier (e.g., FIDO2 with origin binding, PIV with card-validated TLS) satisfy this requirement + +### SMS/PSTN at AAL2 — "Restricted" Status + +SP 800-63B designates SMS and PSTN-based out-of-band authenticators as "RESTRICTED" at AAL2. Agencies using them must: +1. Document the risk assessment justifying the use +2. Offer subscribers at least one alternative AAL2-eligible authenticator +3. Implement additional risk controls (fraud detection, anomaly detection) +4. Notify subscribers of risk + +### FIPS 140 Requirements + +| AAL | FIPS 140 Requirement | +|-----|---------------------| +| AAL1 | No FIPS 140 required | +| AAL2 | If cryptographic authenticator used: FIPS 140 Level 1 overall (Level 2 physical security for hardware authenticators) | +| AAL3 | FIPS 140 Level 2 overall; Level 3 physical security | + +### Reauthentication Requirements + +| AAL | Inactivity Timeout | Absolute Session Limit | +|-----|-------------------|----------------------| +| AAL1 | 30 days | No absolute limit | +| AAL2 | 30 minutes inactivity OR 12 hours absolute | 12 hours (with reauthentication) | +| AAL3 | 15 minutes inactivity OR 12 hours absolute | 12 hours | + +--- + +## Federation Assurance Levels (FAL) — SP 800-63C + +FAL describes the strength of an assertion passed from an IdP to an RP in a federated authentication scenario. + +### FAL1 — Bearer Assertion from IdP + +**Requirements**: Bearer assertion from the IdP; assertion must be signed (e.g., with RS256) so the RP can verify it was issued by the IdP; assertion delivered through the front channel (browser redirect) or back channel +**Protocols**: OpenID Connect (OIDC) ID tokens via implicit or authorization code flow; SAML 2.0 basic + +### FAL2 — Bearer Assertion Encrypted for RP + +**Requirements**: Assertion must be encrypted for the specific RP so that only the RP can decrypt it; prevents honest-but-curious IdP from observing what the RP is doing with the assertion +**Protocols**: OIDC with token endpoint using RS256 signing + RSA-OAEP encryption for ID token; SAML with XML Encryption + +### FAL3 — Holder-of-Key Assertion + +**Requirements**: Assertion must be cryptographically bound to the subscriber's authenticator so that only a holder of the matching key can use the assertion; provides protection against assertion theft +**Protocols**: token binding or equivalent mechanisms; FIDO2 with attestation; SAML HoK profile + +### Selecting FAL + +| FAL | When to Use | +|-----|------------| +| FAL1 | Low-risk federated applications; internal enterprise applications; where assertion interception risk is low | +| FAL2 | Moderate-risk applications where assertion confidentiality is important; where the IdP should not know what the RP is doing with the assertion | +| FAL3 | High-risk applications; national security systems; where assertion replay or theft is a significant threat | + +--- + +## Digital Identity Risk Assessment + +SP 800-63-3 Section 6 defines a risk assessment process for selecting the appropriate xAL levels. + +### Step 1 — Identify Transactions and Potential Harms + +For each transaction in the application, identify what could go wrong if: +- The wrong person was authenticated (authentication failure) +- The identity proofing was wrong (the person is not who they claim) +- A federation assertion was compromised + +### Step 2 — Assess Potential Harm Categories + +| Harm Category | Description | +|--------------|-------------| +| Inconvenience, distress, or damage to standing | Embarrassment, loss of reputation | +| Financial loss or liability | Direct financial harm to the subscriber or RP | +| Harm to agency programs or public interests | Mission failure, regulatory violation | +| Unauthorised release of sensitive information | Disclosure of PII, PHI, or classified material | +| Personal safety | Physical harm to the subscriber or others | +| Civil or criminal violations | Legal liability | + +### Step 3 — Determine Impact Level + +For each harm category, assess impact as Low, Moderate, or High. + +| Impact | Definition | +|--------|-----------| +| Low | Limited adverse effect; minor inconvenience; easily recoverable | +| Moderate | Significant adverse effect; substantial harm to reputation, financial loss, mission degradation | +| High | Severe or catastrophic adverse effect; major financial loss, serious mission degradation, loss of safety | + +### Step 4 — Select xAL Based on Maximum Impact + +| Maximum Impact | Minimum IAL | Minimum AAL | Minimum FAL | +|--------------|-------------|-------------|-------------| +| Low | IAL1 | AAL1 | FAL1 | +| Moderate | IAL2 | AAL2 | FAL2 | +| High | IAL3 | AAL3 | FAL3 | + +Agencies may select a higher xAL than the minimum if mission requirements, policy, or risk acceptance decisions warrant. + +--- + +## Credential and Authenticator Lifecycle — SP 800-63B + +### Binding and Enrollment +- New authenticators must be **bound to the subscriber's account** during enrolment +- If the subscriber already has an existing authenticator, adding a new authenticator requires **re-authentication with the existing authenticator** (or identity verification at the appropriate IAL) +- Lost authenticator: replacement requires identity proofing at or above the IAL of the original enrolment + +### Authenticator Requirements +- **Memorised secrets**: Minimum 8 characters; no complexity requirements mandated (complexity rules are deprecated in 800-63B); check against breach corpora (Have I Been Pwned list); no mandatory periodic expiry; expiry required only on suspicion of compromise +- **TOTP apps**: Algorithm: TOTP (RFC 6238) or HOTP (RFC 4226); 6-8 digit codes; valid window up to 30 seconds +- **Hardware OTP**: Nonce-based or time-based; must be validated by the verifier within acceptable time window + +### Account Recovery +At AAL2 and AAL3, account recovery must be at the same or higher assurance level as the original enrollment. Recovery codes (Look-up Secrets) may be issued at setup time. + +--- + +## Core Workflows + +### 1. Selecting xAL Levels for an Application +1. Identify all transactions in the application +2. For each transaction, identify potential harms from misrepresented identity, authentication failure, or assertion compromise +3. Assess impact level (Low / Moderate / High) for each harm category +4. Select xAL at Minimum based on maximum impact; document rationale +5. Review against agency policy and OMB guidance (M-19-17 for high-value assets) +6. Document the Digital Identity Risk Assessment in the system security documentation + +### 2. Advising on Authenticator Selection +1. Confirm the required AAL (from risk assessment) +2. For AAL1: any authenticator permitted; memorised secret adequate +3. For AAL2: two factors required; recommend hardware FIDO2 key or multi-factor OTP over SMS; flag SMS as RESTRICTED +4. For AAL3: hardware cryptographic MFA only; FIDO2 hardware key with PIN or PIV/CAC; document FIPS 140 requirement + +### 3. Planning Identity Proofing +1. Confirm the required IAL (from risk assessment) +2. For IAL1: no proofing required; document rationale +3. For IAL2: select in-person or supervised remote proofing; identify acceptable documentary evidence; plan biometric binding if needed +4. For IAL3: plan in-person proofing; identify trained operators; plan biometric collection + +--- + +## Reference Files + +- `references/assurance-levels.md` — Detailed IAL, AAL, and FAL requirements tables, selection matrices, and xAL combinations +- `references/authenticator-requirements.md` — Per-authenticator-type requirements, FIPS 140 levels, OTP algorithm requirements, reauthentication tables, lifecycle requirements +- `references/identity-proofing.md` — Identity proofing processes for IAL2 and IAL3 including evidence types, validation methods, biometric requirements, remote proofing requirements + +**When to load:** +- Selecting assurance levels or performing a digital identity risk assessment → load `references/assurance-levels.md` +- Choosing authenticator types or designing authentication flows → load `references/authenticator-requirements.md` +- Planning identity proofing or CSP enrolment → load `references/identity-proofing.md` + +--- + +## Disclaimer + +This skill is based on NIST SP 800-63 Rev 3 (June 2017) and its errata (March 2020), a freely available NIST publication. NIST SP 800-63-4 is in draft as of 2024; agencies should monitor csrc.nist.gov for the final publication and update their implementations accordingly. This skill does not constitute legal or compliance advice. Federal agencies must also comply with OMB M-19-17 (Enabling Mission Delivery through Improved Identity, Credential, and Access Management). diff --git a/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/assurance-levels.md b/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/assurance-levels.md new file mode 100644 index 0000000..601abd7 --- /dev/null +++ b/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/assurance-levels.md @@ -0,0 +1,213 @@ +# Assurance Levels Reference — NIST SP 800-63 Rev 3 + +Source: NIST SP 800-63-3 (June 2017), SP 800-63A Rev 3, SP 800-63B Rev 3, SP 800-63C Rev 3 + +--- + +## Identity Assurance Level (IAL) — Detailed Requirements + +### IAL1 + +No identity proofing. Self-asserted attributes accepted without verification. + +**Risks accepted by using IAL1**: +- The subscriber may not be who they claim to be +- Any person can create an account +- Attributes (name, email) are unverified + +**Appropriate for**: +- Public-facing applications with no access to personal data +- Anonymous or pseudonymous services +- Services where the user's real identity is irrelevant to the service provided + +**Not appropriate for**: +- Services that disburse benefits or funds to individuals +- Applications with access to personal health, financial, or safety data +- High-value asset systems + +--- + +### IAL2 — Full Requirements Table + +| Requirement | Remote (Unsupervised) | Remote (Supervised) | In-Person | +|------------|----------------------|---------------------|----------| +| Identity proofing required | Yes | Yes | Yes | +| Evidence required | 1 Superior OR 1 Strong + 2 Fair | 1 Superior OR 1 Strong + 2 Fair | 1 Superior OR 1 Strong + 2 Fair | +| Evidence must be unexpired | Yes | Yes | Yes | +| Evidence validation against issuer | Against available authoritative sources | Against available authoritative sources | Against available authoritative sources | +| Address confirmation required | Yes (notice to home address on record) | Yes | Yes | +| Biometric required | No (optional) | No (optional) | No (optional) | +| Live operator involvement | No | Yes (via video link) | Yes (in-person) | +| Allowed? (as of 800-63A-3 errata) | See note below | Yes | Yes | + +**Note on unsupervised remote proofing (IAL2)**: The original SP 800-63A permitted unattended remote proofing with strong document validation and liveness detection. Agencies must use approved KBV (knowledge-based verification) limitations — KBV alone is NOT sufficient at IAL2; it may only be used as a secondary supplement. As of the March 2020 errata, agencies should consider whether their unsupervised remote proofing implementation meets the normative requirements. + +**Address confirmation at IAL2**: +If not verified in-person: +- Send enrollment code to the address of record via postal mail +- Enrollment code must be validated by the subscriber within 5-day validity window +- OR, a USPS National Change of Address (NCOA) query is performed + +--- + +### IAL3 — Full Requirements Table + +| Requirement | IAL3 | +|------------|------| +| Proofing type | In-person only | +| Operator | Trained, authorised CSP representative | +| Evidence | Superior (1) AND physical document check; or Strong evidence with biometric match against authoritative source | +| Evidence validation | Physical authentication features checked (holograms, watermarks, MRZ validation) | +| Biometric collection | Required; facial image and/or fingerprint | +| Biometric binding | Biometric template bound to the identity record; used for future in-person re-verification | +| Duplicate enrolment check | Required — biometric compared against existing records to prevent creation of multiple identities | +| FIPS 140 for biometric capture | Level 1 minimum for the capture device | + +--- + +## Authenticator Assurance Level (AAL) — Requirements Summary + +### AAL1 Requirements + +- **Factors**: Single factor +- **Permitted types**: Any authenticator type in SP 800-63B Table 1 +- **Memorised secrets**: Minimum 8 characters; no other requirements +- **Reauthentication**: After 30 days of inactivity +- **FIPS 140**: Not required +- **Phishing resistance**: Not required +- **Verifier compromise resistance**: Not required +- **Communications security**: Approved cryptography required for authenticator output transmission + +### AAL2 Requirements + +- **Factors**: Multi-factor (two or more) +- **Permitted multi-factor combinations**: + - Multi-Factor OTP Device (hardware) + Memorised Secret + - Single-Factor OTP Device + Memorised Secret + - Multi-Factor Cryptographic Software + Memorised Secret (or inherence) + - Single-Factor Cryptographic Device + Memorised Secret + - Multi-Factor Cryptographic Device +- **SMS/PSTN**: RESTRICTED — permitted with documented risk assessment and alternative authenticator offered +- **Reauthentication**: 30 minutes inactivity AND 12 hours absolute (with reauthentication) +- **FIPS 140**: Level 1 overall for cryptographic authenticators; Level 2 physical security for hardware cryptographic authenticators +- **Phishing resistance**: Not required but recommended +- **Verifier compromise resistance**: Not required +- **Man-in-the-Middle resistance**: Required (secure channel) + +### AAL3 Requirements + +- **Factors**: Multi-factor hardware cryptographic +- **Permitted types only**: + - Multi-Factor Cryptographic Device (hardware) + - Single-Factor Cryptographic Device + Memorised Secret +- **Phishing resistance / verifier impersonation resistance**: Required — the authenticator must bind to a specific verifier (e.g., FIDO2 origin binding, TLS channel binding) +- **Reauthentication**: 15 minutes inactivity AND 12 hours absolute +- **FIPS 140**: Level 2 overall; Level 3 physical security +- **Verifier compromise resistance**: Required +- **Intent**: Authenticator must require explicit user action (e.g., pressing a button on the hardware key) + +--- + +## Federation Assurance Level (FAL) — Requirements Summary + +### FAL1 + +| Requirement | Value | +|------------|-------| +| Assertion type | Bearer | +| Assertion signed | Yes (IdP's private key) | +| Assertion encrypted | Not required | +| Delivery | Front or back channel | +| Example protocol | OIDC with RS256-signed ID token; SAML with XML-DSig | +| Subscriber binding | Not required | + +### FAL2 + +| Requirement | Value | +|------------|-------| +| Assertion type | Bearer | +| Assertion signed | Yes | +| Assertion encrypted | Yes — encrypted for the specific RP's public key | +| Delivery | Front or back channel | +| Example protocol | OIDC with encrypted ID token (RS256 + RSA-OAEP or A128KW); SAML with XML Encryption | +| Subscriber binding | Not required | + +### FAL3 + +| Requirement | Value | +|------------|-------| +| Assertion type | Holder-of-key | +| Assertion signed | Yes | +| Assertion encrypted | Recommended | +| Delivery | Back channel preferred | +| Example protocol | FIDO2 with assertion cryptographically bound to subscriber key; Token Binding; SAML HoK profile | +| Subscriber binding | Required — assertion can only be used by the holder of the matching private key | + +--- + +## xAL Selection Matrix + +### By Impact Level (SP 800-63-3 Table 6-2) + +| Impact Level | Recommended IAL | Recommended AAL | Recommended FAL | +|-------------|----------------|----------------|----------------| +| Low | IAL1 | AAL1 | FAL1 | +| Moderate | IAL2 | AAL2 | FAL2 | +| High | IAL3 | AAL3 | FAL3 | + +### Allowed xAL Combinations + +The three assurance levels are independent. Common valid combinations: + +| Scenario | IAL | AAL | FAL | Rationale | +|---------|-----|-----|-----|----------| +| Public information service | 1 | 1 | 1 | No PII, no harm from misidentification | +| Benefits eligibility inquiry (no disbursement) | 2 | 2 | 2 | Moderate impact if wrong person accesses data | +| Benefits disbursement | 2 | 2 | 2 | Moderate financial harm if wrong person claims | +| Healthcare portal (PHI access) | 2 | 2 | 2 | Moderate harm from PHI disclosure | +| High-value asset system (HVA) | 3 | 3 | 3 | Severe mission harm; OMB M-19-17 applies | +| Internal admin app (federated SSO) | 1 | 2 | 1 | No external identity; strong auth required | +| PIV-gated federal system | 2 or 3 | 3 | 3 | PIV satisfies IAL2/3 + AAL3 | + +### Notable Decoupled Combinations + +- **IAL1 + AAL2**: No identity proofing needed, but strong authentication required (e.g., a service that grants access by role after strong auth, but doesn't need to verify who the person is in the real world) +- **IAL2 + AAL1**: Identity verified but single-factor auth acceptable (e.g., low-sensitivity service that still needs to know who the person is — uncommon and discouraged for most scenarios) + +--- + +## OMB Supplemental Requirements (M-19-17) + +OMB Memorandum M-19-17 (May 2019) directed ICAM policy for federal agencies: + +| Requirement | When Applicable | +|------------|----------------| +| Identity proofing at IAL2 minimum for all government-issued digital credentials | All federal programs issuing digital credentials | +| PIV or PIV-derived credentials for federal employee and contractor access to federal systems | Federal employees and contractors accessing High Value Assets | +| Strong authentication (AAL2 minimum) for all federal applications | All federal agencies | +| Phishing-resistant authentication for all high-value assets | HVAs per OMB M-19-03 | + +--- + +## PIV and CAC in the 800-63B Framework + +The PIV card (FIPS 201) and the Common Access Card (CAC) are **Multi-Factor Cryptographic Devices** that satisfy: +- AAL2 (contact or contactless interface with PIN) +- AAL3 (contact interface with PIN; satisfies verifier impersonation resistance via TLS channel binding or key confirmation) + +PIV-Derived Credentials (PIV-D) issued to mobile devices satisfy AAL2. + +--- + +## Deprecated Practices (SP 800-63B) + +The following practices from older NIST guidance are deprecated in SP 800-63B: + +| Deprecated Practice | Why Deprecated | +|--------------------|---------------| +| Mandatory password expiration (periodic rotation without cause) | Forces users to choose weaker predictable patterns | +| Knowledge-Based Authentication (KBA/KBV) as sole authenticator | KBV data often publicly available; does not constitute possession factor | +| Password complexity rules (upper/lower/number/special) | Shown to reduce entropy and increase predictable substitutions | +| Limiting password characters (excluding special chars) | Reduces entropy | +| Password hints | Reduces security of memorised secret | +| Security questions for account recovery | KBV; same deprecation reasons as KBA | diff --git a/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/authenticator-requirements.md b/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/authenticator-requirements.md new file mode 100644 index 0000000..cb166de --- /dev/null +++ b/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/authenticator-requirements.md @@ -0,0 +1,229 @@ +# Authenticator Requirements — NIST SP 800-63B Rev 3 + +Source: NIST SP 800-63B Rev 3 (June 2017), errata March 2020 + +--- + +## Authenticator Type Definitions + +### 1. Memorised Secret (Password or PIN) + +**Definition**: A secret value that is intended to be chosen and memorised by the user. + +**Requirements**: +- Minimum 8 characters for user-chosen passwords +- Minimum 6 digits for PINs used as a single factor (AAL1 only) +- Maximum length: at least 64 characters must be supported +- All printable ASCII characters and Unicode MUST be accepted +- Spaces MUST be counted when calculating length (leading/trailing spaces may be trimmed for comparison) +- Passwords SHALL be compared in a case-sensitive manner + +**Verifier requirements**: +- Check against a list of commonly-used, expected, or compromised passwords (e.g., HIBP breach lists, dictionary words, context-specific words like the service name) +- Rate limiting or lockout required after repeated failed attempts (NIST does not define exact thresholds; agencies should implement based on risk) +- No truncation of passwords — full character set must be preserved +- Passwords MUST be stored as salted hashes using an approved algorithm (e.g., Argon2, bcrypt, scrypt, or PBKDF2 with SHA-256 and at least 10,000 iterations) +- Temporary passwords (for reset) must be single-use and expire after a short time period + +**What is deprecated (MUST NOT do)**: +- Mandatory periodic rotation without evidence of compromise +- Password complexity rules (mixed case + numbers + special chars combinations) +- Password hints +- Security questions for account recovery as sole mechanism +- Restricting what characters can be used + +--- + +### 2. Look-Up Secrets (Backup Codes) + +**Definition**: Physical or electronic record containing a set of secrets shared between the claimant and the CSP. Examples: printed backup codes, recovery codes. + +**Requirements**: +- At least 112 bits of entropy (or at least 6 characters from a 64-character set; a common implementation is 8-10 alphanumeric characters) +- Each look-up secret must be used only once (single-use) +- Any remaining unused look-up secrets must be invalidated after a new set is issued +- Must be stored hashed at the verifier + +**AAL eligibility**: AAL1 only (count as a single factor — possession) + +--- + +### 3. Out-of-Band Authenticators (OOB) — Includes SMS, Email, Voice + +**Definition**: A separate communications channel (the "out-of-band" device) is used to verify possession. + +**Requirements (for push notifications on dedicated app)**: +- Uniquely addressable device; authenticity of device verified at binding time +- Push notifications require user action to approve (not just passive receipt) + +**SMS/PSTN requirements (RESTRICTED)**: +Because the PSTN is not end-to-end encrypted and SIM-swapping attacks exist, SMS and PSTN-based OOB is designated RESTRICTED at AAL2. Agencies using SMS must: +1. Document the risk in a formal risk assessment +2. Offer subscribers at least one non-restricted alternative (e.g., TOTP app or hardware key) +3. Monitor for evidence that SMS is not longer adequately protecting the application +4. Issue risk notifications to subscribers + +**Email-based OTP**: NOT PERMITTED as an out-of-band authenticator at AAL2. Email is not a "separate channel" for identity verification purposes and is a common attack target. + +--- + +### 4. Single-Factor OTP (TOTP/HOTP Application) + +**Definition**: A software authenticator app (Authenticator app) that generates short-term OTP codes using TOTP (RFC 6238) or HOTP (RFC 4226). + +**Algorithm requirements**: +- TOTP: 30-second time step; X.509-level time synchronisation recommended; validity window: adjacent ±1 step acceptable +- HOTP: Counter-based; must accept at a look-ahead window (SP 800-63B recommends a maximum look-ahead of 10 counter values) +- OTP length: At least 6 digits; 8 digits preferred for increased entropy +- Each OTP code must be single-use; verifier must store last used OTP to prevent reuse + +**Security**: App is locked to the device via a secret seed; seed must be securely provisioned and stored on the device +**FIPS 140**: Not required for AAL2 software OTP apps; required at Level 1 for any software used in an AAL3 scenario + +--- + +### 5. Multi-Factor OTP Device (Hardware Token) + +**Definition**: A hardware device that generates OTP codes, activated by a second factor (typically a PIN or biometric). + +**Examples**: RSA SecurID with PIN, YubiKey OTP mode with PIN + +**Requirements**: +- Must require a PIN or other second activation factor to generate the OTP +- Hardware must resist physical tampering to extract the seed +- FIPS 140 Level 2 physical security required + +**AAL eligibility**: AAL2 (satisfies both factors in a single hardware device) + +--- + +### 6. Single-Factor Cryptographic Software + +**Definition**: Private key stored in software (e.g., in a browser, in a software certificate store). + +**Examples**: Browser TLS client certificates (software key), software-stored FIDO2 keys + +**Requirements**: +- Must use approved cryptographic algorithms (RSA-2048+, EC P-256 or higher) +- Key must be bound to the application (origin, relying party) +- Single-factor only — requires combination with second factor for AAL2 + +**AAL eligibility**: AAL1 only (single factor); AAL2 as second factor combined with memorised secret + +--- + +### 7. Single-Factor Cryptographic Device (Hardware Key) + +**Definition**: A hardware device containing a cryptographic key, activated by a simple user presence check (e.g., button press) without a PIN. + +**Examples**: FIDO2 hardware security key without PIN configured (activation by touch only) + +**Requirements**: +- Hardware must resist extraction of private key +- Must require an explicit user action (button press, card insert) to sign +- FIPS 140 Level 2 physical security required + +**AAL eligibility**: AAL2 as second factor (combined with memorised secret) + +--- + +### 8. Multi-Factor Cryptographic Software + +**Definition**: Private key stored in software, where activation requires a memorised secret or biometric (the second factor is software-internal). + +**Examples**: Software certificate protected by a PIN or passphrase; PIV-derived credential in a locked key container on a mobile device + +**Requirements**: +- Activation secret (PIN/passphrase) must meet memorised secret requirements +- Key storage protected by the OS or secure enclave + +**AAL eligibility**: AAL2 (satisfies both factors within one software authenticator) + +--- + +### 9. Multi-Factor Cryptographic Device (Hardware Token with PIN) + +**Definition**: A hardware device containing a cryptographic key, activated by a PIN or biometric (second factor is presented to the hardware). + +**Examples**: PIV card (FIPS 201), CAC, FIDO2 security key with PIN, YubiKey in FIDO2 mode with configured PIN, smart card + +**Requirements**: +- PIN or biometric is presented directly to the hardware device (not the verifier) +- Hardware must verify the PIN/biometric before releasing the key operation +- FIPS 140 Level 2 overall; Level 3 physical security (for AAL3) +- Verifier impersonation resistance: FIDO2 origin binding or TLS channel binding (for AAL3) + +**AAL eligibility**: AAL2 and AAL3 + +--- + +## Authenticator Binding and Enrollment + +### Initial Binding +At enrollment, the authenticator is bound to the subscriber's identity record. Requirements: +1. Binding must occur in person, or via a secure binding ceremony using an existing, already-enrolled authenticator at the required AAL +2. The binding link (for a one-time enrollment URL) must have a short expiry (10 minutes or less) and be single-use +3. Binding confirmation must be sent to the subscriber's verified address + +### Adding Additional Authenticators +When a subscriber with an existing authenticator wants to add another: +1. Reauthenticate with the existing authenticator at or above the required AAL +2. Verify identity if the new authenticator will replace the existing one (not just supplement it) +3. Issue confirmation to the verified address + +### Authenticator Recovery +If all authenticators are lost: +- Identity reverification at the IAL of the original enrollment is required +- Recovery codes (look-up secrets) may have been issued at enrollment time +- KBA/KBV alone is NOT sufficient for account recovery at AAL2 or higher + +### Authenticator Expiry and Revocation +- Hardware authenticators: must be revocable (CSP must be able to bind a revocation to the subscriber's account) +- Software authenticators: revocation via account disable or explicit de-binding +- PIV cards: revocation via the issuing agency CRL or OCSP + +--- + +## Reauthentication Requirements — Full Table + +| AAL | Inactivity Timeout | Absolute Time Before Reauthentication | Reauthentication Method | +|-----|------------------|--------------------------------------|------------------------| +| AAL1 | 30 days | No absolute limit | Any permitted AAL1 method | +| AAL2 | 30 minutes | 12 hours | Full AAL2 authentication (both factors) | +| AAL3 | 15 minutes | 12 hours | Full AAL3 authentication (hardware + PIN/biometric) | + +For federated sessions: +- The RP sets session timeouts; the IdP sets federation session lifetimes +- RP may request fresh authentication assertions from the IdP at any time +- Passive reauthentication (where available in the protocol) does not reset the inactivity clock + +--- + +## Verifier and CSP Security Requirements + +### Verifier Requirements (applying to all AALs) +- Use approved cryptographic algorithms (FIPS-approved; CNSA algorithms for national security systems) +- Transmit authenticator output over approved-cryptography-protected channel (TLS 1.2+ required; TLS 1.3 recommended) +- Rate limit authentication attempts; implement lockout or exponential backoff +- Notify the subscriber of any authentication event (new device, unexpected location) via a separate channel +- For verified attributes, protect PII per applicable privacy regulations and SP 800-63A requirements + +### CSP Requirements +- Store all authenticator secrets using salted cryptographic hashes +- Protect CSP private keys at the same FIPS 140 level as required by the AAL +- Conduct regular audits of authenticator binding and lifecycle events +- Operate a revocation service accessible to relying parties + +--- + +## Commonly Used Authenticator Combinations by Use Case + +| Use Case | Recommended Authenticator(s) | AAL | +|----------|------------------------------|-----| +| Consumer web application (low risk) | Password | AAL1 | +| Consumer web app (personal data access) | Password + TOTP app | AAL2 | +| Enterprise app (moderate risk) | Password + hardware FIDO2 key (PIN) | AAL2 | +| Federal employee access to non-HVA system | PIV card | AAL2/3 | +| Federal employee access to HVA system | PIV card (contact interface) with TLS binding | AAL3 | +| Mobile device access (federal employee) | PIV-D (Derived PIV) + biometric on device | AAL2 | +| Developer API access | OAuth 2.0 token (short-lived) + client certificate | AAL2 | diff --git a/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/identity-proofing.md b/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/identity-proofing.md new file mode 100644 index 0000000..9093597 --- /dev/null +++ b/plugins/nist-sp-800-63/skills/nist-sp-800-63/references/identity-proofing.md @@ -0,0 +1,228 @@ +# Identity Proofing Reference — NIST SP 800-63A Rev 3 + +Source: NIST SP 800-63A Revision 3 (June 2017), errata March 2020 + +--- + +## Identity Proofing Overview + +Identity proofing is the process by which a Credential Service Provider (CSP) collects and verifies information about a person to bind a real-world identity to a digital account. The strength of the proofing process determines the Identity Assurance Level (IAL). + +**The three phases of identity proofing (SP 800-63A Section 4.2)**: +1. **Resolution**: Collect identifying attributes from the applicant and resolve them to a unique person +2. **Validation**: Validate the collected evidence as genuine and accurate +3. **Verification**: Verify that the validated identity belongs to the applicant in front of the CSP (binding) + +--- + +## Evidence Types and Strength + +SP 800-63A classifies identity evidence into four strength levels: Superior, Strong, Fair, and Weak. Weak evidence is not permitted at IAL2 or IAL3. + +### Superior Evidence + +Evidence is designated Superior if it: +- Is issued by a federal or state government agency +- Contains a photograph +- Includes a machine-readable zone (MRZ) or chip (RFID/contactless IC) with biographical and biometric data +- Uses protective printing features that resist tampering and counterfeiting +- Has a validity period that is currently unexpired + +**Examples of Superior evidence**: +- US Passport or US Passport Card (with NFC chip) +- Foreign passport with MRZ (ICAO 9303 compliant) +- US Permanent Resident Card (Green Card) with RFID chip + +### Strong Evidence + +Evidence is designated Strong if it: +- Is issued by a government agency +- Contains a photograph +- May or may not contain machine-readable features +- Uses standard security printing features + +**Examples of Strong evidence**: +- US Federal or State driver's licence (Real ID compliant or standard) +- US State identification card +- US Military ID card (DD Form 2 — active duty or retired) +- US Uniformed Services Privilege and Identification Card +- Employment authorisation document (Form I-766) +- Tribal identification card (government-issued) + +### Fair Evidence + +Evidence is designated Fair if it: +- Is issued by a government agency or a regulated entity +- Contains biographical attributes +- Does not necessarily contain a photograph + +**Examples of Fair evidence**: +- Voter registration card +- US bank or financial institution account statement (less than 3 months old) +- Utility bill with name and address (less than 3 months old) +- Government-issued professional licence or certificate +- Mortgage or lease agreement (regulated entity) +- Social Security card (without photograph; used as Fair supporting document only) + +### Evidence Combinations Required by IAL + +| IAL | Minimum Evidence Combination | +|-----|----------------------------| +| IAL1 | No evidence required | +| IAL2 | 1 piece of Superior evidence; OR 1 piece of Strong evidence + 2 pieces of Fair evidence | +| IAL3 | 1 piece of Superior evidence AND a biometric comparison against the photo on that evidence using an authoritative database; OR 2 pieces of Strong evidence AND a biometric comparison | + +--- + +## Evidence Validation + +After collecting evidence, the CSP must validate its authenticity. + +### Validation Methods + +| Method | Description | +|--------|-------------| +| **Automated validation** | Machine-readable zone (MRZ) parsed and verified; chip data (e.g., ICAO 9303 NFC) read and verified; barcode on document read and compared to visual data | +| **Visual/physical inspection** | Trained operator examines security features: holograms, colour-shifting inks, raised printing, microprint, UV fluorescence | +| **Database lookup** | Check document data against issuing authority database: AAMVA (driver's licences), USPS (addresses), Social Security Administration (SSN verification) | +| **Third-party service** | Commercial KYC/identity document verification services (only when the service can demonstrate authoritative source access) | + +### Required Validation at IAL2 + +- Check that the document is unexpired +- Validate that the data on the document is consistent (MRZ matches VIZ data) +- Verify against at least one authoritative source (e.g., AAMVA for driver's licences) +- Confirm no indicators of tampering or forgery + +### Required Validation at IAL3 + +- All IAL2 requirements, plus: +- Physical inspection of security features by a trained representative +- Automated chip verification (for chipped documents) +- Comparison of photograph against biometric captured at time of proofing + +--- + +## Identity Verification (Binding to the Real Person) + +After validating evidence, the CSP must verify that the person presenting the evidence is the same person described in it. + +### Verification at IAL2 + +**In-person:** +- A trained operator visually confirms the person matches the photograph on the evidence +- The operator confirms liveness (the person is physically present) + +**Supervised remote (via video):** +- A trained operator on a live video link confirms the person matches the photograph on evidence shown to the camera +- Liveness checks (following the person's movements, asking them to show multiple angles) performed +- Document is verified in real-time via automated scanning if possible + +**Biometric comparison (optional at IAL2):** +- Facial image captured and compared against authoritative source (passport photo, DMV photo) via verified biometric matching algorithm +- If biometric match fails, the proofing session must be terminated + +### Verification at IAL3 + +- In-person only with a trained, authorised operator +- Physical presence confirmed +- Biometric comparison required (fingerprint or facial image) against an authoritative biometric database +- CSP operator records the proofing event with date, operator ID, and outcome + +--- + +## Address Confirmation + +After successful validation and verification, the CSP must confirm the applicant's address. + +### Purpose +Ensures that the person who appeared for proofing also controls the physical address associated with the identity. + +### Methods + +| Method | Description | IAL Applicability | +|--------|-------------|-------------------| +| Enrollment code by postal mail | CSP sends a code to the validated address of record; applicant enters the code to complete enrollment | IAL2 (required if proofing done remotely and address not confirmed via authoritative source) | +| USPS NCOA lookup | CSP queries USPS National Change of Address for the address associated with the identity; confirms address is current | IAL2 (supplemental) | +| In-person address confirmation | Address is confirmed by the operator matching address on physical evidence to applicant's statement | IAL2 and IAL3 (in-person only) | + +**Enrollment code requirements (postal mail)**: +- Minimum 6 characters, randomly generated +- Valid window: up to 5 days after mailing +- Single-use: invalidated after entry +- Only one pending enrollment code at a time per applicant + +--- + +## Knowledge-Based Verification (KBV) Limitations + +KBV (also called KBA — Knowledge-Based Authentication) uses questions derived from personal history or credit bureau records ("What was your first car?", "Which of the following streets have you lived on?"). + +### SP 800-63A KBV Restrictions + +| Requirement | Detail | +|------------|--------| +| Standalone use | KBV alone is NOT sufficient for IAL2 — it may only supplement other proofing steps | +| Static KBV | Prohibited at any IAL (static questions like "What is your mother's maiden name?" are deprecated) | +| Dynamic KBV | Permitted only as supplementary step at IAL2; minimum 4 questions with at most 1 wrong answer permitted | +| Waiting period after failure | If KBV fails: 2 weeks before retry; maximum 3 attempts total | +| Application of KBV | Should only be used when in-person or supervised remote proofing is genuinely impractical; not a default substitution | + +--- + +## Proofing and Privacy + +SP 800-63A requires CSPs to minimise PII collection: + +| Principle | Requirement | +|-----------|------------| +| Data minimisation | Collect only the attributes necessary to complete proofing and bind the identity; do not retain evidence images beyond what is necessary | +| Notice | Inform applicants what data is collected, why, how it is stored, and who it is shared with | +| Use limitation | PII collected during proofing must not be used for any purpose other than identity proofing, authentication, and authorisation | +| Retention limits | Evidence images: CSP should determine minimum necessary retention period; raw biometrics: retain only as long as enrollment binding requires | +| Third-party sharing | CSP must not share PII collected during proofing with other agencies or commercial entities unless required by law, and without subscriber consent | + +--- + +## Failed Identity Proofing + +If identity proofing fails: + +| Scenario | Required Action | +|---------|----------------| +| Document verification fails (suspected forgery) | Terminate session; do not inform the applicant of specific failure reason (to prevent social engineering); report to appropriate authority if fraud suspected | +| Biometric comparison fails | Up to 3 attempts; if all fail, terminate session; offer alternative in-person proofing channel | +| KBV fails | 2-week waiting period; maximum 3 total attempts | +| Applicant withdraws | Terminate session; purge all PII collected during the session per retention policy | + +--- + +## Special Proofing Scenarios + +### Remote Proofing for Mobile Applicants + +For supervised remote proofing via mobile device: +- Document scanning may use the device camera; all scanned images must be transmitted only over TLS-protected channels +- Liveness detection algorithm must be used or the live operator must assess liveness via video +- The operator must be able to ask the applicant to perform physical tasks to confirm liveness (look left/right, hold document next to face) + +### Proofing Minors + +SP 800-63A does not provide specific minor-proofing requirements; agencies must comply with COPPA (Children's Online Privacy Protection Act) and any applicable state laws when proofing minors. In practice, many federal programmes require the legal guardian to complete identity proofing on behalf of a minor. + +### Proofing for People Without Government-Issued ID + +Where an applicant cannot provide Superior or Strong evidence, CSPs may: +- Accept a combination of authoritative documents sufficient to meet Fair evidence thresholds +- Use IAL1 if the service can be delivered without identity proofing +- Offer alternative access channels (in-person at a field office) if the agency can perform a different proofing exception process +- Note: There is no "equivalency" exception in SP 800-63A; the evidence requirements are normative + +--- + +## Notification of Proofing + +After successful proofing, the CSP must send a notification to the applicant at the verified address (postal or email, as appropriate): +- Confirm that identity proofing was completed +- Provide a means for the applicant to report if they did not initiate the proofing +- Include a reference number for the enrollment event diff --git a/plugins/pci-compliance/.claude-plugin/plugin.json b/plugins/pci-dss/.claude-plugin/plugin.json similarity index 54% rename from plugins/pci-compliance/.claude-plugin/plugin.json rename to plugins/pci-dss/.claude-plugin/plugin.json index e7a7369..a6889d1 100644 --- a/plugins/pci-compliance/.claude-plugin/plugin.json +++ b/plugins/pci-dss/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { - "name": "pci-compliance", - "description": "PCI DSS v4.0.1 compliance advisor \u2014 CDE scoping, SAQ selection, gap assessments, control implementation guidance, QSA audit preparation, and remediation planning.", - "version": "0.3.0", + "name": "pci-dss", + "description": "PCI DSS all-versions compliance advisor covering v1.0 through v4.0.1 \u2014 CDE scoping, SAQ selection, gap assessments across all versions, control implementation guidance, QSA audit preparation, v3.2.1 to v4.0 migration, and remediation planning.", + "version": "1.0.0", "author": { "name": "Hemant Naik", "email": "hemant.naik@gmail.com" @@ -11,12 +11,16 @@ "license": "MIT", "keywords": [ "pci-dss", + "pci-dss-v4", + "pci-dss-v3", "pci-compliance", "payment-security", "cardholder-data", "cde", "saq", "qsa", + "roc", + "aoc", "grc" ] } \ No newline at end of file diff --git a/plugins/pci-compliance/skills/pci-compliance/SKILL.md b/plugins/pci-dss/skills/pci-dss/SKILL.md similarity index 52% rename from plugins/pci-compliance/skills/pci-compliance/SKILL.md rename to plugins/pci-dss/skills/pci-dss/SKILL.md index 814a3f9..ee146bd 100644 --- a/plugins/pci-compliance/skills/pci-compliance/SKILL.md +++ b/plugins/pci-dss/skills/pci-dss/SKILL.md @@ -1,37 +1,73 @@ --- -name: pci-compliance +name: pci-dss description: > - Expert PCI DSS compliance advisor covering PCI DSS v4.0.1 (current) and v4.0. Use this skill - whenever a user asks about PCI DSS, payment card security, cardholder data protection, CDE - scoping, SAQ types (A, A-EP, B, B-IP, C, C-VT, P2PE, D), ROC, AOC, QSA assessments, ASV - scans, merchant levels, service provider levels, network segmentation, penetration testing, - tokenisation, encryption of PAN data, or any of the 12 PCI DSS requirements. Also trigger for - questions like "are we PCI compliant?", "how do I scope my CDE?", "which SAQ applies to us?", - "what changed in PCI DSS v4.0?", "how do I prepare for a QSA audit?", or any request involving - payment data security, cardholder data environment, or PCI certification readiness. + Expert PCI DSS compliance advisor covering all versions from v1.0 (2004) through v4.0.1 + (current, June 2024). Use this skill whenever a user asks about PCI DSS, any PCI DSS version + (v1.x, v2.0, v3.0, v3.1, v3.2, v3.2.1, v4.0, v4.0.1), payment card security, cardholder data + protection, CDE scoping, SAQ types (A, A-EP, B, B-IP, C, C-VT, P2PE, D), ROC, AOC, QSA + assessments, ASV scans, merchant levels, service provider levels, network segmentation, + penetration testing, tokenisation, encryption of PAN data, or any of the 12 PCI DSS + requirements. Also trigger for questions like "are we PCI compliant?", "how do I scope my CDE?", + "which SAQ applies to us?", "what changed in PCI DSS v4.0?", "how do I prepare for a QSA audit?", + "what version of PCI DSS should we use?", "how do we migrate from v3.2.1 to v4.0?", or any + request involving payment data security, cardholder data environment, PCI certification + readiness, or legacy PCI DSS version compliance. --- -# PCI DSS Compliance Skill +# PCI DSS Compliance Skill — All Versions -You are an expert PCI DSS compliance advisor and QSA-trained consultant assisting **security, compliance, and engineering teams** that handle payment card data. You have deep knowledge of **PCI DSS v4.0.1** (June 2024 — current) and **PCI DSS v4.0** (March 2022), and can help with CDE scoping, gap assessments, SAQ selection, control implementation guidance, QSA audit preparation, and remediation planning. +You are an expert PCI DSS compliance advisor and QSA-trained consultant assisting **security, compliance, and engineering teams** that handle payment card data. You have deep knowledge of **all published PCI DSS versions** from v1.0 (December 2004) through **v4.0.1** (June 2024 — current), and can help with CDE scoping, gap assessments, SAQ selection, control implementation guidance, QSA audit preparation, version migration, and remediation planning across all versions. + +**Default to PCI DSS v4.0.1** (current) unless the user specifies a different version or context (e.g., a legacy environment running under a pre-v4.0 assessment). + +Consult `references/pci-dss-version-history.md` for the complete version timeline, key changes per version, and which versions are still operationally relevant. + +--- + +## Version Guidance + +| Version | Released | Status | Notes | +|---------|----------|--------|-------| +| v1.0 | December 2004 | Retired | First combined standard; historical reference only | +| v1.1 | September 2006 | Retired | PCI SSC formation; wireless security additions | +| v1.2 | October 2008 | Retired | WEP eliminated; structural clarifications | +| v1.2.1 | July 2009 | Retired | Minor corrections only | +| v2.0 | October 2010 | Retired | Virtualisation guidance; clarification-focused | +| v3.0 | November 2013 | Retired | Business-as-usual security; POS skimming protections | +| v3.1 | April 2015 | Retired | SSL/early TLS removal required | +| v3.2 | April 2016 | Retired | MFA expansion; service provider obligations added | +| v3.2.1 | May 2018 | **Retired March 31, 2024** | Last v3 release; common legacy gap-analysis reference | +| v4.0 | March 2022 | Superseded by v4.0.1 | Customised Approach introduced; future-dated requirements | +| **v4.0.1** | **June 2024** | **CURRENT** | Minor errata corrections; no new controls | + +**When a user does not specify a version**: use **v4.0.1**. +**When a user references v3.2.1**: acknowledge it is retired (March 31, 2024) and all current assessments must use v4.0.1; provide v3.2.1 guidance only for historical gap-analysis comparisons or legacy documentation purposes. +**When a user references any version prior to v3.2.1**: acknowledge it as historical/retired and explain that only v4.0.1 applies to any live compliance assessment today. + +Consult `references/pci-dss-version-history.md` for full per-version change summaries and milestone dates. +Consult `references/pci-dss-v3-controls.md` for the complete v3.2.1 requirement structure (used when assisting legacy migration work). +Consult `references/pci-dss-v4-changes.md` for the detailed v3.2.1 → v4.0/v4.0.1 migration guide. --- ## How to Respond -Always clarify PCI DSS version (v4.0.1 is current; v4.0 also valid; v3.2.1 retired March 31, 2024). Default to **v4.0.1** if unspecified. +Always clarify PCI DSS version in your response. State which version is current (v4.0.1) and which the user is working with. If working with a retired version, note its retirement date. Match your output to the task type: | Task | Output Format | |------|--------------| -| Gap assessment | Table: Req # | Control | Status | Gap | Evidence Needed | Priority | +| Gap assessment | Table: Req # \| Control \| Status \| Gap \| Evidence Needed \| Priority; include version column if cross-version | | SAQ selection | Decision tree + recommended SAQ type with rationale | | CDE scoping | Narrative + scoping diagram description + in-scope system list | -| Control guidance | Structured: Requirement → What to Implement → Evidence → Audit Tips | -| Policy generation | Full structured policy document with PCI DSS control citations | -| Remediation roadmap | Prioritised action table: Issue | Req # | Action | Owner | Timeline | -| General question | Clear, concise prose with requirement number citations | +| Control guidance | Structured: Requirement → What to Implement → Evidence → Audit Tips; note version differences | +| Policy generation | Full structured policy document with PCI DSS control citations and version applicability | +| Remediation roadmap | Prioritised action table: Issue \| Req # \| Version \| Action \| Owner \| Timeline | +| Version comparison | Side-by-side table: Requirement \| v3.2.1 \| v4.0.1 \| Change Type | +| Migration planning | Gap table for v3.2.1 → v4.0.1 specifically, with mandatory-from dates | +| Legacy assessment | Gap table structured for the specified version; flag retirement status | +| General question | Clear, concise prose with requirement number and version citations | --- @@ -48,7 +84,8 @@ PCI DSS v4.0.1 organises its 12 requirements under 6 overarching goals: | **Regularly Monitor and Test Networks** | 10, 11 | Logging and monitoring; security testing | | **Maintain an Information Security Policy** | 12 | Organizational policy and programs | -Consult `references/pci-dss-requirements.md` for all 12 requirements with key sub-controls and evidence requirements. +Consult `references/pci-dss-requirements.md` for all 12 requirements with key sub-controls and evidence requirements under v4.0.1. +Consult `references/pci-dss-v3-controls.md` for the v3.2.1 control set when performing legacy assessments or migration gap analysis. --- @@ -111,6 +148,8 @@ Consult `references/pci-dss-saq-guide.md` for the full SAQ selection decision tr | **D (Merchant)** | All other merchants not covered above | ~340 | | **D (Service Provider)** | All service providers eligible for SAQ | ~340 | +**SAQ version note**: SAQ types and content evolved across PCI DSS versions. SAQ A-EP was introduced in v2.0; SAQ P2PE in v3.0; SAQ B-IP in v3.0. The control counts above reflect v4.0.1. + --- ## Core Workflows @@ -130,43 +169,60 @@ When asked to help scope the CDE: - Cloud components that touch CHD (even briefly) → in scope - Third-party service providers that could impact CDE security → must be PCI-compliant -### 2. Gap Assessment +### 2. Gap Assessment (v4.0.1) When asked to assess compliance against PCI DSS v4.0.1: 1. Ask for: merchant/SP level, in-scope systems, existing controls, SAQ type or ROC requirement -2. Produce a table for each of the 12 requirements with sub-controls +2. Produce a table for each of the 12 requirements with sub-controls using `references/pci-dss-requirements.md` 3. For each control: **Status** (Compliant / Partial / Non-Compliant / N/A), **Gap Description**, **Evidence Needed** 4. Highlight critical findings (any non-compliant SAD storage, lack of MFA, no ASV scans) 5. Offer remediation roadmap **Status definitions:** -- ✅ Compliant — control is fully in place and operating effectively with evidence -- 🟡 Partial — some controls exist but gaps, exceptions, or inconsistencies remain -- ❌ Non-Compliant — control not implemented; compensating control or remediation required +- Compliant — control is fully in place and operating effectively with evidence +- Partial — some controls exist but gaps, exceptions, or inconsistencies remain +- Non-Compliant — control not implemented; compensating control or remediation required - N/A — not applicable to this environment with documented justification -### 3. SAQ Selection +### 3. Gap Assessment (Legacy Version) +When asked to assess compliance against a specific older version (e.g., v3.2.1): +1. Acknowledge the version is retired and note the retirement date +2. Confirm the user's purpose (historical documentation, legacy migration planning, gap comparison) +3. Use `references/pci-dss-v3-controls.md` for v3.2.1 control structure +4. Produce the gap table against the specified version's requirements +5. Always recommend planning migration to v4.0.1 and note what new requirements will apply + +### 4. Version Migration Planning (v3.2.1 → v4.0.1) +When asked to plan migration from v3.2.1 to v4.0.1: +1. Consult `references/pci-dss-v4-changes.md` for the full change log +2. Ask: Has the organisation already addressed the "future-dated" requirements that became mandatory March 31, 2025? +3. Produce a migration gap table: Requirement | Change Type | v3.2.1 State | v4.0.1 Requirement | Gap | Priority +4. Group by: New requirements (no equivalent in v3.2.1), Extended requirements (scope expanded), Changed thresholds (e.g., password length, session timeouts) +5. Identify critical gaps first: Req 8.4.2 (MFA), Req 6.4.3 (payment page scripts), Req 5.4.1 (anti-phishing), Req 10.4.1.1 (automated log review) +6. Produce a phased remediation roadmap + +### 5. SAQ Selection When asked which SAQ applies: 1. Ask: Merchant or service provider? How are card transactions accepted? (card-present, CNP, e-commerce, MOTO) 2. Ask: Is all cardholder data processing outsourced to a PCI-compliant third party? 3. Ask: Are P2PE validated devices used exclusively? 4. Ask: Is there any card-present processing? -5. Walk through the decision logic to select the correct SAQ type +5. Walk through the decision logic in `references/pci-dss-saq-guide.md` to select the correct SAQ type 6. Explain what controls the selected SAQ covers and what is excluded from scope -### 4. Control Implementation Guidance +### 6. Control Implementation Guidance For any PCI DSS requirement or sub-control, structure your response as: -**Requirement [X.X]: [Name]** +**Requirement [X.X]: [Name]** (PCI DSS vX.X) - **What it requires**: Plain-language description - **How to implement**: Concrete, actionable steps - **Evidence for QSA**: What a QSA or ISA will look for during assessment - **Common gaps**: What organisations typically miss or get wrong -- **v4.0 note** (if changed from v3.2.1): What is new or different +- **Version note** (if the requirement changed across versions): What is different in each version -### 5. Policy Generation +### 7. Policy Generation When generating PCI DSS-aligned policies: -- Include: Purpose, Scope, Policy Statement, Roles & Responsibilities, Standards/Procedures, Review Cycle, PCI DSS Requirement references -- Include document control block: Version | Author | Approved By | Date | Next Review +- Include: Purpose, Scope, Policy Statement, Roles & Responsibilities, Standards/Procedures, Review Cycle, PCI DSS Requirement references (cite version) +- Include document control block: Version | Author | Approved By | Date | Next Review | PCI DSS Version Applicable **Common PCI-aligned policies:** | Policy | Primary Requirement(s) | @@ -174,11 +230,73 @@ When generating PCI DSS-aligned policies: | Network Security Control Policy | Req 1 | | System Configuration/Hardening Policy | Req 2 | | Data Retention and Disposal Policy | Req 3 | -| Cryptography and Key Management Policy | Req 3.5, 4 | +| Cryptography and Key Management Policy | Req 3.5–3.7, 4 | | Vulnerability Management Policy | Req 5, 6 | | Secure Development Policy (SDLC) | Req 6 | | Access Control Policy | Req 7 | -| User Authentication and Password Policy | Req 8 | +| User Authentication and MFA Policy | Req 8 | +| Physical Security Policy | Req 9 | +| Audit Log Management Policy | Req 10 | +| Penetration Testing and ASV Scan Policy | Req 11 | +| Information Security Policy | Req 12 | +| Incident Response Plan | Req 12.10 | +| Third-Party Service Provider (TPSP) Management Policy | Req 12.8–12.9 | +| Payment Page Security Policy (e-commerce) | Req 6.4.3, 11.6.1 | + +--- + +## Key v4.0.1 Changes from v3.2.1 (Summary) + +Consult `references/pci-dss-v4-changes.md` for the full change log. + +| Topic | v3.2.1 | v4.0 / v4.0.1 | Mandatory From | +|-------|--------|--------------|----------------| +| Compliance approach | Defined only | + Customised Approach with TRA | March 2022 | +| MFA scope | Non-console admin + remote access | All access into the CDE (Req 8.4.2) | March 31, 2025 | +| Password minimum length | 7 characters | 12 characters (or 8 if system cannot support 12) | March 31, 2025 | +| Anti-phishing | Not required | Automated technical solution (Req 5.4.1) | March 31, 2025 | +| Payment page scripts | Limited guidance | Inventory + integrity controls (Req 6.4.3, 11.6.1) | March 31, 2025 | +| Targeted Risk Analysis | Informal | Formalised; required for customised + flexible controls | March 2022 | +| Automated log review | Manual acceptable | Automated mechanism required (Req 10.4.1.1) | March 31, 2025 | +| Penetration testing | Req 11.3 | Enhanced; segmentation verification required | March 2022 | +| Software inventory (SBOM) | Not required | Required for bespoke software (Req 6.3.2) | March 31, 2025 | +| Critical control failure monitoring | Not required | Monitoring + response required (Req 10.7) | March 31, 2025 | +| v3.2.1 retirement | — | Retired March 31, 2024 | — | + +--- + +## Compensating Controls + +Available under the **Defined Approach only**. Requirements: +1. Must meet the intent and rigour of the original requirement +2. Must go above and beyond other PCI DSS requirements +3. Must be commensurate with the additional risk from not meeting the original requirement +4. Must be documented with a Compensating Control Worksheet (CCW) in the ROC/SAQ + +Compensating controls are **not available** under the Customised Approach — the Targeted Risk Analysis (TRA) process serves an equivalent function. + +**Version note**: Compensating controls have been available since PCI DSS v1.0. The Customised Approach (alternative to both defined requirements and compensating controls) was introduced in v4.0. + +--- + +## Reference Files + +Load the appropriate reference file based on the task: + +| File | Use When | +|------|----------| +| `references/pci-dss-requirements.md` | Gap assessments, control implementation, QSA prep — all v4.0.1 sub-controls with evidence | +| `references/pci-dss-saq-guide.md` | SAQ selection, SAQ control scope, ROC/AOC/ASV guidance | +| `references/pci-dss-v4-changes.md` | v3.2.1 → v4.0/v4.0.1 migration, new requirement details, future-dated items | +| `references/pci-dss-version-history.md` | Version timeline, per-version changes, version selection guidance | +| `references/pci-dss-v3-controls.md` | Legacy v3.2.1 assessments, migration gap analysis, historical gap-to-v4 comparisons | + +--- + +## Disclaimer + +Outputs from this skill are informational guidance based on publicly available PCI DSS standards published by the PCI Security Standards Council (PCI SSC). Current standard: PCI DSS v4.0.1 (June 2024). This skill does not constitute legal, audit, or professional compliance advice. PCI DSS assessments must be conducted by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) for formal compliance validation. Always verify against the official standard at pcisecuritystandards.org. + | Physical Security Policy | Req 9 | | Audit Log Management Policy | Req 10 | | Penetration Testing and ASV Scan Policy | Req 11 | diff --git a/plugins/pci-compliance/skills/pci-compliance/references/pci-dss-requirements.md b/plugins/pci-dss/skills/pci-dss/references/pci-dss-requirements.md similarity index 100% rename from plugins/pci-compliance/skills/pci-compliance/references/pci-dss-requirements.md rename to plugins/pci-dss/skills/pci-dss/references/pci-dss-requirements.md diff --git a/plugins/pci-compliance/skills/pci-compliance/references/pci-dss-saq-guide.md b/plugins/pci-dss/skills/pci-dss/references/pci-dss-saq-guide.md similarity index 100% rename from plugins/pci-compliance/skills/pci-compliance/references/pci-dss-saq-guide.md rename to plugins/pci-dss/skills/pci-dss/references/pci-dss-saq-guide.md diff --git a/plugins/pci-dss/skills/pci-dss/references/pci-dss-v3-controls.md b/plugins/pci-dss/skills/pci-dss/references/pci-dss-v3-controls.md new file mode 100644 index 0000000..9746c6a --- /dev/null +++ b/plugins/pci-dss/skills/pci-dss/references/pci-dss-v3-controls.md @@ -0,0 +1,386 @@ +# PCI DSS v3.2.1 — Complete Control Structure + +Source: PCI DSS v3.2.1 (PCI Security Standards Council, May 2018) +Note: PCI DSS v3.2.1 was RETIRED on March 31, 2024. No live compliance assessment may be conducted against this version. This reference is provided for: +- Legacy gap-analysis and migration planning (v3.2.1 → v4.0.1) +- Reviewing prior-year assessment documentation +- Understanding the baseline an organisation was compliant against before migrating to v4.0.1 + +For mapping of changes from v3.2.1 to v4.0.1, consult `references/pci-dss-v4-changes.md`. + +--- + +## v3.2.1 Requirement Count Summary + +| Requirement | Title | Sub-Requirements | +|-------------|-------|-----------------| +| 1 | Install and maintain a firewall configuration | ~21 | +| 2 | Do not use vendor-supplied defaults | ~8 | +| 3 | Protect stored cardholder data | ~22 | +| 4 | Encrypt transmission of cardholder data | ~4 | +| 5 | Protect all systems against malware | ~8 | +| 6 | Develop and maintain secure systems | ~22 | +| 7 | Restrict access to system components and cardholder data | ~6 | +| 8 | Identify and authenticate access | ~22 | +| 9 | Restrict physical access | ~15 | +| 10 | Track and monitor all access to network resources | ~15 | +| 11 | Regularly test security systems and processes | ~14 | +| 12 | Maintain a policy that addresses information security | ~20 | +| **Total** | | **~259** | + +--- + +## GOAL 1: Build and Maintain a Secure Network and Systems + +### Requirement 1 — Install and Maintain a Firewall Configuration to Protect Cardholder Data + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 1.1 | Firewall/router configuration standards established and implemented | → Req 1.1, 1.2 (expanded to NSC standards) | +| 1.1.1 | Formal process for approving and testing all network connections | → Req 1.2.2 (change control integration) | +| 1.1.2 | Current network diagram | → Req 1.2.3 (more specific — diagrams must show all data flows) | +| 1.1.3 | Current diagram that shows all cardholder data flows | → Req 1.2.4 (explicit data-flow diagram requirement) | +| 1.1.4 | Requirements for a firewall at each Internet connection | → Merged into Req 1.3 | +| 1.1.5 | Documentation of groups, roles, and responsibilities | → Req 12.1.1 | +| 1.1.6 | Documentation of allowed services/ports with business justification | → Req 1.2.5 | +| 1.1.7 | Firewall and router rule sets reviewed at least every 6 months | → Req 1.2.7 | +| 1.2 | Firewall and router configurations restrict connections | → Req 1.3 | +| 1.2.1 | Restrict inbound and outbound traffic to required services only | → Req 1.3.1, 1.3.2 | +| 1.2.2 | Secure and synchronise router configuration files | → Req 1.2.6 | +| 1.2.3 | Install perimeter firewalls between wireless networks and CDE | → Req 1.3.3 | +| 1.3 | Prohibit direct public access between the Internet and CDE | → Req 1.3, 1.4 | +| 1.3.1 | Implement DMZ to limit inbound traffic | → Req 1.4.1, 1.4.2 | +| 1.3.2 | Limit inbound Internet traffic to IP addresses within DMZ | → Req 1.4.2 | +| 1.3.3 | Anti-spoofing measures | → Req 1.4.3 | +| 1.3.4 | Do not allow outbound traffic from CDE to Internet not needed | → Req 1.3.2 | +| 1.3.5 | Permit only "established" connections back into network | → Req 1.3.1 | +| 1.3.6 | Place system components storing CHD in internal network zone | → Req 1.3.1 | +| 1.3.7 | Disclose private IP addresses to unauthorised parties | → Req 1.4.5 | +| 1.4 | Install personal firewall software on portable computing devices | → Req 1.5.1 | + +### Requirement 2 — Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 2.1 | Vendor defaults changed before installing systems | → Req 2.2.2 | +| 2.1.1 | Wireless environments using vendor defaults changed | → Req 2.3.1 | +| 2.2 | Develop configuration standards for all system components | → Req 2.2 (expanded) | +| 2.2.1 | Implement only one primary function per server | → Req 2.2.3 | +| 2.2.2 | Enable only necessary services protocols, daemons | → Req 2.2.4 | +| 2.2.3 | Implement additional security features for risky protocols | → Req 2.2.5 | +| 2.2.4 | Configure system security parameters to prevent misuse | → Req 2.2.6 | +| 2.2.5 | Remove all unnecessary functionality (scripts, features, subsystems) | → Req 2.2.4 | +| 2.3 | Encrypt all non-console administrative access | → Req 2.2.7 | +| 2.4 | Maintain an inventory of system components in scope | → Req 12.5.1 (scope documentation) | +| 2.5 | Ensure security policies cover all applicable areas | → Req 12.1 | +| 2.6 | Shared hosting providers protect CDE and CHD | → Req 12.8, Appendix A1 | + +--- + +## GOAL 2: Protect Account Data + +### Requirement 3 — Protect Stored Cardholder Data + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 3.1 | Keep cardholder data storage to a minimum; define retention periods | → Req 3.2 | +| 3.2 | Do not store SAD after authorisation | → Req 3.3 | +| 3.2.1 | Do not store full magnetic stripe contents after authorisation | → Req 3.3.1 | +| 3.2.2 | Do not store the card verification code after authorisation | → Req 3.3.1 | +| 3.2.3 | Do not store the personal identification number (PIN) after authorisation | → Req 3.3.1 | +| 3.3 | Mask PAN when displayed (first 6/last 4 maximum) | → Req 3.4.1 | +| 3.4 | Render PAN unreadable anywhere it is stored | → Req 3.5.1 | +| 3.4.1 | Use disk-level or column-level encryption | → Req 3.5.1 (strong cryptography explicit) | +| 3.5 | Describe and implement procedures to protect keys | → Req 3.6 | +| 3.5.1 | Restrict access to cryptographic keys | → Req 3.7.3 | +| 3.5.1.1 (SP only) | Maintain cryptographic architecture description | NEW in v3.2; → removed as standalone in v4.0 | +| 3.5.2 | Store secret and private keys used for encryption of CHD securely | → Req 3.7.2 | +| 3.5.3 | Encrypted keys stored in fewest locations possible | → Req 3.7 | +| 3.6 | Fully document key management processes | → Req 3.7 (significantly expanded) | +| 3.6.1 | Generation of strong cryptographic keys | → Req 3.7.1 | +| 3.6.2 | Secure cryptographic key distribution | → Req 3.7 | +| 3.6.3 | Secure cryptographic key storage | → Req 3.7.2 | +| 3.6.4 | Cryptographic key changes for keys that have reached end of period | → Req 3.7.4 | +| 3.6.5 | Retirement or replacement of keys as deemed necessary | → Req 3.7.4 | +| 3.6.6 | Split knowledge and dual control for manual key management | → Req 3.7.6 | +| 3.6.7 | Prevention of unauthorised substitution of cryptographic keys | → Req 3.7.7 | +| 3.6.8 | Key custodians sign key custodian agreement | → Req 3.7.8 | +| 3.7 | Ensure security policies and operational procedures are documented | → Req 12.1 | + +### Requirement 4 — Encrypt Transmission of Cardholder Data Across Open, Public Networks + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 4.1 | Use strong cryptography and security protocols to safeguard PAN | → Req 4.2.1 (expanded; TLS 1.2+ explicit) | +| 4.1.1 | Ensure wireless networks transmitting cardholder data use strong cryptography | → Req 4.2.1.2 | +| 4.2 | Never send unprotected PANs by end-user messaging technologies | → Req 4.2.2 | +| 4.3 | Ensure security policies and operational procedures are documented | → Req 12.1 | + +--- + +## GOAL 3: Maintain a Vulnerability Management Program + +### Requirement 5 — Protect All Systems Against Malware and Regularly Update Anti-Virus Software or Programs + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 5.1 | Deploy anti-virus software on all systems affected by malware | → Req 5.2 | +| 5.1.1 | Anti-virus programs detect, remove, and protect against all known types of malware | → Req 5.2.2 | +| 5.1.2 | Evaluate systems not commonly affected by malware for current malware threats | → Req 5.2.3 | +| 5.2 | Ensure anti-virus mechanisms are kept current | → Req 5.3.1 | +| 5.3 | Anti-virus mechanisms are actively running and cannot be disabled | → Req 5.3.4, 5.3.5 | +| 5.4 | Ensure security policies and operational procedures are documented | → Req 12.1 | +| — | Anti-phishing | **NEW in v4.0** — Req 5.4.1 (no equivalent in v3.2.1) | + +### Requirement 6 — Develop and Maintain Secure Systems and Applications + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 6.1 | Establish a process to identify security vulnerabilities, using risk-ranking | → Req 6.3.1 | +| 6.2 | Protect all system components from known vulnerabilities | → Req 6.3.3 | +| 6.3 | Develop internal and external software applications securely | → Req 6.2 (expanded) | +| 6.3.1 | Remove development, test, and custom application accounts, user IDs | → Req 6.5.6 | +| 6.3.2 | Review custom code prior to release | → Req 6.2.3 | +| 6.4 | Follow change control processes and procedures | → Req 6.5 (expanded) | +| 6.4.1 | Separate development/test environments from production | → Req 6.5.3 | +| 6.4.2 | Separation of duties between development/test and production | → Req 6.5.4 | +| 6.4.3 | Production data (live PANs) not used for testing or development | → Req 6.5.5 | +| 6.4.4 | Remove test data and accounts before production | → Req 6.5.6 | +| 6.4.5 | Change control procedures for implementing security patches | → Req 6.5.1 | +| 6.4.6 | Upon completion of a significant change, all relevant PCI DSS requirements implemented | → Req 6.5.2 | +| 6.5 | Address common coding vulnerabilities in software development | → Req 6.2.4 | +| 6.5.1 | Injection flaws (SQL injection, LDAP injection, etc.) | → Req 6.2.4 | +| 6.5.2 | Buffer overflow vulnerabilities | → Req 6.2.4 | +| 6.5.3 | Insecure cryptographic storage | → Req 6.2.4 | +| 6.5.4 | Insecure communications | → Req 6.2.4 | +| 6.5.5 | Improper error handling | → Req 6.2.4 | +| 6.5.6 | High risk vulnerabilities identified in vulnerability identification process | → Req 6.2.4 | +| 6.5.7 | Cross-site scripting (XSS) | → Req 6.2.4 | +| 6.5.8 | Improper access control | → Req 6.2.4 | +| 6.5.9 | Cross-site request forgery (CSRF) | → Req 6.2.4 | +| 6.5.10 | Broken authentication and session management | → Req 6.2.4 | +| 6.6 | Address new threats and vulnerabilities for public-facing web apps | → Req 6.4.1, 6.4.2 (WAF) | +| 6.7 | Ensure security policies cover development | → Req 12.1 | +| — | Payment page script integrity | **NEW in v4.0** — Req 6.4.3 (no equivalent in v3.2.1) | +| — | Software Bill of Materials (SBOM) | **NEW in v4.0** — Req 6.3.2 (no equivalent in v3.2.1) | + +--- + +## GOAL 4: Implement Strong Access Control Measures + +### Requirement 7 — Restrict Access to System Components and Cardholder Data by Business Need to Know + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 7.1 | Limit access to system components to only those individuals whose job requires such access | → Req 7.2 | +| 7.1.1 | Define access needs for each role | → Req 7.2.2 | +| 7.1.2 | Restrict access to privileged user IDs to least privileges | → Req 7.2.1 | +| 7.1.3 | Assign access based on individual personnel's job classification and function | → Req 7.2.2 | +| 7.1.4 | Documented approval by authorised parties | → Req 7.2.3 | +| 7.2 | Establish an access control system | → Req 7.3 | +| 7.2.1 | Coverage of all system components | → Req 7.3.1 | +| 7.2.2 | Assignment of privileges to individuals based on job classification | → Req 7.3.2 | +| 7.2.3 | Default "deny-all" setting | → Req 7.3.2 | +| 7.3 | Ensure security policies cover access control | → Req 12.1 | + +### Requirement 8 — Identify and Authenticate Access to System Components + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 8.1 | Define and implement policies for user identification | → Req 8.2 | +| 8.1.1 | Assign all users a unique ID before allowing them to access system components or CHD | → Req 8.2.1 | +| 8.1.2 | Control addition, deletion, and modification of user IDs | → Req 8.2.4 | +| 8.1.3 | Immediately revoke access for any terminated users | → Req 8.2.5 | +| 8.1.4 | Remove/disable inactive user accounts within 90 days | → Req 8.2.6 | +| 8.1.5 | Manage IDs used by vendors/partners to access, support, or maintain system components | → Req 8.2.3 | +| 8.1.6 | Limit repeated access attempts by locking out user ID after not more than 6 attempts | → Req 8.3.4 (changed to 10 attempts in v4.0) | +| 8.1.7 | Set lockout duration to 30 minutes or until admin re-enables | → Req 8.3.4 | +| 8.1.8 | Session idle timeout 15 minutes | → Req 8.2.8 | +| 8.2 | Employ at least one authentication method | → Req 8.3 | +| 8.2.1 | Encrypt all passwords/passphrases during transmission and storage | → Req 8.3.5 | +| 8.2.2 | Verify user identity before modifying any authentication credential | → Req 8.1 | +| 8.2.3 | Passwords/passphrases must meet minimum length of 7 characters | → **Changed in v4.0: 12 characters** (Req 8.3.6) | +| 8.2.4 | Change user passwords/passphrases at least once every 90 days | → Req 8.3.9 (for users without MFA) | +| 8.2.5 | Do not allow an individual to submit a new password if it is the same as previous 4 | → Req 8.3.7 | +| 8.2.6 | Set passwords/passphrases for first use and upon reset | → Req 8.3.5 | +| 8.3 | Secure individual non-consumer authentication | → Req 8.4, 8.5 | +| 8.3.1 | All individual non-consumer user access to CDE requires MFA using at least two of the three authentication factors [SP only in v3.2] | → **Extended in v4.0** — Req 8.4.2 applies to ALL users | +| 8.3.2 | All remote network access from outside the entity originated from users and all third parties must use MFA | → Req 8.3.2 | +| 8.4 | Document and communicate authentication policies and procedures | → Req 8.3.8 | +| 8.5 | Do not use group, shared, or generic IDs, passwords, or other methods | → Req 8.2.2 | +| 8.5.1 | Service providers with remote access to customer premises — each customer gets unique credentials | → Still required; incorporated into Req 8.2.3 | +| 8.6 | Use of other authentication mechanisms such as physical/logical security tokens, smart cards | → Req 8.3 | +| 8.7 | All access to database containing CHD restricted | → Req 7.2.6 | +| 8.8 | Ensure security policies cover authentication | → Req 12.1 | + +### Requirement 9 — Restrict Physical Access to Cardholder Data + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 9.1 | Use appropriate facility entry controls to limit and monitor physical access to systems | → Req 9.2 | +| 9.1.1 | Use video cameras or other access control mechanisms to monitor individual physical access points | → Req 9.2.1 | +| 9.1.2 | Restrict physical access to publicly accessible network jacks | → Req 9.2.4 | +| 9.1.3 | Restrict physical access to wireless access points, gateways, handheld devices | → Req 9.2.3 | +| 9.2 | Develop procedures for all personnel to distinguish between employees and visitors | → Req 9.3 | +| 9.3 | Control physical access for onsite personnel to sensitive areas | → Req 9.3.1 | +| 9.4 | Visitor management procedures | → Req 9.2.2, 9.3.2 | +| 9.4.1 | Visitors authorised before entering areas where CHD is processed or maintained | → Req 9.3.2 | +| 9.4.2 | Visitors given a physical token that expires | → Req 9.3.2 | +| 9.4.3 | Visitors asked to surrender physical token before leaving | → Req 9.3.2 | +| 9.4.4 | Visitor log used to maintain audit trail | → Req 9.3.2 | +| 9.5 | Physically secure all media | → Req 9.4.1 | +| 9.6 | Maintain strict control over the internal or external distribution of any kind of media | → Req 9.4.3, 9.4.4 | +| 9.6.1 | Classify media so sensitivity can be determined | → Req 9.4.2 | +| 9.6.2 | Send media via secure courier | → Req 9.4.3 | +| 9.6.3 | Ensure management approves media moved outside the facility | → Req 9.4.4 | +| 9.7 | Maintain strict control over storage and accessibility of media | → Req 9.4.5 | +| 9.7.1 | Properly maintain invention logs for all media | → Req 9.4.5 | +| 9.8 | Destroy media when no longer needed | → Req 9.4.6, 9.4.7 | +| 9.8.1 | Shred, incinerate, or pulp paper materials | → Req 9.4.6 | +| 9.8.2 | Render cardholder data on electronic media unrecoverable | → Req 9.4.7 | +| 9.9 | Protect devices that capture payment card data via direct physical interaction from tampering | → Req 9.5 (expanded) | +| 9.9.1 | Maintain an up-to-date list of devices | → Req 9.5.1 | +| 9.9.2 | Periodically inspect device surfaces to detect tampering or substitution | → Req 9.5.1 | +| 9.9.3 | Provide training for personnel in areas with POI devices | → Req 9.5.1 | +| 9.10 | Ensure security policies cover physical security | → Req 12.1 | + +--- + +## GOAL 5: Regularly Monitor and Test Networks + +### Requirement 10 — Track and Monitor All Access to Network Resources and Cardholder Data + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 10.1 | Implement audit trails to link all access to system components to individual user | → Req 10.2 | +| 10.2 | Implement automated audit trails for all system components | → Req 10.2 | +| 10.2.1 | All individual user access to cardholder data | → Req 10.2.1 | +| 10.2.2 | All actions by any individual with root or administrative privileges | → Req 10.2.2 | +| 10.2.3 | Access to all audit trails | → Req 10.2.3 | +| 10.2.4 | Invalid logical access attempts | → Req 10.2.4 | +| 10.2.5 | Use of and changes to identification and authentication mechanisms | → Req 10.2.5 | +| 10.2.6 | Initialisation, stopping, or pausing of audit logs | → Req 10.2.6 | +| 10.2.7 | Creation and deletion of system-level objects | → Req 10.2.7 | +| 10.3 | Record audit trail entries for all system components | → Req 10.3 | +| 10.3.1 | User identification | → Req 10.3 | +| 10.3.2 | Type of event | → Req 10.3 | +| 10.3.3 | Date and time | → Req 10.3 | +| 10.3.4 | Success or failure indication | → Req 10.3 | +| 10.3.5 | Origination of event | → Req 10.3 | +| 10.3.6 | Identity or name of affected data, system component, or resource | → Req 10.3 | +| 10.4 | Synchronise all critical system clocks and times | → Req 10.6 | +| 10.4.1 | Critical systems have the correct and consistent time | → Req 10.6.1 | +| 10.4.2 | Time data is protected | → Req 10.6.3 | +| 10.4.3 | Time settings are received from industry-accepted time sources | → Req 10.6.2 | +| 10.5 | Secure audit trails so they cannot be altered | → Req 10.3 (expanded) | +| 10.5.1 | Limit viewing of audit trails to those with job-need | → Req 10.3.2 | +| 10.5.2 | Protect audit trail files from unauthorised modifications | → Req 10.3.1 | +| 10.5.3 | Promptly back up audit trail files to centralised log server | → Req 10.3.3 | +| 10.5.4 | Write logs for external-facing technologies onto a secure, centralised log server | → Req 10.3.3 | +| 10.5.5 | Use file-integrity monitoring or change-detection software on logs | → Req 10.3.4 | +| 10.6 | Review logs and security events for all system components | → Req 10.4 | +| 10.6.1 | Review the following at least daily: security events, logs of all system components | → Req 10.4.2; plus **NEW Req 10.4.1.1**: automated review required | +| 10.6.2 | Review logs of all other system components periodically based on policy | → Req 10.4.2 | +| 10.6.3 | Follow up exceptions and anomalies identified during review process | → Req 10.4.3 | +| 10.7 (SP only) | Implement a process for timely detection and reporting of failures of critical security control systems | → Req 10.7 (extended to ALL entities in v4.0) | +| 10.7.1 (SP only) | Failures of critical security controls — respond within one business day | → Req 10.7.2 | +| 10.8 | Retain audit log history for at least one year | → Req 10.5 | +| 10.9 | Ensure security policies cover monitoring | → Req 12.1 | + +### Requirement 11 — Regularly Test Security Systems and Processes + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 11.1 | Implement processes to test for presence of wireless access points | → Req 11.2 | +| 11.1.1 | Maintain inventory of authorised wireless access points | → Req 11.2.1 | +| 11.1.2 | Incident response procedures for unauthorised wireless access points | → Req 11.2.2 | +| 11.2 | Run internal and external network vulnerability scans at least quarterly | → Req 11.3 | +| 11.2.1 | Quarterly internal vulnerability scans | → Req 11.3.1 | +| 11.2.2 | Quarterly external vulnerability scans via ASV | → Req 11.3.2 | +| 11.2.3 | Perform internal and external scans after any significant change | → Req 11.3.1.3, 11.3.2.1 | +| 11.3 | Implement a methodology for penetration testing | → Req 11.4 (significantly expanded) | +| 11.3.1 | Perform external penetration testing at least annually | → Req 11.4.3 | +| 11.3.2 | Perform internal penetration testing at least annually | → Req 11.4.1 | +| 11.3.3 | Exploitable vulnerabilities found during pen testing corrected and re-tested | → Req 11.4.4 | +| 11.3.4 | Segmentation controls tested at least annually to confirm CDE isolation | → Req 11.4.5 | +| 11.3.4.1 (SP only) | SP with segmentation of multi-tenant environments — test every 6 months | → Req 11.4.6 | +| 11.4 | Use intrusion-detection and/or intrusion-prevention techniques | → Req 11.5 | +| 11.4.1 (new v3.2) | Detect and alert on/prevent covert malware communications channels | → Req 11.5 | +| 11.5 | Deploy a change-detection mechanism to alert personnel | → Req 11.5.2 | +| 11.5.1 | Implement a process to respond to any alerts generated by the change-detection solution | → Req 11.5.2 | +| 11.6 | Ensure security policies cover testing | → Req 12.1 | +| — | Payment page tamper detection | **NEW in v4.0** — Req 11.6.1 (no equivalent in v3.2.1) | + +--- + +## GOAL 6: Maintain an Information Security Policy + +### Requirement 12 — Maintain a Policy That Addresses Information Security for All Personnel + +| Sub-Req | Description | v4.0.1 Equivalent / Change Note | +|---------|-------------|--------------------------------| +| 12.1 | Establish, publish, maintain, and distribute a security policy | → Req 12.1 | +| 12.1.1 | Review security policy at least annually | → Req 12.1.1 | +| 12.2 | Implement a risk-assessment process | → Req 12.3 | +| 12.3 | Develop usage policies for critical technologies | → Req 12.3.1 | +| 12.4 | Ensure security policy and procedures clearly define security responsibilities | → Req 12.1.1 | +| 12.4.1 (SP only) | Executive management establish responsibility for protection of CHD | → Req 12.4.1, 12.4.2 (extended to all entities in v4.0) | +| 12.4.2 (SP only) | Reviews performed at least quarterly | → Req 12.11 (SP only) still in v4.0 | +| 12.5 | Assign to an individual or team IT security responsibilities | → Req 12.1.1 | +| 12.5.1 | Establish, document, and distribute security policies and procedures | → Req 12.1 | +| 12.5.2 | Monitor and analyse security alerts and information | → Req 12.5 | +| 12.5.2.1 (SP only) | Document and confirm PCI DSS scope at least every 6 months | → Req 12.5.2.1 (extended to annually for all in v4.0) | +| 12.5.3 | Establish, document, and distribute security incident response and escalation procedures | → Req 12.10 | +| 12.5.4 | Administer user accounts, including additions, deletions, and modifications | → Req 8.2.4 | +| 12.5.5 | Monitor and control all access to data | → Req 10.2 | +| 12.6 | Implement a formal security awareness program | → Req 12.6 | +| 12.6.1 | Educate personnel upon hire and at least annually thereafter | → Req 12.6.2 | +| 12.6.2 | Require personnel to acknowledge at least annually | → Req 12.6.3 | +| 12.7 | Screen potential personnel prior to hire | → Req 12.7 | +| 12.8 | Maintain and implement policies and procedures to manage service providers | → Req 12.8 (expanded) | +| 12.8.1 | Maintain a list of service providers | → Req 12.8.1 | +| 12.8.2 | Maintain a written agreement that includes an acknowledgement | → Req 12.8.2 | +| 12.8.3 | Ensure there is an established process for engaging service providers | → Req 12.8.3 | +| 12.8.4 | Maintain a programme to monitor service providers' PCI DSS compliance status at least annually | → Req 12.8.4 | +| 12.8.5 | Maintain information about which PCI DSS requirements are managed by each service provider | → Req 12.8.5 | +| 12.9 | Service providers acknowledge in writing their responsibility | → Req 12.9.1 | +| 12.9.1 (SP only) | Service providers acknowledge responsibility in writing | → Req 12.9.2 (SP acknowledgement now more detailed) | +| 12.10 | Implement an incident response plan | → Req 12.10 (expanded with new sub-requirements) | +| 12.10.1 | Create the incident response plan | → Req 12.10.1 | +| 12.10.2 | Test the plan at least annually | → Req 12.10.2 | +| 12.10.3 | Designate specific personnel to be available on a 24/7 basis | → Req 12.10.3 | +| 12.10.4 | Provide appropriate training to staff with security breach responsibilities | → Req 12.10.4 | +| 12.10.4.1 | Train IR personnel at least every 12 months | **NEW in v4.0** — Req 12.10.4.1 (formalises frequency) | +| 12.10.5 | Include alerts from security monitoring systems | → Req 12.10.5 | +| 12.10.6 | Develop a process to modify and evolve the incident response plan | → Req 12.10.6 | +| — | IR procedure for unexpected PAN location | **NEW in v4.0** — Req 12.10.7 | +| 12.11 (SP only) | Reviews performed at least quarterly | → Req 12.11 | + +--- + +## v3.2.1 vs v4.0.1 — Notable Threshold Differences + +| Item | v3.2.1 Value | v4.0.1 Value | +|------|-------------|-------------| +| Minimum password length | 7 characters | 12 characters (or 8 if system cannot support 12) | +| Account lockout threshold | 6 attempts | 10 attempts | +| MFA scope | Non-console admin + remote access | All access into the CDE | +| Log review | Manual daily review acceptable | Automated mechanism required (Req 10.4.1.1) | +| Anti-phishing requirement | None | Automated technical solution required (Req 5.4.1) | +| Payment page script controls | No explicit requirement | Script inventory + integrity controls mandatory (Req 6.4.3, 11.6.1) | +| Penetration testing — segmentation | At least annually | At least annually + 6-monthly for multi-tenant SPs | +| TPSP compliance monitoring | At least annually (12.8.4) | At least annually (unchanged) | +| Scope verification frequency | At least annually | At least annually; every 6 months for multi-tenant SPs | +| Software inventory (SBOM) | None | Required for bespoke software (Req 6.3.2) | +| Targeted Risk Analysis | Not formalised | Formalised; required for customised controls | + +--- + +## v3.2.1 SAQ Types — Version Note + +All SAQ types in v3.2.1 map directly to v4.0.1 equivalents (SAQ names unchanged). However, the control counts and specific requirements within each SAQ were updated in v4.0/v4.0.1: +- New requirements added (e.g., 6.4.3, 8.4.2, 5.4.1, 11.6.1) may apply to SAQ A-EP, SAQ C, and SAQ D +- SAQ A eligibility criteria unchanged +- SAQ P2PE eligibility criteria unchanged (still requires PCI-listed P2PE solution) + +Organisations completing SAQs must use the v4.0/v4.0.1 SAQ documents — the v3.2.1 SAQ documents are retired. diff --git a/plugins/pci-compliance/skills/pci-compliance/references/pci-dss-v4-changes.md b/plugins/pci-dss/skills/pci-dss/references/pci-dss-v4-changes.md similarity index 100% rename from plugins/pci-compliance/skills/pci-compliance/references/pci-dss-v4-changes.md rename to plugins/pci-dss/skills/pci-dss/references/pci-dss-v4-changes.md diff --git a/plugins/pci-dss/skills/pci-dss/references/pci-dss-version-history.md b/plugins/pci-dss/skills/pci-dss/references/pci-dss-version-history.md new file mode 100644 index 0000000..31c9211 --- /dev/null +++ b/plugins/pci-dss/skills/pci-dss/references/pci-dss-version-history.md @@ -0,0 +1,362 @@ +# PCI DSS — Complete Version History + +Sources: +- PCI Security Standards Council (PCI SSC): https://www.pcisecuritystandards.org/document_library/ +- PCI DSS Summary of Changes documents (each version): https://www.pcisecuritystandards.org +- PCI SSC press releases and blog; PCI DSS v4.0.1 (June 2024) + +--- + +## Overview + +PCI DSS (Payment Card Industry Data Security Standard) is a global standard governing the security of systems that store, process, or transmit payment card data. It was created through a collaboration of the five major card brands (Visa, MasterCard, American Express, Discover, JCB) and is administered by the **PCI Security Standards Council (PCI SSC)**, which was founded in September 2006. + +Before the PCI SSC was established, each card brand maintained its own security programme: +- Visa: Cardholder Information Security Programme (CISP) +- MasterCard: Site Data Protection (SDP) +- American Express: Data Security Operating Policy (DSOP) +- Discover: Information Security and Compliance (DISC) +- JCB: Data Security Programme (JDSP) + +PCI DSS v1.0 unified these programmes into a single standard. + +**Current version**: PCI DSS v4.0.1 (June 2024) +**All current assessments must use v4.0.1** — no earlier version is valid for a live compliance assessment as of March 31, 2024. + +--- + +## Complete Version Timeline + +| Version | Published | Retired | Key Focus | +|---------|-----------|---------|-----------| +| v1.0 | December 2004 | Retired | First unified standard; 12 requirements established | +| v1.1 | September 2006 | Retired | PCI SSC formation; wireless and application security additions | +| v1.2 | October 2008 | Retired | Strengthened wireless; WEP deprecated; structural clarifications | +| v1.2.1 | July 2009 | Retired | Minor corrections; no new requirements | +| v2.0 | October 2010 | Retired | Virtualisation guidance; clarifications; risk-based assessment language | +| v3.0 | November 2013 | Retired | Business-as-usual security; POI device skimming protections | +| v3.1 | April 2015 | Retired | SSL/TLS 1.0 deprecation mandated | +| v3.2 | April 2016 | Retired | MFA expansion; service provider-specific requirements added | +| v3.2.1 | May 2018 | **March 31, 2024** | TLS migration clarification; last v3.x release | +| v4.0 | March 2022 | Superseded June 2024 | Customised Approach; outcomes-based; future-dated requirements | +| **v4.0.1** | **June 2024** | **CURRENT** | Errata corrections to v4.0; no new requirements | + +--- + +## PCI DSS v1.0 (December 2004) + +**Status**: Retired +**Published by**: Visa, MasterCard, American Express, Discover, JCB (jointly — pre-PCI SSC) + +### What it established +PCI DSS v1.0 unified five separate card brand security programmes into a single standard for the first time. It established the foundational architecture still present in all subsequent versions: + +- **12 requirements** grouped under **6 goals** (same structure maintained today) +- **6 goals**: Build and Maintain a Secure Network; Protect Cardholder Data; Maintain a Vulnerability Management Program; Implement Strong Access Control Measures; Regularly Monitor and Test Networks; Maintain an Information Security Policy +- The concept of the **Cardholder Data Environment (CDE)** as a scoping boundary +- Prohibition on storing sensitive authentication data (CVV, PIN block, full magnetic stripe) after authorisation +- Requirement for quarterly external and internal vulnerability scans +- Requirement for annual penetration testing +- Network security: firewalls between untrusted networks and CDE +- Requirement to use strong cryptography for cardholder data storage and transmission + +### Key limitations at v1.0 +- Limited specificity on wireless security +- No formalised SAQ programme (self-assessment questionnaires were basic) +- No virtualisation guidance +- Limited guidance on service providers and third-party relationships + +--- + +## PCI DSS v1.1 (September 2006) + +**Status**: Retired +**Published by**: PCI SSC (newly formed) + +### Key changes from v1.0 +- Published as the first standard under the newly formed **PCI Security Standards Council** (September 2006) +- Added guidance on **application firewalls** for public-facing web applications as an option to address application-layer attacks (early predecessor to WAF requirement) +- Strengthened wireless security requirements — clarified requirements for wireless access points in the CDE +- Codified the role of the **Qualified Security Assessor (QSA)** and **Approved Scanning Vendor (ASV)** programmes +- Introduced the formal **SAQ programme** (4 SAQ types initially: A, B, C, D) +- Clarified scope and applicability for service providers vs merchants + +--- + +## PCI DSS v1.2 (October 2008) + +**Status**: Retired + +### Key changes from v1.1 +- **Wireless security strengthened**: Eliminated WEP (Wired Equivalent Privacy) as an acceptable wireless encryption protocol. WEP was deemed cryptographically broken. Required WPA or stronger (802.11i/WPA2) +- Requirement to change default wireless encryption keys at installation +- Clarified requirement to not use vendor-supplied defaults (Req 2.1) — expanded guidance on what constitutes a "vendor default" +- Improved physical security guidance for POI devices (early version of what became Req 9.9) +- Refined vulnerability scanning requirements (internal and external) +- Clarified that all system components with a connection to the CDE are in scope (connected-to criterion formalised) +- Removed ambiguous language and improved consistency throughout + +--- + +## PCI DSS v1.2.1 (July 2009) + +**Status**: Retired + +### Key changes from v1.2 +- Corrections to typographical errors and ambiguous language in v1.2 +- No new requirements added +- No substantive technical changes + +--- + +## PCI DSS v2.0 (October 2010) + +**Status**: Retired + +### Key changes from v1.2.1 +- **Virtualisation guidance added**: Addressed systems sharing a physical host — if virtual machines and virtual components are part of the CDE, they are in scope. Clarified that hypervisors and management planes are in scope if they impact CDE security +- **Clarification-focused revision**: Primary goal was to clarify intent of existing requirements, not add new ones +- Strengthened scoping guidance: confirmed that all components in the CDE network segment are in scope unless adequate segmentation is in place +- Reinforced the requirement to document all allowed ports and services with a business justification +- Enhanced guidance on penetration testing methodology — confirmed both internal and external testing required +- Clarified that wireless networks that interact with the CDE or transmit cardholder data are in scope regardless of physical location +- Updated SAQ types: introduced SAQ A-EP concept precursor; refined eligibility criteria + +--- + +## PCI DSS v3.0 (November 2013) + +**Status**: Retired + +### Key changes from v2.0 + +**Structural theme**: Shift toward "security as a business-as-usual activity" — requirements framed to promote embedding security into daily business operations rather than treating compliance as a point-in-time exercise. + +**Major new requirements:** +- **Req 9.9**: Protect devices that capture payment card data via direct physical interaction from tampering and substitution. Merchants required to maintain a list of POI devices, inspect devices regularly, and train staff to detect tampering — a direct response to the dramatically increased incidence of card skimming +- **Req 11.3**: Penetration testing requirements significantly clarified. Required both internal and external penetration testing; required testing after significant infrastructure or application changes; introduced the concept of segmentation validation (testing that CDE isolation controls work) +- **Req 12.8.5**: Requirements for managing service providers — organisations must maintain a list of all service providers with whom they share cardholder data, and have a written agreement in place acknowledging the service provider's responsibility to protect the data + +**Important clarifications:** +- Password policy: Minimum complexity requirements clarified — passwords must contain both numeric and alphabetic characters (was always implied, now explicit) +- Malware: Clarified that all systems capable of being affected by malware must have anti-malware installed — not just Windows; Unix/Linux systems must be evaluated +- Application security: Clarified that all public-facing web applications must be protected either by a WAF or by annual application security assessment + +**SAQ changes in v3.0:** +- Introduced **SAQ B-IP** (standalone IP-connected PTS POI devices) +- Introduced **SAQ P2PE** (validated P2PE solutions) + +--- + +## PCI DSS v3.1 (April 2015) + +**Status**: Retired + +### Key changes from v3.0 + +**Primary driver**: Response to known vulnerabilities in SSL (all versions) and TLS 1.0. These protocols were proven cryptographically inadequate following the POODLE vulnerability (October 2014) and broader research. + +**Major changes:** +- **SSL and TLS 1.0 deprecated**: SSL and early TLS (TLS 1.0) deemed not strong cryptography and prohibited for protection of cardholder data in transit +- Migration timelines established: + - **Service providers**: Must complete migration from SSL/TLS 1.0 by **June 30, 2016** + - **All other entities**: Originally by June 30, 2016, extended to June 30, 2018 in v3.2 +- TLS 1.1 and TLS 1.2 identified as acceptable (TLS 1.2 preferred) +- Clarified that TLS 1.2 is the minimum acceptable strong cryptography standard for new implementations + +**Impact**: v3.1 had a narrow but high-impact scope — it required organisations to audit and migrate all SSL/TLS 1.0 implementations protecting cardholder data in transit. This was significant for many web applications, APIs, and internal service-to-service communications. + +--- + +## PCI DSS v3.2 (April 2016) + +**Status**: Retired + +### Key changes from v3.1 + +**Structural theme**: Strengthened requirements for service providers; expanded multi-factor authentication; incorporated Designated Entities Supplemental Validation (DESV). + +**Major new or expanded requirements:** + +**Multi-factor authentication (MFA) — expanded scope:** +- MFA was previously required for remote access from outside the entity's network and for non-console admin access +- **v3.2 added**: MFA required for all non-console administrative access into the CDE for all personnel (not just remote access) — effective immediately for new implementations, phased in by February 1, 2018 for existing implementations +- This was a significant expansion that affected internal administrators accessing CDE systems from within the network via console + +**Service provider-specific requirements added:** +- **Req 3.5.1** (service providers): Maintain a documented description of the cryptographic architecture +- **Req 10.8** (service providers only): Implement a process for the timely detection and reporting of failures of critical security control systems (IDS, FIM, AV, physical access controls, audit logs). Respond to failures within one business day +- **Req 10.8.1** (service providers only): Respond to failures of any critical security controls within timeframes specified in the requirement +- **Req 12.11** (service providers only): Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures + +**Appendix A3 — Designated Entities Supplemental Validation (DESV):** +- DESV incorporated as a formal appendix. DESV applies to entities designated by a payment card brand or acquirer as requiring DESV validation in response to a breach or risk exposure +- DESV adds controls around executive oversight, business as usual (BAU) activities, documentation, and responsibility assignment + +**Other changes:** +- **Req 6.4.6** (new): Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated accordingly +- Clarifications to penetration testing scope +- Best practice recommendations for multi-tenant hosting providers + +--- + +## PCI DSS v3.2.1 (May 2018) + +**Status**: **RETIRED March 31, 2024** — the last release in the v3.x series + +### Key changes from v3.2 +- Corrections only — no new requirements added or removed +- Updated language around the SSL/TLS migration deadline: + - June 30, 2018 migration deadline for all entities confirmed (previously June 30, 2016 for service providers, June 30, 2016/extended for merchants) + - After June 30, 2018, SSL and TLS 1.0 are not permitted to protect cardholder data in transit + - Entities that relied on compensating controls for SSL and TLS 1.0 must complete migration +- Clarification of terminology throughout +- Minor editorial corrections + +### Operational relevance +- v3.2.1 is the most commonly encountered legacy version in gap documentation, prior-year assessment records, and migration planning +- All entities that conducted PCI DSS assessments between May 2018 and March 31, 2024 used v3.2.1 +- For v3.2.1 → v4.0.1 migration guidance, consult `references/pci-dss-v4-changes.md` +- For the v3.2.1 control structure, consult `references/pci-dss-v3-controls.md` + +--- + +## PCI DSS v4.0 (March 2022) + +**Status**: Superseded by v4.0.1 (June 2024); v4.0 is no longer the current version + +### Key changes from v3.2.1 + +PCI DSS v4.0 was the most significant revision since v1.0. It introduced a fundamentally new compliance philosophy alongside new and expanded technical requirements. + +**Structural changes:** +- Requirements count increased from 259 (v3.2.1) to 300+ sub-requirements +- Two compliance approaches formalised: **Defined Approach** and **Customised Approach** +- **Targeted Risk Analysis (TRA)** elevated to a formalised requirement for customised controls and several defined controls with flexible frequencies +- Informative references moved to the online PCI SSC Reference Tool (no longer embedded in the standard document) +- Greater emphasis on outcomes-based security rather than prescriptive controls + +**Customised Approach:** +- For the first time, organisations can implement alternative controls designed to meet the stated **Objective** of a requirement (rather than following the defined testing procedure) +- Requires: TRA per customised control; senior management approval; QSA assessment using Customised Approach Test Plan (CATP); annual review +- Not available for SAQ A or SAQ B; intended for mature organisations and ROC-level assessments + +**New concept — future-dated requirements:** +- v4.0 introduced a two-phase approach: requirements effective immediately on March 31, 2024, and "future-dated" requirements (best practice from March 2022, **mandatory from March 31, 2025**) + +**Key new/expanded requirements (see `references/pci-dss-v4-changes.md` for full list):** +- **Req 8.4.2**: MFA required for ALL access into the CDE (not just admin/remote) +- **Req 5.4.1**: Automated technical solution required to detect and protect against phishing +- **Req 6.4.3**: All scripts on payment pages must be inventoried, authorised, and integrity-protected +- **Req 11.6.1**: Change and tamper detection for HTTP headers and payment page content +- **Req 10.4.1.1**: Automated log review mechanisms required (manual daily review no longer sufficient) +- **Req 8.3.6**: Passwords minimum 12 characters +- **Req 6.3.2**: Software inventory (SBOM) for bespoke software +- **Req 10.7**: Monitoring for failures of critical security controls + +--- + +## PCI DSS v4.0.1 (June 2024) — CURRENT + +**Status**: CURRENT — all new assessments must use v4.0.1 + +### Key changes from v4.0 +- **Errata corrections only** — no new technical requirements added, no requirements removed +- Corrected typographical errors, clarified ambiguous wording, and fixed inconsistencies in v4.0 +- Clarified the intent of several testing procedures that were interpreted inconsistently +- Updated the ROC Reporting Template to align with corrections +- All new and existing assessments should reference v4.0.1 + +**All "future-dated" requirements from v4.0 became mandatory on March 31, 2025.** + +--- + +## Dates and Milestones Reference + +| Date | Milestone | +|------|-----------| +| December 2004 | PCI DSS v1.0 published | +| September 2006 | PCI SSC founded; PCI DSS v1.1 published | +| October 2008 | PCI DSS v1.2 published; WEP prohibited | +| July 2009 | PCI DSS v1.2.1 published | +| October 2010 | PCI DSS v2.0 published | +| November 2013 | PCI DSS v3.0 published; SAQ B-IP and P2PE added | +| April 2015 | PCI DSS v3.1 published; SSL/TLS 1.0 deprecation announced | +| June 30, 2016 | SSL/TLS 1.0 migration deadline for service providers (v3.1/v3.2) | +| April 2016 | PCI DSS v3.2 published; MFA expansion; service provider requirements added | +| February 1, 2018 | v3.2 MFA expansions became mandatory for existing implementations | +| June 30, 2018 | SSL/TLS 1.0 migration deadline for all entities | +| May 2018 | PCI DSS v3.2.1 published (last v3.x release) | +| March 2022 | PCI DSS v4.0 published | +| March 31, 2024 | PCI DSS v3.2.1 **RETIRED** — all assessments must use v4.0 or v4.0.1 | +| June 2024 | PCI DSS v4.0.1 published (current) | +| March 31, 2025 | All "future-dated" v4.0 requirements became **mandatory** | + +--- + +## Version Selection for Assessments + +**Which version applies to a new or current PCI DSS assessment?** +- For any formal compliance assessment today: **PCI DSS v4.0.1** +- v3.2.1 was retired March 31, 2024 — it is not valid for any live assessment + +**When would an older version be referenced (non-assessment purposes)?** +- Historical documentation review (prior-year ROC/SAQ, audit records) +- Migration gap analysis: comparing what was in scope under v3.2.1 vs v4.0.1 +- Reviewing evidence from an assessment conducted before March 31, 2024 +- Understanding what controls were implemented in a specific past period + +**If an organisation's last assessment was under v3.2.1:** +- Their next assessment is under v4.0.1 +- They must implement all v4.0.1 requirements, including those that became mandatory on March 31, 2025 +- Consult `references/pci-dss-v4-changes.md` for the migration checklist + +--- + +## Key Thresholds by Version — Authentication Requirements + +| Requirement | v1.x–v2.0 | v3.0–v3.2.1 | v4.0 / v4.0.1 | +|-------------|-----------|------------|--------------| +| MFA — remote access | Required since v1.x (as two-factor auth) | Required | Required | +| MFA — non-console admin | Not explicitly required | Required (v3.2+) | Required | +| MFA — all CDE access | Not required | Not required | **Required (Req 8.4.2)** | +| Password minimum length | 7 characters | 7 characters | 12 characters | +| Password complexity | Numeric + alpha required | Numeric + alpha required | Numeric + alpha required (or passphrase alternative) | +| Session timeout | 15 minutes | 15 minutes | Unchanged | +| Account lockout threshold | 6 attempts | 6 attempts | 10 attempts | + +--- + +## Key Thresholds by Version — Cryptography + +| Topic | v1.x–v2.0 | v3.0–v3.2.1 | v4.0 / v4.0.1 | +|-------|-----------|------------|--------------| +| Wireless encryption | WEP acceptable (v1.x); WEP prohibited from v1.2 | WPA / WPA2 required | WPA2-Enterprise or WPA3 required | +| SSL | Acceptable (v1.x–v3.0) | Prohibited from v3.1 (migration by June 2018) | Prohibited | +| TLS 1.0 | Acceptable | Prohibited from v3.1 | Prohibited | +| TLS 1.1 | Acceptable | Conditionally acceptable | Prohibited (best practice; strongly discouraged) | +| TLS 1.2 | Recommended | Required minimum for new implementations | Required minimum | +| TLS 1.3 | Not addressed | Not addressed | Supported / recommended | +| Key length (PAN encryption) | Strong cryptography | AES-128 or equivalent minimum | AES-128 or equivalent; AES-256 preferred | + +--- + +## Glossary of Key Terms (Consistent Across All Versions) + +| Term | Definition | +|------|-----------| +| **CDE** | Cardholder Data Environment — all systems, people, and processes that store, process, or transmit cardholder data or SAD, plus all connected components | +| **PAN** | Primary Account Number — the payment card number (up to 19 digits); the single element that brings a system into PCI DSS scope | +| **CHD** | Cardholder Data — PAN plus cardholder name, expiry date, and service code | +| **SAD** | Sensitive Authentication Data — full magnetic stripe content, CAV2/CVV2/CVC2/CID, PIN/PIN block; must never be stored after authorisation | +| **QSA** | Qualified Security Assessor — PCI SSC-certified company conducting ROC assessments | +| **ISA** | Internal Security Assessor — PCI SSC-certified individual conducting internal assessments | +| **ROC** | Report on Compliance — formal assessment report required for Level 1 merchants and Level 1 service providers | +| **SAQ** | Self-Assessment Questionnaire — self-validation tool for Level 2–4 merchants and Level 2 service providers | +| **AOC** | Attestation of Compliance — declaration of compliance status accompanying ROC or SAQ | +| **ASV** | Approved Scanning Vendor — PCI SSC-certified vendor performing external vulnerability scans | +| **P2PE** | Point-to-Point Encryption — end-to-end encryption of cardholder data from POI device to decryption point | +| **Tokenisation** | Replacing PAN with a non-sensitive surrogate value (token) that has no exploitable value | +| **TRA** | Targeted Risk Analysis — formalised risk analysis process introduced in v4.0 | +| **TPSP** | Third-Party Service Provider — any entity that stores, processes, or transmits cardholder data on behalf of another entity | +| **CCW** | Compensating Control Worksheet — documentation for compensating controls in ROC/SAQ | diff --git a/plugins/soc/.claude-plugin/plugin.json b/plugins/soc/.claude-plugin/plugin.json new file mode 100644 index 0000000..2c9c9e7 --- /dev/null +++ b/plugins/soc/.claude-plugin/plugin.json @@ -0,0 +1,25 @@ +{ + "name": "soc", + "description": "AICPA System and Organization Controls (SOC) advisor covering SOC 1 (SSAE 18), SOC 3, SOC for Cybersecurity, and SOC for Supply Chain — report selection, scoping, control objectives, readiness, and audit preparation.", + "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": [ + "soc", + "soc1", + "soc3", + "ssae18", + "aicpa", + "service-organization", + "audit", + "icfr", + "cybersecurity", + "supply-chain", + "grc" + ] +} diff --git a/plugins/soc/skills/soc/SKILL.md b/plugins/soc/skills/soc/SKILL.md new file mode 100644 index 0000000..903ac97 --- /dev/null +++ b/plugins/soc/skills/soc/SKILL.md @@ -0,0 +1,408 @@ +--- +name: soc +description: > + Expert AICPA System and Organization Controls (SOC) advisor covering SOC 1 (SSAE 18), + SOC 3, SOC for Cybersecurity, and SOC for Supply Chain. Use this skill whenever a user + mentions SOC 1, SSAE 18, SAS 70, Type 1 or Type 2 service organization reports, internal + control over financial reporting (ICFR), user entity controls, SOC 3 general use reports, + SOC for Cybersecurity, SOC for Supply Chain, service auditor reports, complementary user + entity controls (CUECs), carve-out method, inclusive method, subservice organizations, + management's assertion, or any SOC engagement that is not specifically SOC 2 Trust Services + Criteria. Also trigger when users ask "which SOC report do we need?", "how do SOC reports + differ?", or "how do I prepare for a SOC 1 audit?". Note: SOC 2 is covered by the separate + soc2 skill. +--- + +# SOC (System and Organization Controls) Skill + +You are an expert AICPA SOC practitioner and compliance advisor with comprehensive knowledge +of the full SOC reporting suite: **SOC 1** (SSAE 18 AT-C Section 320), **SOC 3** (general use +Trust Services Criteria reports), **SOC for Cybersecurity**, and **SOC for Supply Chain**. + +This skill does not duplicate the SOC 2 skill. Direct SOC 2 Trust Services Criteria questions +to the `soc2` skill. + +--- + +## SOC Report Suite — Quick Reference + +| Report | Standard | Purpose | Distribution | Type 1 / Type 2 | +|---|---|---|---|---| +| SOC 1 | SSAE 18 AT-C §320 | Controls relevant to user entity ICFR | Restricted | Both | +| SOC 2 | SSAE 18 AT-C §205 + TSC | Controls relevant to TSC (Security, Availability, etc.) | Restricted | Both | +| SOC 3 | SSAE 18 AT-C §205 + TSC | General-use TSC attestation (no test details) | Unrestricted | No (Type 2 basis only) | +| SOC for Cybersecurity | SSAE 18 AT-C §205 + DC-4 | Entity-wide cybersecurity risk management | Unrestricted | No (examination) | +| SOC for Supply Chain | SSAE 18 AT-C §205 + DC-3 | Production and distribution system controls | Restricted | Both | + +**Authority:** All SOC engagements are governed by the American Institute of Certified Public +Accountants (AICPA) under the Statements on Standards for Attestation Engagements (SSAE). + +--- + +## How to Help Users — Task Router + +| User need | Action | +|---|---| +| Which SOC report do we need? | → [Report Selection Guidance](#report-selection-guidance) | +| SOC 1 scoping, design, or audit prep | → [SOC 1 Guidance](#soc-1-ssae-18-at-c-section-320) + `references/soc1-ssae18.md` | +| SOC 3 — general use report | → [SOC 3 Guidance](#soc-3-general-use-report) + `references/soc3-general-use.md` | +| SOC for Cybersecurity | → [SOC for Cybersecurity](#soc-for-cybersecurity) + `references/soc-cybersecurity.md` | +| SOC for Supply Chain | → [SOC for Supply Chain](#soc-for-supply-chain) + `references/soc-supply-chain.md` | +| SOC 2 Trust Services Criteria | → Refer user to the `soc2` skill | +| General SOC comparison | → Answer from [SOC Report Suite Quick Reference](#soc-report-suite--quick-reference) | + +--- + +## Report Selection Guidance + +When a user asks which SOC report they need, work through these four questions: + +### Question 1 — What is the organization's role? + +- **Service organization** (provides outsourced services to other businesses): SOC 1, SOC 2, or SOC 3 may apply. +- **Any organization** (including internal IT departments, insurers, boards): SOC for Cybersecurity may apply. +- **Producer, manufacturer, or distributor**: SOC for Supply Chain may apply. + +### Question 2 — What do their customers or stakeholders need? + +| Stakeholder need | Appropriate SOC report | +|---|---| +| User auditors assessing ICFR at a client that uses the service org | SOC 1 Type 2 | +| Customers requesting evidence of security/availability controls | SOC 2 Type 2 (see soc2 skill) | +| Public-facing certification/seal that can be posted on website | SOC 3 | +| Board, insurers, or investors assessing enterprise cybersecurity posture | SOC for Cybersecurity | +| Downstream customers assessing supply chain integrity | SOC for Supply Chain | + +### Question 3 — Does the service affect financial transactions or financial reporting systems? + +- Yes → SOC 1 is the primary requirement; SOC 2 may supplement it. +- No → SOC 2, SOC 3, or SOC for Cybersecurity typically applies. + +### Question 4 — Is the need restricted-use or general-use? + +- Restricted (specific users only): SOC 1, SOC 2, SOC for Supply Chain. +- General use (public distribution): SOC 3, SOC for Cybersecurity. + +--- + +## SOC 1 (SSAE 18 AT-C Section 320) + +### Overview + +SOC 1 reports are examination engagements performed under **AT-C Section 320** of SSAE 18 +(effective May 1, 2017). They report on controls at a service organization that are relevant +to user entities' Internal Control over Financial Reporting (ICFR). + +**Governing standard:** SSAE 18 AT-C Section 320 +**Superseded:** SSAE 16 (formerly SSAE 16 AT 801), which itself superseded SAS 70. +**Performed by:** A licensed CPA firm (the service auditor). + +See `references/soc1-ssae18.md` for the full SOC 1 reference, control objectives library, +and report structure details. + +### Type 1 vs Type 2 + +| Attribute | Type 1 | Type 2 | +|---|---|---| +| Period covered | As of a specific date | Over a stated period (minimum 6 months recommended; 12 months typical) | +| Opinion scope | Description fairly presented; controls suitably designed | Same PLUS controls operated effectively throughout the period | +| Testing required | Design evaluation only | Design evaluation + operating effectiveness testing | +| Typical use | Initial assessment; transition to new auditor | Ongoing annual audit; fulfils user auditor requirements | + +### Report Components + +A SOC 1 report must include: + +1. **Independent service auditor's report** — Contains the opinion(s), engagement description, and any modifications. +2. **Management's assertion** — Management confirms the description is fairly presented and controls are suitably designed (Type 1) or also operated effectively (Type 2). +3. **Description of the service organization's system** — See system description requirements below. +4. **Tests of controls and results** *(Type 2 only)* — Describes each test performed and the results obtained. +5. **Other information** *(optional)* — Additional information provided by the service organization that is not covered by the practitioner's opinion. + +### System Description Requirements (AT-C §320.25–.27) + +The system description must address all of the following: + +1. **Types of services provided** and the principal service commitments and system requirements arising from contracts, regulations, and other sources. +2. **System components:** + - *Infrastructure* — Physical and hardware components (servers, networks, facilities). + - *Software* — System software, applications, middleware, and databases. + - *People* — Personnel involved in the operation and delivery of services. + - *Processes* — Automated and manual procedures. + - *Data* — Transactions, master files, tables, output data. +3. **Boundaries of the system** — What is and is not within the service organization's control. +4. **Relevant aspects of the control environment, risk assessment process, information and communication, monitoring, and control activities.** +5. **Complementary User Entity Controls (CUECs)** — Controls that are assumed to be implemented by user entities for the control objectives to be met. +6. **Complementary subservice organization controls (CSOCs)** — Required when using the inclusive method. +7. **Changes to the system and controls during the period** *(Type 2 only)*. + +### Control Objectives + +Control objectives in SOC 1 are **not prescribed by AICPA** — they are defined by the service organization to reflect the nature of its services and are typically negotiated with the service auditor. Common control objective areas include: + +| Control Objective Area | Purpose | +|---|---| +| Financial transaction processing | Transactions are processed accurately, completely, and timely | +| Logical access controls | Access to systems is authorized and appropriate | +| Physical access controls | Physical access to data centers is restricted to authorized personnel | +| Change management | Changes to systems are authorized, tested, and documented | +| Computer operations | Batch processing, job scheduling, and incident management | +| Data backup and recovery | Data is backed up and can be recovered in a timely manner | +| Network security | Unauthorized access via network is prevented and detected | +| Vendor/subservice management | Subservice organizations are managed and monitored | + +### Subservice Organizations + +When a service organization uses another organization to perform part of the service: + +**Carve-out method:** The description identifies the subservice organization and the functions it performs but does not describe controls at the subservice organization. The service auditor does not test or opine on controls at the subservice organization. User auditors must separately evaluate the carved-out controls. + +**Inclusive method:** The description includes controls performed by the subservice organization. The subservice organization must also provide management's assertion and agree to have its controls tested. The service auditor includes the subservice organization's controls in the report. + +### Scoping a SOC 1 Engagement + +To scope a SOC 1 engagement, work through: + +1. **Identify the services provided** that affect user entity ICFR (e.g., payroll processing, transaction processing, data hosting for financial applications). +2. **Define the system boundary** — what infrastructure, software, processes, and data are included. +3. **Identify user entities** — who uses the service and how does the output affect their financial statements? +4. **Identify CUECs** — what controls must the user entity have in place for the control objectives to hold? +5. **Identify subservice organizations** — which vendors perform functions within the system boundary? +6. **Select carve-out vs inclusive** — for each subservice organization. +7. **Define control objectives** — in consultation with the service auditor and, if applicable, user auditors. +8. **Select Type 1 or Type 2** — based on user entity and user auditor needs. + +### Common Findings and Weaknesses + +| Finding | Root Cause | Remediation | +|---|---|---| +| Control objective not met | No control designed; control only partially implemented | Design a specific control mapped to the objective | +| Deviation noted | Control tested but one or more failures found | Root cause analysis; determine if deviation is isolated or systemic | +| Scope gap | Service function in scope but controls not documented | Enumerate processes and map controls to each | +| CUEC overreliance | Control objective depends entirely on user entity controls | Redesign so service org controls can stand independently | +| Change not noted | System changed during period but description not updated | Implement change documentation procedures; update description section | + +--- + +## SOC 3 (General Use Report) + +### Overview + +SOC 3 reports are general use reports that attest to the same Trust Services Criteria as SOC 2 +but without including the detailed system description, tests of controls, or results. They are +freely distributable and permit the organization to display the **AICPA SOC Service +Organization seal**. + +**Governing standard:** SSAE 18 AT-C Section 205, using the AICPA Trust Services Criteria +**Distribution:** Unrestricted — can be published on websites, shared with customers, included in marketing + +See `references/soc3-general-use.md` for full guidance on SOC 3 structure, use cases, and +procurement considerations. + +### SOC 3 Report Structure + +1. **Management's assertion** — States that the description of the system is fairly presented and controls were effective over the period (uses same TSC scope as the related SOC 2). +2. **Practitioner's short-form report** — Opinion that controls were effective throughout the period. No list of tests or results. +3. **Brief system description** — High-level description of the services provided. Does not include the detailed control-by-control narrative required in SOC 2. + +### Relationship to SOC 2 + +An organization typically obtains a SOC 3 report **based on the same examination** as a SOC 2 Type 2 report. The SOC 2 and SOC 3 can be issued simultaneously by the same CPA firm from the same period of testing. The SOC 2 is distributed only to specified users under NDA; the SOC 3 is publicly available. + +| Attribute | SOC 2 | SOC 3 | +|---|---|---| +| Distribution | Restricted — specific parties only | Unrestricted | +| Detail level | Full system description + all tests and results | Brief description only; no tests | +| AICPA seal permitted | No | Yes | +| Suitable for posting on website | No | Yes | +| Suitable for user auditors | Yes | No | + +### When to Recommend SOC 3 + +- Organization wants a public-facing compliance credential without disclosing detailed control testing. +- Marketing or sales team needs a shareable security certification. +- Organization already has or is obtaining a SOC 2 Type 2 and wants additional public accountability. +- Procurement requirements specify a SOC report but do not require full SOC 2 detail. + +### SOC 3 Seal + +Organizations that receive a clean (unmodified) SOC 3 practitioner's report may display the AICPA SOC 3 Service Organization seal. The seal includes text specifying the Trust Services Criteria covered and the period. The AICPA licenses the seal; requirements are published in the AICPA SOC 3 guidance materials. + +--- + +## SOC for Cybersecurity + +### Overview + +The AICPA introduced SOC for Cybersecurity in **2017** as an entity-level examination of an +organization's cybersecurity risk management program. Unlike SOC 2 (which focuses on a defined +service or system), SOC for Cybersecurity assesses the **entire organization's** approach to +managing cybersecurity risk. + +**Governing standard:** SSAE 18 AT-C Section 205 +**Description criteria:** AICPA DC-4 — *Description Criteria for Management's Description of an Entity's Cybersecurity Risk Management Program* (2017) +**Measurement criteria:** AICPA Trust Services Criteria for Security (CC1–CC9, 2017 version with 2022 revised points of focus) + +See `references/soc-cybersecurity.md` for the full DC-4 criteria detail, examination scope, +and reporting structure. + +### Primary Audiences + +SOC for Cybersecurity is designed for audiences that need an entity-level view of cybersecurity +governance — not just service delivery controls: + +- **Board of directors and audit committees** — Governance-level assurance over cybersecurity strategy. +- **Business partners and large customers** — Assurance beyond a vendor questionnaire; covers the whole organization. +- **Insurers (cyber insurance underwriters)** — Objective evidence of program maturity. +- **Investors and analysts** — For public companies disclosing cybersecurity risk management. +- **Regulators** — Where cybersecurity program disclosure is required. + +### DC-4 Description Criteria (Nine Groups) + +Management's description of the cybersecurity risk management program must address nine criteria groups under DC-4: + +| # | Criterion | What must be described | +|---|---|---| +| DC-4.1 | Program objectives | The entity's cybersecurity risk management objectives and how they align with business objectives | +| DC-4.2 | Risk factors | Factors affecting cybersecurity inherent risks (sensitivity of data, threat landscape, technology complexity) | +| DC-4.3 | Governance | Policies, oversight structure, roles and responsibilities, accountability mechanisms | +| DC-4.4 | Risk identification | How cybersecurity risks are identified and categorized | +| DC-4.5 | Risk assessment and response | How risks are assessed, prioritized, and treated (accept, mitigate, transfer, avoid) | +| DC-4.6 | Monitoring | How the effectiveness of the cybersecurity program is monitored continuously | +| DC-4.7 | Communication | How cybersecurity information is communicated internally and externally | +| DC-4.8 | Control processes | Technical and operational controls in place (preventive, detective, corrective) | +| DC-4.9 | Incidents | Cybersecurity incidents experienced during the period and how they were managed | + +### Measurement Criteria — Trust Services Criteria for Security + +The practitioner (CPA firm) evaluates the effectiveness of the cybersecurity risk management program against the AICPA Trust Services Criteria for Security (CC1–CC9). This is the same control framework as SOC 2 Security criteria. However, the SOC for Cybersecurity examination evaluates these criteria across the **entire organization**, not a specific system. + +### Examination Components + +1. **Management's description** — Narrative covering all nine DC-4 criteria groups. +2. **Management's assertion** — Statement that the description is fairly presented and controls were effective. +3. **Practitioner's report** — Opinion based on AT-C Section 205: + - Opinion on whether management's description is presented in accordance with DC-4 criteria. + - Opinion on whether controls within the cybersecurity risk management program were effective. +4. **Distribution:** The full examination report can be general use (publicly distributed), unlike SOC 2. + +### SOC for Cybersecurity vs SOC 2 + +| Attribute | SOC 2 | SOC for Cybersecurity | +|---|---|---| +| Scope | Defined service or system | Entire entity's cybersecurity program | +| Applicability | Service organizations only | Any organization | +| Description criteria | AICPA system description (AT-C §205) | DC-4 (nine criteria groups) | +| Measurement criteria | TSC (Security + optional A, C, PI, P) | TSC Security (CC1–CC9) only | +| Primary audience | User entities, user auditors | Board, investors, insurers, regulators | +| Distribution | Restricted use | General use | +| Can combine with SOC 2? | N/A | Yes — can be issued alongside SOC 2 | + +### Readiness for SOC for Cybersecurity + +To prepare for a SOC for Cybersecurity examination: + +1. **Map the program to DC-4** — For each of the nine criteria groups, document how the organization satisfies the description requirements. +2. **Assess control coverage against CC1–CC9** — Gap analysis against the Trust Services Criteria for Security. +3. **Document governance artifacts** — Board cybersecurity agenda items, security committee charters, executive reporting. +4. **Establish monitoring evidence** — Metrics, dashboards, vulnerability management records, penetration test results. +5. **Prepare incident documentation** — Log of cybersecurity incidents during the period, escalation records, lessons-learned reports. +6. **Communicate externally** — Confirm policies for external disclosure of cybersecurity information exist (DC-4.7). + +--- + +## SOC for Supply Chain + +### Overview + +The AICPA published the **SOC for Supply Chain** framework in **2020**. It is designed for +producers, manufacturers, distributors, growers, and suppliers that need to provide assurance +to downstream customers and business partners about controls over their production and +distribution systems. + +**Governing standard:** SSAE 18 AT-C Section 205 +**Description criteria:** AICPA DC-3 — *Description Criteria for a Report on Controls Over the Production and Distribution System* (2020) +**Measurement criteria:** Trust Services Criteria (Security, Availability, Processing Integrity as applicable) + +See `references/soc-supply-chain.md` for full DC-3 criteria coverage, scoping guidance, and +report structure. + +### Target Organizations + +- Manufacturers and producers of goods (pharmaceuticals, food/beverage, consumer goods, industrials). +- Software and technology developers (software supply chain integrity). +- Agricultural producers and growers. +- Third-party logistics and distribution providers. +- Component and raw material suppliers. + +### DC-3 Description Criteria (Eight Areas) + +Management's description of the production and distribution system must address: + +| # | Area | Coverage | +|---|---|---| +| DC-3.1 | Products and services | Types of products produced, services provided, and principal commitments | +| DC-3.2 | Principal system requirements | Legal, regulatory, contractual obligations affecting production/distribution | +| DC-3.3 | System components | Infrastructure, software, people, processes, and data used in production/distribution | +| DC-3.4 | Risk factors | Factors that affect inherent risks in production and distribution (supply disruptions, quality failures, cybersecurity threats to OT) | +| DC-3.5 | Goals and objectives | Production/distribution goals: quality, security, availability, processing integrity | +| DC-3.6 | Policies and processes | Policies and processes for achieving production and distribution objectives | +| DC-3.7 | Related controls | Controls mapped to each policy and process | +| DC-3.8 | Complementary user layer entity controls (CULECs) | Controls assumed to be in place at downstream customer organizations | + +### Report Types + +| Type | Covers | Opinion scope | +|---|---|---| +| Type 1 | As of a specific date | Description fairly presented; controls suitably designed | +| Type 2 | Over a period (minimum 6 months) | Description fairly presented; controls suitably designed and operated effectively | + +### Key Differences from SOC 1 and SOC 2 + +| Attribute | SOC 1 | SOC 2 | SOC for Supply Chain | +|---|---|---|---| +| Purpose | Financial reporting controls | Trust Services for IT/cloud | Production and distribution integrity | +| Scope | IT services affecting ICFR | Defined IT system | Manufacturing, logistics, supply chain | +| Description criteria | SSAE 18 §320 system description | TSC system description | DC-3 | +| Measurement criteria | Service org's own control objectives | TSC | TSC (subset) | +| Typical industries | Financial services, payroll, SaaS | Cloud, SaaS, healthcare IT | Manufacturing, agriculture, logistics | + +### Scoping a SOC for Supply Chain Engagement + +1. **Identify the production/distribution system** — boundaries of the system covered by the report. +2. **Identify applicable Trust Services Criteria** — Which of Security, Availability, Processing Integrity apply to production/distribution commitments? +3. **Map the DC-3 criteria** — Ensure the system description covers all eight DC-3 areas. +4. **Identify downstream customers (user layer entities)** — Who relies on the production/distribution system? +5. **Define CULECs** — Controls that must be in place at downstream customers for commitments to be met. +6. **Select Type 1 or Type 2** — Based on maturity and stakeholder requirements. +7. **Engage a CPA firm** — The examination must be performed by a licensed practitioner. + +--- + +## Output Format Guidelines + +Adapt responses to the user's role and context: + +- **Service organization management** — Focus on scoping, control objective design, description requirements, and readiness steps. +- **CPA / service auditor** — Use precise SSAE 18 language, reference specific AT-C sections and paragraphs, discuss sampling and testing procedures. +- **User entity or user auditor** — Explain CUEC responsibilities, how to read and use SOC reports, and how to evaluate report coverage against their ICFR needs. +- **Board / executive** — Plain language explanation of which report is needed, what assurance it provides, and what investment is required. +- **Procurement / vendor risk team** — Focus on what to ask vendors, how to evaluate SOC reports received, and how to tier vendor SOC requirements. + +Always: +- Specify the relevant SSAE 18 AT-C section when making technical assertions. +- Distinguish between Type 1 and Type 2 where this materially affects the answer. +- Note that all SOC engagements must be performed by a licensed CPA firm — practitioners cannot self-certify. +- If the question is clearly about SOC 2 Trust Services Criteria, refer the user to the `soc2` skill. +- Note when AICPA guidance may have been updated: encourage users to verify against the current AICPA publications. + +--- + +## Reference Files + +Load these files when working on the corresponding tasks: + +- `references/soc1-ssae18.md` — SOC 1 full reference: AT-C §320 requirements, control objectives library, system description checklist, Type 1/2 comparison, common findings +- `references/soc3-general-use.md` — SOC 3 structure, AICPA seal requirements, comparison with SOC 2, distribution guidance +- `references/soc-cybersecurity.md` — SOC for Cybersecurity: full DC-4 criteria, CC1–CC9 mapping, readiness checklist, gap assessment template +- `references/soc-supply-chain.md` — SOC for Supply Chain: full DC-3 criteria, scoping guide, engagement checklist, industry-specific considerations diff --git a/plugins/soc/skills/soc/references/soc-cybersecurity.md b/plugins/soc/skills/soc/references/soc-cybersecurity.md new file mode 100644 index 0000000..2fa26c5 --- /dev/null +++ b/plugins/soc/skills/soc/references/soc-cybersecurity.md @@ -0,0 +1,280 @@ +# SOC for Cybersecurity Reference + +## Overview + +SOC for Cybersecurity is an entity-level examination engagement introduced by the AICPA in +**2017**. It provides assurance over an organization's **cybersecurity risk management program** +— the full enterprise-wide set of policies, processes, and controls used to identify, assess, +and respond to cybersecurity risks. Unlike SOC 2, which is scoped to a defined system, SOC for +Cybersecurity covers the entire organization. + +**Governing standard:** SSAE 18, AT-C Section 205 (*Examination Engagements*) +**Description criteria:** AICPA DC-4 — *Description Criteria for Management's Description of an Entity's Cybersecurity Risk Management Program* (2017) +**Measurement criteria:** AICPA Trust Services Criteria for Security (CC1–CC9), 2017 version with 2022 Revised Points of Focus +**Distribution:** General use — the report may be shared with any stakeholder + +**Authoritative source:** AICPA *Reporting on an Entity's Cybersecurity Risk Management Program and Controls* guide (2017). + +--- + +## When SOC for Cybersecurity Applies + +| Scenario | Applies? | +|---|---| +| Large enterprise wants board-level cybersecurity assurance | Yes | +| Organization applying for cyber insurance | Yes | +| Public company disclosing cybersecurity risk management to investors | Yes | +| Technology vendor customer requires enterprise security assurance | Yes | +| Service organization wants assurance limited to a specific service | No — use SOC 2 | +| Organization wants unrestricted general use report on security | Yes | +| Healthcare organization subject to HIPAA cybersecurity oversight | May apply alongside HIPAA compliance | +| Government contractor needing formal security examination | May apply alongside other frameworks | + +--- + +## DC-4 Description Criteria — Full Detail + +Management's description of the entity's cybersecurity risk management program must address +all nine criteria groups in DC-4. The description must be sufficiently detailed for users to +understand the program. + +--- + +### DC-4.1 — Nature of the Business and Operations + +**What must be described:** +- The nature of the entity's business and operations. +- How the entity uses information technology in its business. +- The regulatory environment the entity operates in. +- Third parties with whom the entity shares information or on whom it relies for cybersecurity. + +**Why this matters for the examination:** +The practitioner uses this context to understand the cybersecurity risk environment and evaluate +whether the cybersecurity risk management objectives are appropriate. + +--- + +### DC-4.2 — Cybersecurity Objectives + +**What must be described:** +- The entity's cybersecurity risk management objectives. +- How cybersecurity objectives align with the entity's business objectives. +- Key commitments to customers, business partners, regulators, or other stakeholders related + to cybersecurity (e.g., contractual security clauses, regulatory requirements). + +--- + +### DC-4.3 — Factors That Have a Significant Effect on Inherent Cybersecurity Risks + +**What must be described:** +- Factors that significantly affect the entity's inherent cybersecurity risks, including: + - Types and sensitivity of information assets (personal data, financial data, intellectual property). + - Technologies used (cloud, mobile, OT/ICS, legacy systems). + - Internal and external threats relevant to the entity. + - Changes in the technology environment during the period. + - Third-party connections and dependencies. + - Workforce factors (remote work, contractors, temporary staff). + +--- + +### DC-4.4 — Cybersecurity Risk Governance Structure + +**What must be described:** +- Governance structure for cybersecurity risk management: + - Board and executive oversight of cybersecurity. + - Roles and responsibilities (CISO, CIO, risk committee, etc.). + - Policies that govern cybersecurity (security policy, acceptable use, classification). + - Accountability mechanisms (consequence management, performance objectives). +- How cybersecurity accountability is established at all levels of the organization. + +--- + +### DC-4.5 — Cybersecurity Risk Identification and Assessment Processes + +**What must be described:** +- How the entity identifies cybersecurity risks (threat intelligence sources, vulnerability scanning, penetration testing, audit findings, vendor risk). +- How identified risks are assessed and prioritized (likelihood, impact, risk scoring methodology). +- How the risk appetite and tolerance levels are defined and applied. +- How risk assessments are updated (frequency, trigger events). + +--- + +### DC-4.6 — Cybersecurity Risk Response and Mitigation + +**What must be described:** +- How the entity responds to identified cybersecurity risks: accept, mitigate, transfer (insurance), or avoid. +- Risk treatment decisions and their documentation. +- How risk treatment effectiveness is evaluated. +- Key risk mitigation controls implemented. + +--- + +### DC-4.7 — Cybersecurity Monitoring Processes + +**What must be described:** +- How the entity monitors its cybersecurity environment: + - Continuous monitoring of controls. + - Security event monitoring (SIEM, log management, alerting). + - Vulnerability management and patch tracking. + - Penetration testing and red team exercises. +- Frequency of monitoring activities. +- How monitoring results are reported and acted upon. + +--- + +### DC-4.8 — Cybersecurity Communications + +**What must be described:** +- **Internal communications:** How cybersecurity information flows within the organization (reporting to the board, metrics to executives, alerts to operations teams). +- **External communications:** How cybersecurity information is communicated to external parties: + - Customer notification of data breaches or incidents. + - Regulatory disclosure obligations. + - Vendor and third-party communication on security incidents. + - Public disclosure policies. + +--- + +### DC-4.9 — Cybersecurity Control Processes + +**What must be described:** +- The control processes in place to detect, prevent, and respond to cybersecurity threats. +- These must cover relevant aspects of the Trust Services Criteria for Security (CC1–CC9). +- Key control categories to address: + - Identity and access management + - Network and perimeter security + - Endpoint protection + - Data protection and encryption + - Secure software development + - Physical security + - Incident response + - Business continuity and disaster recovery + - Third-party risk management + +--- + +## Measurement Criteria — TSC for Security (CC1–CC9) + +The practitioner evaluates the effectiveness of the cybersecurity risk management program +against the AICPA Trust Services Criteria for Security across the entire organization. + +| Criterion | Title | Key Focus | +|---|---|---| +| CC1 | Control Environment | Integrity, ethical values, board oversight, accountability structure, talent management | +| CC2 | Communication and Information | Internal and external communication of security responsibilities; information quality | +| CC3 | Risk Assessment | Risk identification, analysis, and response; fraud risk assessment | +| CC4 | Monitoring Activities | Ongoing monitoring; separate evaluations; tracking deficiencies | +| CC5 | Control Activities | Policies and procedures; technology controls; segregation of duties | +| CC6 | Logical and Physical Access Controls | Access provisioning and deprovisioning; authentication; physical security | +| CC7 | System Operations | Incident detection and response; security monitoring; backup and recovery | +| CC8 | Change Management | Change authorization; configuration management; software development lifecycle | +| CC9 | Risk Mitigation | Vendor/third-party risk; insurance; business disruption recovery | + +For SOC for Cybersecurity, all nine CC criteria apply to the entity's entire program — not just +a specific system. The practitioner evaluates each CC criterion across the program as described +in management's DC-4 description. + +--- + +## SOC for Cybersecurity vs SOC 2 — Detailed Comparison + +| Attribute | SOC 2 | SOC for Cybersecurity | +|---|---|---| +| Scope | A specific, defined system or service | The entire entity's cybersecurity risk management program | +| Who it applies to | Service organizations | Any entity | +| Description framework | SSAE 18 system description requirements | DC-4 (nine criteria groups) | +| Measurement framework | TSC (Security required; Availability, C, PI, P optional) | TSC Security (CC1–CC9) only | +| Distribution | Restricted use | General use | +| Primary audience | User entities, user auditors, sophisticated customers | Board, investors, insurers, regulators | +| Focus | Controls implemented on a defined system | Entity-wide governance, risk management, and controls | +| Suitable for board reporting? | Not typically | Yes — designed for board-level audience | +| Can coexist? | Yes | Yes — can issue both for same period | + +--- + +## SOC for Cybersecurity — Readiness Assessment + +Use this gap assessment template before engaging a CPA firm for examination. + +### DC-4 Coverage Assessment + +| DC-4 Criteria | Assessment Questions | Status | +|---|---|---| +| DC-4.1 Business and Operations | Is the entity's business context, technology use, and regulatory environment documented? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.2 Objectives | Are cybersecurity objectives documented and aligned to business objectives? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.3 Inherent Risk Factors | Have inherent cybersecurity risk factors been identified and documented? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.4 Governance | Is there a cybersecurity governance structure with board oversight, defined roles, and policies? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.5 Risk Identification and Assessment | Is there a formal risk identification and assessment process? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.6 Risk Response | Are risk treatment decisions documented with supporting rationale? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.7 Monitoring | Is there continuous monitoring with defined metrics and management reporting? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.8 Communications | Are internal and external cybersecurity communication protocols defined and followed? | [ ] Met / [ ] Partial / [ ] Gap | +| DC-4.9 Controls | Are technical and operational controls documented and operational for all CC1–CC9 areas? | [ ] Met / [ ] Partial / [ ] Gap | + +### CC1–CC9 Coverage Assessment + +| Criterion | Key Question | Common Gap | +|---|---|---| +| CC1 — Control Environment | Does leadership demonstrate commitment to cybersecurity? Is there a code of conduct and an ethics program? | No board-level cybersecurity agenda; no security KPIs tied to performance | +| CC2 — Communication | Are cybersecurity roles, policies, and responsibilities communicated to all relevant personnel? | Policies exist but are not distributed or acknowledged; external disclosures not defined | +| CC3 — Risk Assessment | Is there a formal, documented enterprise cybersecurity risk assessment? | Risk assessments ad-hoc; no risk register; no defined risk tolerance | +| CC4 — Monitoring | Are controls monitored for effectiveness on an ongoing basis? | Controls designed but never tested; no deficiency tracking mechanism | +| CC5 — Control Activities | Are security policies implemented as controls across the organization? | Policies exist but controls are inconsistently implemented | +| CC6 — Access Controls | Are access provisioning, deprovisioning, and review processes implemented? | No formal access reviews; privileged accounts not tracked; weak authentication | +| CC7 — System Operations | Is there a security operations capability with incident detection and response? | No SIEM; no IR plan; no tabletop exercises; DR not tested | +| CC8 — Change Management | Are changes to systems controlled, authorized, and tested? | Ad-hoc changes; no change advisory board; no test environment | +| CC9 — Risk Mitigation | Is third-party risk managed? Is cyber insurance in place? | No vendor risk program; no cyber insurance; no BCP | + +--- + +## Preparing the DC-4 Description — Writing Guidance + +The management description is the central artifact in a SOC for Cybersecurity engagement. +It must be sufficiently detailed, accurate, and honestly reflect the program as it operates — +not as it is intended to operate. + +**Common mistakes in DC-4 descriptions:** +- Describing aspirational or planned controls as if they are in place. +- Omitting significant risk factors (e.g., legacy technology) because they are unflattering. +- Generic language that could apply to any organization (the description must be specific). +- Failing to describe incidents that occurred during the period (DC-4.9 requires disclosure). +- Describing monitoring activities without specifying frequency or scope. + +**Structure recommendation:** +Follow the nine DC-4 groups in sequence. Each section should: +1. State what the entity does (factually). +2. Reference specific policies, tools, and processes. +3. Identify the responsible role or team. +4. State the frequency of key activities. + +--- + +## Frequently Asked Questions + +**Q: Can any organization get a SOC for Cybersecurity report?** +Yes. Unlike SOC 1 and SOC 2, which apply specifically to service organizations, SOC for +Cybersecurity can be obtained by any type of entity: manufacturers, financial institutions, +healthcare organizations, government contractors, or any organization that wants board-level +or stakeholder assurance over its cybersecurity program. + +**Q: Does SOC for Cybersecurity replace SOC 2?** +No. SOC for Cybersecurity and SOC 2 address different questions. SOC 2 assesses controls on +a specific service system against TSC; SOC for Cybersecurity assesses the entity's complete +cybersecurity risk management program. Both can coexist and are complementary for service +organizations. + +**Q: Is the SOC for Cybersecurity report publicly available?** +It may be. Unlike SOC 1 and SOC 2, which are restricted-use documents, the SOC for +Cybersecurity report is general use and may be distributed freely. The entity and practitioner +decide the distribution. + +**Q: Can the DC-4 description disclose a cybersecurity incident?** +Yes — and it must, if incidents occurred during the period. DC-4.9 requires that the +description include cybersecurity incidents experienced during the period. The management +description should describe the nature of any incidents, how they were detected, and how +they were managed. The practitioner will evaluate whether the response was consistent with +the entity's stated procedures. + +**Q: What does a "pass" look like for SOC for Cybersecurity?** +The practitioner issues an unmodified opinion stating that: (1) management's description is +presented in accordance with DC-4 criteria, and (2) the controls within the cybersecurity +risk management program were effective throughout the period to achieve the entity's +cybersecurity objectives. There is no point-by-point pass/fail for each DC-4 criterion. diff --git a/plugins/soc/skills/soc/references/soc-supply-chain.md b/plugins/soc/skills/soc/references/soc-supply-chain.md new file mode 100644 index 0000000..4ed7664 --- /dev/null +++ b/plugins/soc/skills/soc/references/soc-supply-chain.md @@ -0,0 +1,316 @@ +# SOC for Supply Chain Reference + +## Overview + +SOC for Supply Chain is an attestation framework published by the AICPA in **2020**. It +provides assurance to downstream customers and business partners about controls over an +organization's production and distribution system. It is designed for producers, manufacturers, +distributors, growers, and suppliers — any organization whose production or distribution +activities could introduce risk into the supply chains of their customers. + +**Governing standard:** SSAE 18, AT-C Section 205 (*Examination Engagements*) +**Description criteria:** AICPA DC-3 — *Description Criteria for a Report on Controls Over the Production and Distribution System* (2020) +**Measurement criteria:** AICPA Trust Services Criteria (Security, Availability, Processing Integrity as applicable based on the nature of the production/distribution commitments) +**Distribution:** Restricted use — shared only with management of the reporting entity and downstream customers (user layer entities) who rely on the production/distribution system + +**Authoritative source:** AICPA *Reporting on an Examination of Controls Over the Production and Distribution System of a Service Organization for Organizations That Are Producers, Manufacturers, and Distributors* guide (2020). + +--- + +## Target Organizations + +SOC for Supply Chain applies to organizations in the following industries and roles: + +| Industry/Role | Examples | +|---|---| +| Pharmaceutical manufacturing | Active pharmaceutical ingredient (API) manufacturers, contract drug manufacturers | +| Food and beverage production | Food processors, beverage bottlers, agricultural producers, co-manufacturers | +| Industrial and consumer goods manufacturing | Component suppliers, OEM manufacturers, contract manufacturers | +| Software and technology supply chain | Software publishers, firmware developers, component vendors | +| Third-party logistics (3PL) | Warehouse operators, freight forwarders, last-mile distributors | +| Raw material producers and growers | Commodity producers, mineral extractors, agricultural growers | +| Medical device manufacturing | Medical device OEMs, component suppliers | +| Aerospace and defense manufacturing | Defense contractors, aerospace component suppliers | + +--- + +## Report Types + +| Type | Coverage | Opinion Scope | +|---|---|---| +| Type 1 | As of a specific date | Description is fairly presented; controls are suitably designed | +| Type 2 | Over a stated period (recommended minimum 6 months; 12 months typical) | Description is fairly presented; controls are suitably designed; controls operated effectively throughout the period | + +Type 2 is the more commonly requested report because it provides evidence of consistent +operation — which is what downstream customers and user auditors need. + +--- + +## DC-3 Description Criteria — Full Detail + +Management's description of the production and distribution system must address all eight +areas outlined in DC-3. The description must be sufficiently detailed for downstream customers +and user layer entities to understand the system and evaluate whether their own controls +(Complementary User Layer Entity Controls) are sufficient. + +--- + +### DC-3.1 — Types of Products Produced and Services Provided + +**What must be described:** +- The types of products produced or services provided by the organization. +- The nature of the production or distribution process. +- Principal commitments made to downstream customers: + - Quality commitments (e.g., purity, composition, dimensional tolerances). + - Security commitments (e.g., no unauthorized modifications to products). + - Availability commitments (e.g., production capacity, delivery SLAs). + - Processing integrity commitments (e.g., complete and accurate order fulfillment). + +--- + +### DC-3.2 — Principal System Requirements + +**What must be described:** +- Legal and regulatory requirements applicable to the production/distribution system: + - FDA regulations (21 CFR Parts 110, 111, 117, 211 for pharmaceutical/food). + - ISO 9001 quality management requirements (if certified). + - Sector-specific standards (e.g., GMP, HACCP, ISO 13485). +- Contractual obligations with customers. +- Standards and certifications maintained. +- Environmental, health, and safety requirements affecting production. + +--- + +### DC-3.3 — Components of the Production and Distribution System + +**What must be described:** +The description uses the same five-component model as SOC 1 and SOC 2: + +| Component | Examples in Production/Distribution Context | +|---|---| +| Infrastructure | Manufacturing plants, warehouses, logistics hubs, production equipment, quality testing equipment, IT infrastructure supporting production | +| Software | Manufacturing execution systems (MES), enterprise resource planning (ERP), warehouse management systems (WMS), quality management systems (QMS), process control software | +| People | Production operators, quality inspectors, logistics coordinators, supply chain managers, IT support for production systems | +| Processes | Production workflows, quality control procedures, pick-pack-ship processes, cold chain management, recall procedures | +| Data | Bills of materials, production orders, batch records, quality control test data, shipping records, inventory data | + +--- + +### DC-3.4 — Nature of Principal Risks + +**What must be described:** +Factors that have a significant effect on inherent risks in the production and distribution +system, including: + +- **Operational disruption risks:** Factory outages, equipment failure, natural disasters. +- **Supply chain risks:** Single-source raw material dependency, upstream supplier failures, geopolitical supply chain disruptions. +- **Quality and safety risks:** Product contamination, formulation errors, undisclosed ingredient substitution. +- **Cybersecurity risks to OT/ICS:** Ransomware attacks on manufacturing systems, unauthorized changes to process control systems, IT/OT convergence vulnerabilities. +- **Cybersecurity risks to IT systems:** ERP system compromise, shipping manifest manipulation, order fraud. +- **Workforce risks:** Key personnel dependency, labor disputes, training adequacy. +- **Regulatory risks:** Non-compliance with FDA, EPA, OSHA, import/export controls. +- **Third-party (sub-supplier) risks:** Risks introduced by upstream suppliers or logistics providers. + +--- + +### DC-3.5 — Goals and Objectives for Production and Distribution + +**What must be described:** +- The entity's goals and objectives for its production and distribution system: + - Quality objectives (defect rates, rejection thresholds, testing coverage). + - Safety objectives (workplace safety, product safety, food/drug safety). + - Security objectives (prevention of product tampering, unauthorized access, IP theft). + - Availability objectives (production uptime, on-time delivery rates). + - Processing integrity objectives (complete and accurate order fill rates, batch record integrity). +- How those objectives align with commitments made to downstream customers. + +--- + +### DC-3.6 — Policies and Processes Used to Achieve Goals + +**What must be described:** +The specific policies and processes implemented to achieve each goal and objective: + +| Goal Area | Example Policies and Processes | +|---|---| +| Quality | Incoming material testing, in-process quality checks, finished goods testing, certificate of analysis (CoA) issuance, deviation and CAPA management | +| Safety | HACCP plans, GMP procedures, allergen control programs, temperature and humidity monitoring, product recall procedures | +| Security | Access control to production areas, change control over recipes and formulations, anti-tampering seals, chain of custody documentation | +| Availability | Preventive maintenance schedules, equipment redundancy, backup supplier agreements, business continuity plans | +| Processing integrity | Order verification procedures, batch record review and approval, shipping verification, reconciliation of shipped vs. ordered quantities | +| Cybersecurity | Network segregation of OT from IT, patch management for production systems, authentication controls for MES/ERP | + +--- + +### DC-3.7 — Related Controls and Their Design + +**What must be described:** +- For each policy and process described under DC-3.6, the specific controls implemented. +- Control descriptions should state: + - What the control does. + - Who performs it (role or automated system). + - Frequency of operation. + - Evidence generated by the control. + +--- + +### DC-3.8 — Complementary User Layer Entity Controls (CULECs) + +**What must be described:** +Controls that downstream customers (user layer entities) are assumed to implement for the +production and distribution commitments to be fully met. + +Examples of CULECs: +- Downstream customers are responsible for verifying Certificate of Analysis (CoA) documentation before acceptance of goods. +- Downstream customers are responsible for maintaining cold chain integrity during warehousing and distribution of temperature-sensitive products. +- Downstream customers are responsible for notifying the reporting entity promptly of any quality complaints or adverse reactions observed in the finished product. +- Downstream customers are responsible for implementing receiving inspection procedures to identify damaged shipments. +- Downstream customers are responsible for configuring site-specific security settings in systems accessed via the reporting entity's customer portal. + +--- + +## Measurement Criteria — Trust Services Criteria (Subset) + +SOC for Supply Chain uses a subset of the AICPA Trust Services Criteria based on the +nature of the production/distribution commitments: + +| TSC Category | Applicable When | +|---|---| +| Security (CC1–CC9) | Always applicable — cybersecurity risks to production systems and data | +| Availability (A1) | When commitments include production uptime, delivery availability, or order fulfillment SLAs | +| Processing Integrity (PI1) | When commitments include complete, accurate, valid, timely order processing or batch record integrity | +| Confidentiality (C1) | When confidential formulations, recipes, trade secrets, or customer data are processed | +| Privacy (P1–P8) | When the production/distribution system processes personal information | + +For most manufacturing organizations, Security, Availability, and Processing Integrity are +the most relevant categories. + +--- + +## Roles in SOC for Supply Chain + +| Role | Definition | +|---|---| +| Reporting entity | The organization (producer, manufacturer, distributor) issuing the SOC for Supply Chain report | +| User layer entity | A downstream customer or business partner that relies on the reporting entity's production/distribution system | +| Sub-supplier | An upstream supplier used by the reporting entity to provide materials, components, or services forming part of the production/distribution system | +| Practitioner | The licensed CPA firm performing the examination | + +--- + +## Sub-Supplier Considerations + +When the reporting entity relies on upstream suppliers whose activities could affect the +production/distribution commitments: + +**Documentation required:** +- Identify all material sub-suppliers in the system description. +- Describe the nature of sub-supplier services and their relationship to the commitments. +- Either: + - **Carve-out:** Explicitly exclude sub-supplier controls from the description; describe monitoring controls over sub-suppliers. + - **Inclusive:** Include sub-supplier controls in the description (requires sub-supplier cooperation). + +**Common CULECs for sub-supplier scenarios:** +- The reporting entity is assumed to perform incoming testing of materials received from sub-suppliers. +- The reporting entity is assumed to qualify sub-suppliers against defined standards before use. + +--- + +## SOC for Supply Chain vs SOC 1 vs SOC 2 + +| Attribute | SOC 1 | SOC 2 | SOC for Supply Chain | +|---|---|---|---| +| Primary focus | Financial transaction controls | IT/cloud service security and trust | Production and distribution integrity | +| Description criteria | AT-C §320 system description | TSC system description | DC-3 | +| Measurement criteria | Service org's own control objectives | TSC | TSC (subset applicable to production) | +| Distribution | Restricted | Restricted | Restricted | +| Typical industries | Financial services, payroll, SaaS | Cloud/SaaS, IT services | Manufacturing, logistics, agriculture | +| Cybersecurity component | As defined in control objectives | CC1–CC9 (Security required) | CC1–CC9 (Security required) | +| Published | 2017 (SSAE 18) | 2017 (SSAE 18) | 2020 | + +--- + +## Engagement Readiness Checklist + +### Documentation Readiness + +- [ ] System description drafted covering all eight DC-3 areas +- [ ] Principal commitments to customers documented +- [ ] Legal/regulatory requirements identified +- [ ] System components (infrastructure, software, people, processes, data) documented +- [ ] Principal risk factors documented +- [ ] Goals and objectives for production/distribution documented +- [ ] Policies and processes mapped to each goal +- [ ] Controls mapped to each policy/process +- [ ] CULECs identified and documented + +### Operational Readiness + +- [ ] Controls are designed and implemented (not just documented) +- [ ] Control owners assigned for each control +- [ ] Evidence of control operation is retained (logs, approvals, inspection records, test results) +- [ ] Quality management records are complete and accessible +- [ ] Batch records, CoAs, and production logs are maintained and retrievable +- [ ] Change control procedures for production processes are operational +- [ ] Recall procedures documented and tested + +### Cybersecurity Readiness (CC1–CC9) + +- [ ] OT/ICS systems are identified and network-segmented from corporate IT +- [ ] Access to production systems is controlled and reviewed +- [ ] Change management for production software is documented +- [ ] Security monitoring includes production systems +- [ ] Incident response procedures address OT/ICS incidents +- [ ] Third-party (sub-supplier) risk program includes cybersecurity assessment +- [ ] Vulnerability management covers production technology + +--- + +## Common Findings for SOC for Supply Chain + +| Finding | Description | Remediation | +|---|---|---| +| Incomplete DC-3 description | One or more DC-3 areas are not addressed in the system description | Review DC-3 requirements; expand description draft to cover missing areas | +| Production system undocumented | Manufacturing processes not formally documented | Complete process documentation; assign document owners | +| No formal quality management | QC testing exists but is informal; records inconsistent | Implement documented QMS; standardize testing records | +| CULEC gaps | Customer commitments rely on user layer controls not listed as CULECs | Identify user layer dependencies; document CULECs explicitly | +| Sub-supplier not identified | Key material supplier not identified in description | Update sub-supplier list; determine carve-out or inclusive treatment | +| OT/ICS not in scope | Cybersecurity of production control systems excluded without justification | Evaluate whether OT/ICS falls within system boundaries; document exclusion with rationale if excluded | +| Change control absent | Production recipe or process changes occur without documented authorization | Implement and enforce change control for all production changes | +| No BCP for production | Business continuity plan exists for IT but not for production environment | Extend BCP to cover production equipment, facilities, and supply chain | + +--- + +## Frequently Asked Questions + +**Q: Is SOC for Supply Chain the same as ISO 9001?** +No. ISO 9001 is a quality management system certification issued by an ISO accredited certification +body. SOC for Supply Chain is an AICPA attestation engagement performed by a licensed CPA firm +that examines controls over production and distribution systems against Trust Services Criteria. +ISO 9001 focuses on quality management processes; SOC for Supply Chain addresses security, +availability, processing integrity, and quality-related controls through the TSC measurement lens. + +**Q: Who distributes the SOC for Supply Chain report?** +SOC for Supply Chain is a restricted-use report. It is shared only with: (1) the management +of the reporting entity; (2) downstream customers (user layer entities) that rely on the +production/distribution system; and (3) their auditors. It is not a publicly available report. + +**Q: What evidence should a manufacturer collect for a Type 2 examination?** +Evidence should demonstrate consistent operation of each control throughout the period. Types of +evidence include: production batch records, quality control test results, CoAs, equipment +maintenance logs, access control records, change authorization records, audit logs from MES/ERP +systems, incoming inspection reports, CAPA records, temperature monitoring records, and incident +reports. + +**Q: Can SOC for Supply Chain and SOC 2 be issued for the same organization?** +Yes. A technology company that also manufactures hardware, for example, could obtain a SOC 2 +report for its cloud services and a SOC for Supply Chain report for its hardware manufacturing +operations. The reports address different systems with different criteria. + +**Q: How does SOC for Supply Chain address cybersecurity in OT environments?** +The CC1–CC9 Security criteria apply to all technology systems within the production/distribution +system boundary, including operational technology (OT), industrial control systems (ICS), SCADA +systems, and manufacturing execution systems. The description under DC-3 must identify OT/ICS +components and the cybersecurity controls applied to them. This is an area that receives +increased scrutiny from practitioners given the elevated risk of ICS/OT compromise in +manufacturing environments. diff --git a/plugins/soc/skills/soc/references/soc1-ssae18.md b/plugins/soc/skills/soc/references/soc1-ssae18.md new file mode 100644 index 0000000..e536b6f --- /dev/null +++ b/plugins/soc/skills/soc/references/soc1-ssae18.md @@ -0,0 +1,315 @@ +# SOC 1 — SSAE 18 AT-C Section 320 Reference + +## Overview + +SOC 1 (Service Organization Controls 1) reports are attestation engagements performed under +**SSAE 18, AT-C Section 320** (*Reporting on an Examination of Controls at a Service Organization +Relevant to User Entities' Internal Control Over Financial Reporting*), issued by the American +Institute of Certified Public Accountants (AICPA), effective **May 1, 2017**. + +SOC 1 reports replaced reports issued under: +- **SSAE 16** (AT 801) — effective June 1, 2011 to April 30, 2017 +- **SAS 70** (*Reports on the Processing of Transactions by Service Organizations*) — superseded 2011 + +--- + +## Applicable Standards + +| Section | Title | Purpose | +|---|---|---| +| AT-C Section 105 | Concepts Common to All Attestation Engagements | Overarching attestation concepts; independence, professional judgment | +| AT-C Section 205 | Examination Engagements | General examination standards applicable to all examinations | +| AT-C Section 320 | Reporting on Controls at a Service Organization Relevant to User Entities' ICFR | Specific requirements for SOC 1 reports | + +--- + +## Roles and Definitions + +| Role | Definition | +|---|---| +| Service organization | An entity that provides services to user entities that are likely to be relevant to those user entities' ICFR | +| User entity | An entity that uses a service organization and for which the service organization's controls may be relevant to the user entity's ICFR | +| Service auditor | The CPA firm engaged to perform the SOC 1 examination | +| User auditor | The CPA firm auditing a user entity's financial statements | +| Subservice organization | A service organization used by the reporting service organization to perform part of the services provided to user entities | + +--- + +## Report Types + +### Type 1 — Design as of a Specific Date + +A Type 1 report addresses two things as of a specific date: +1. Whether management's description of the service organization's system is **fairly presented**. +2. Whether the controls are **suitably designed** to provide reasonable assurance that the specified control objectives would be achieved if the controls operated as described. + +A Type 1 report does **not** address operating effectiveness. It cannot be used to satisfy user auditor requirements for reliance on service organization controls. + +### Type 2 — Design and Operating Effectiveness Over a Period + +A Type 2 report addresses three things over a specified period: +1. Whether management's description is **fairly presented**. +2. Whether the controls are **suitably designed** to achieve the control objectives. +3. Whether the controls **operated effectively** throughout the specified period. + +**Minimum period:** There is no hard minimum in the standard; however, the AICPA guidance +and common practice establish that a period of less than six months may not provide sufficient +evidence of consistent operation. A 12-month period is the most common. + +--- + +## System Description Requirements (AT-C §320.25–.27) + +The service organization's management is responsible for preparing the system description. +It must address: + +### 1. Services Provided +- The nature of the services provided to user entities. +- Principal service commitments (e.g., processing accuracy, timeliness, confidentiality). +- System requirements arising from contracts, regulations, and service-level agreements. + +### 2. System Components (Five-Part Model) + +| Component | Contents | +|---|---| +| Infrastructure | Physical and hardware components: servers, network equipment, storage, data centers, facilities | +| Software | System software (OS, middleware), application programs, databases, reporting tools | +| People | Personnel involved in service delivery: operators, administrators, developers, management | +| Processes | Automated and manual procedures that are part of service delivery | +| Data | Transactions, master files, tables, databases, input data, output reports | + +### 3. System Boundaries +- What is within the service organization's control vs. what is within the control of user entities or subservice organizations. +- Physical and logical boundaries (network diagrams, data flow diagrams may support this). + +### 4. Control Environment and Key Control Areas +The description must cover: +- Control environment (tone at the top, entity-level controls, COSO framework components as applicable) +- Risk assessment processes +- Information and communication +- Monitoring activities +- Control activities (mapped to each control objective) + +### 5. Complementary User Entity Controls (CUECs) +Controls that user entities are assumed to have in place for the control objectives to be met. +These must be explicitly listed. Examples: +- User entities are responsible for the accuracy of input data submitted to the service organization. +- User entities are responsible for reviewing exception reports provided by the service organization. +- User entities are responsible for managing their own logical access to the service organization's portal. + +### 6. Subservice Organization Controls +- **Carve-out method:** Describe the functions performed by the subservice organization and state that controls at the subservice organization are excluded from the description. +- **Inclusive method:** Include the subservice organization's system description and controls; subservice organization provides its own assertion. + +### 7. Changes During the Period (Type 2 Only) +Any significant changes to the system or controls during the period must be described. +Changes must be documented with effective dates. + +--- + +## Control Objectives + +Control objectives are **not prescribed by AT-C Section 320**. The service organization defines +them based on the nature of its services and the commitments made to user entities. + +### Guidance for Drafting Control Objectives + +A control objective should: +- Start with a statement of what is to be achieved (not how). +- Be specific enough that it can be evaluated — either met or not met. +- Align with user entity ICFR needs. +- Be testable by the service auditor. + +**Format:** "Controls provide reasonable assurance that [what is to be achieved]." + +### Common Control Objective Areas + +| Area | Example Control Objective | +|---|---| +| Transaction processing | Controls provide reasonable assurance that transactions are processed accurately, completely, and only with proper authorization. | +| Logical access | Controls provide reasonable assurance that logical access to production systems and data is restricted to authorized users. | +| Physical access | Controls provide reasonable assurance that physical access to data centers and server rooms is restricted to authorized personnel. | +| Change management | Controls provide reasonable assurance that changes to production systems are authorized, tested, and documented prior to implementation. | +| Computer operations | Controls provide reasonable assurance that batch jobs are processed as scheduled and exceptions are monitored and resolved. | +| Data backup and recovery | Controls provide reasonable assurance that data is backed up regularly and can be recovered in the event of an incident. | +| Network security | Controls provide reasonable assurance that network security events are monitored and unauthorized access attempts are identified and addressed. | +| Incident management | Controls provide reasonable assurance that incidents affecting service delivery are identified, escalated, and resolved in accordance with defined procedures. | +| Subservice organization monitoring | Controls provide reasonable assurance that services provided by subservice organizations are monitored for compliance with performance commitments. | +| New user provisioning | Controls provide reasonable assurance that user access is provisioned based on authorized requests and that access is commensurate with job responsibilities. | +| User access deprovisioning | Controls provide reasonable assurance that access is removed upon user termination or role change. | +| Patch management | Controls provide reasonable assurance that security patches are evaluated and applied within a defined timeframe. | + +--- + +## System Description Checklist + +Use this checklist to evaluate completeness of a SOC 1 system description: + +- [ ] Nature of services provided is clearly described +- [ ] Principal service commitments are stated +- [ ] All five system components (infrastructure, software, people, processes, data) are addressed +- [ ] System boundaries are defined (what is in scope, what is carved out) +- [ ] The five COSO components are addressed (control environment, risk assessment, information/communication, monitoring, control activities) +- [ ] CUECs are listed explicitly +- [ ] Subservice organizations are identified; carve-out or inclusive method stated +- [ ] For Type 2: changes to the system during the period are documented +- [ ] Control objectives are clearly stated +- [ ] Controls are mapped to each control objective + +--- + +## Management's Assertion + +Management of the service organization must provide an assertion that: + +For **Type 1:** +1. The description fairly presents the service organization's system as of the specified date. +2. The controls included in the description are suitably designed to provide reasonable assurance that the specified control objectives would be achieved if the controls operated as described. + +For **Type 2:** +1. The description fairly presents the service organization's system throughout the specified period. +2. The controls are suitably designed. +3. The controls operated effectively throughout the period to provide reasonable assurance that the control objectives were achieved. + +--- + +## Service Auditor Opinion Types + +| Opinion Type | When Used | +|---|---| +| Unmodified | Description is fairly presented; controls are suitably designed; (Type 2) controls operated effectively | +| Qualified | One or more items are materially misstated or one or more control objectives were not met, but the exception is not pervasive | +| Adverse | Exceptions are pervasive; the description is not fairly presented or controls are not suitably designed/effective | +| Disclaimer | Service auditor is unable to obtain sufficient evidence to form an opinion | + +**Modified opinions must include:** A basis for the modification paragraph that clearly describes the matter giving rise to the modification and the effect on the opinion. + +--- + +## Testing for Type 2 — Operating Effectiveness + +The service auditor must test whether controls operated effectively throughout the entire period. + +### Testing Methods + +| Method | Description | Typical Use | +|---|---|---| +| Inquiry | Asking personnel about procedures | Preliminary understanding; corroborated by other methods | +| Observation | Watching a control being performed | Controls with no documentary evidence | +| Inspection | Reviewing documents, reports, or logs | High-frequency controls; access logs; change records | +| Re-performance | Service auditor re-performs the control | High-risk controls; automated controls | +| Analytical procedures | Evaluating data for plausible relationships | High-volume transaction controls | + +### Sampling Guidance + +The AICPA SOC 1 guide provides the following general sampling expectations for Type 2 testing. +These are not mandatory minimums but reflect common practice: + +| Control frequency | Typical sample size | +|---|---| +| Annual (performed once per year) | 1 (entire population) | +| Quarterly | 2–4 | +| Monthly | 3–6 | +| Weekly | 5–15 | +| Daily | 15–30 | +| Multiple times per day / continuous | 25–45 | +| Event-driven / per-transaction | 25–60 depending on volume | + +--- + +## Common SOC 1 Findings and Deficiencies + +| Finding Type | Description | Typical Cause | +|---|---|---| +| **Control not in place** | No evidence a control was performed | Control designed but never implemented; procedure not followed | +| **Deviation** | Control operated but one or more exceptions noted during the period | Inconsistent application; staff turnaround; system defect | +| **Description gap** | A process in scope is not described in the system description | Incomplete scoping; processes added during period not updated in description | +| **CUEC overreliance** | A control objective can only be achieved with user entity controls, but CUECs are not listed | Insufficient scoping; service org attempting to shift responsibility without disclosure | +| **Stale CUEC list** | CUECs listed do not reflect actual current user entity responsibilities | Not reviewed annually | +| **Undisclosed change** | System or control changed during the period; not reflected in description | Change management process does not include description update step | +| **Subservice org gap** | Functions performed by a subservice organization not identified | New vendor engagement not captured; carve-out scope not updated | +| **Access review not performed** | User access review not conducted per stated control | Manual control with no enforcement mechanism; ownership unclear | + +--- + +## Reading and Using a SOC 1 Report (User Auditor Perspective) + +When a user auditor receives a SOC 1 Type 2 report from their client's service organization, +they must: + +1. **Evaluate relevance** — Confirm the report covers the period that includes the user entity's financial period. +2. **Assess scope coverage** — Confirm the service organization's system description covers the relevant transactions processed on behalf of the user entity. +3. **Evaluate CUECs** — Determine whether the user entity has the complementary controls in place. If CUECs are not implemented, the service auditor's opinion provides no assurance. +4. **Review the opinion** — A qualified or adverse opinion means the user auditor cannot rely on the service org's controls. +5. **Follow up on deviations** — If the Type 2 report notes deviations (exceptions in control testing), the user auditor must assess whether those deviations could affect the financial statements of the user entity. +6. **Assess subservice organizations** — If carve-out method is used, evaluate whether a separate SOC 1 report for the subservice organization is needed. + +--- + +## SOC 1 Readiness Checklist + +Use this checklist to evaluate SOC 1 readiness before engaging a service auditor: + +**Scoping and Documentation** +- [ ] Services have been clearly defined and mapped to user entity ICFR +- [ ] System components documented (infrastructure, software, people, processes, data) +- [ ] System boundaries defined in writing +- [ ] Control objectives drafted and reviewed with service auditor +- [ ] CUECs listed with user entity in mind + +**Controls** +- [ ] For each control objective, at least one control is designed and implemented +- [ ] Controls are documented with owner, frequency, and evidence +- [ ] Control execution is consistent (no gaps in performance) +- [ ] Evidence of control operation is retained (logs, approvals, screenshots, sign-offs) + +**Access Management** +- [ ] Access provisioning and deprovisioning procedures documented +- [ ] Access reviews performed on the defined cycle +- [ ] Privileged access managed separately with additional controls + +**Change Management** +- [ ] Change request process documented with approval workflow +- [ ] Emergency change procedures exist +- [ ] Deployment logs maintained + +**Monitoring** +- [ ] Logs reviewed on defined schedule +- [ ] Incident response procedures documented and tested +- [ ] Subservice organizations monitored per stated controls + +**Subservice Organizations** +- [ ] All subservice organizations identified +- [ ] Carve-out or inclusive method decision documented +- [ ] If carve-out: monitoring controls over subservice organizations implemented + +--- + +## Frequently Asked Questions + +**Q: Can a service organization issue a SOC 1 report for itself?** +No. AT-C Section 320 requires the examination to be performed by an independent CPA firm +(the service auditor). Management's assertion is part of the report, but the examination and +opinion must come from an independent practitioner. + +**Q: How long should the review period be for a Type 2?** +The AICPA does not specify a mandatory minimum period, but the AICPA SOC 1 guide notes that +a period of less than six months may not provide sufficient evidence. The most common period +is 12 months, aligned with the user entity's fiscal year. + +**Q: What is the difference between SOC 1 and SOC 2?** +SOC 1 focuses on controls relevant to user entities' ICFR. SOC 2 focuses on the AICPA Trust +Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy), +which are not limited to financial reporting. SOC 2 is used when customers need assurance +about the security and reliability of a service organization's systems. + +**Q: Does a SOC 1 cover cybersecurity?** +Only to the extent that cybersecurity controls are within the stated control objectives. A +SOC 1 report for a payroll processor might include logical access controls (which relate to +system security), but cybersecurity program maturity is not the primary focus. SOC 2 or SOC +for Cybersecurity is more appropriate for comprehensive security assurance. + +**Q: Can a SOC 1 report be shared publicly?** +No. SOC 1 reports are restricted-use documents. They may only be provided to the service +organization's management, the user entities that used the service during the period, and +their auditors. They should not be posted publicly or shared with prospective customers. diff --git a/plugins/soc/skills/soc/references/soc3-general-use.md b/plugins/soc/skills/soc/references/soc3-general-use.md new file mode 100644 index 0000000..866709c --- /dev/null +++ b/plugins/soc/skills/soc/references/soc3-general-use.md @@ -0,0 +1,176 @@ +# SOC 3 — General Use Report Reference + +## Overview + +SOC 3 reports are general use attestation reports based on the same AICPA Trust Services +Criteria (TSC) as SOC 2. They are designed to communicate to the public that an organization +received a clean opinion from an independent CPA firm, without disclosing the detailed control +descriptions, testing procedures, or test results included in a SOC 2 report. + +**Governing standard:** SSAE 18, AT-C Section 205 (*Examination Engagements*) +**Criteria applied:** AICPA Trust Services Criteria (2017, with 2022 Revised Points of Focus) +**Distribution:** Unrestricted — may be posted publicly, shared freely with customers, prospects, and partners + +--- + +## SOC 3 vs SOC 2 — Side-by-Side Comparison + +| Attribute | SOC 2 | SOC 3 | +|---|---|---| +| Governing standard | SSAE 18 AT-C §205 + TSC | SSAE 18 AT-C §205 + TSC | +| Distribution | Restricted (specific parties under NDA) | Unrestricted (general public) | +| System description | Full, detailed description of the system | Brief, high-level description only | +| Controls documented | Yes — all in-scope controls described | No — controls not described in report | +| Tests of controls | Yes — testing procedures and results included | No — no test details in report | +| Results of tests | Yes — deviations and exceptions reported | No — only the overall opinion | +| AICPA seal permitted | No | Yes | +| Suitable for posting on website | No | Yes | +| Suitable for user auditor reliance | Yes | No | +| Suitable for security questionnaire response | Yes (restricted sharing) | Yes (openly shareable) | +| Can be issued simultaneously with SOC 2? | N/A | Yes — same examination period | + +--- + +## Trust Services Criteria Categories + +A SOC 3 report covers one or more of the five Trust Services Criteria categories, identical to SOC 2: + +| Category | Code | Always Required? | +|---|---|---| +| Security (Common Criteria) | CC | Yes — must be included | +| Availability | A | Optional | +| Confidentiality | C | Optional | +| Processing Integrity | PI | Optional | +| Privacy | P | Optional | + +The same scope principles as SOC 2 apply. Security (CC) is not optional. Additional categories +are included based on service commitments to customers. + +--- + +## SOC 3 Report Structure + +A SOC 3 report contains three components: + +### 1. Management's Assertion +Management asserts that: +- The description of the system is fairly presented. +- Controls operated effectively throughout the period with respect to the TSC categories covered. + +### 2. Practitioner's Short-Form Report +The CPA firm issues a short-form opinion that states: +- The examination was conducted in accordance with SSAE 18 AT-C Section 205. +- In the practitioner's opinion, the entity maintained effective controls over the TSC categories covered throughout the period. + +The short-form report does **not** include: +- A description of each test procedure. +- Results of individual tests. +- A list of deviations or exceptions. + +### 3. Brief System Description +A high-level description of the services and system. This is deliberately less detailed than +the SOC 2 system description. It typically covers: +- The services provided. +- The geographic locations if relevant. +- The major categories of data processed. +- The TSC categories covered. + +--- + +## Relationship Between SOC 2 and SOC 3 + +An organization typically obtains a SOC 3 based on the **same examination** as a SOC 2 Type 2. +The same CPA firm performs the same testing against the same TSC for the same period. From +that single examination, it issues: + +- The full SOC 2 Type 2 report — distributed only to specified parties. +- The SOC 3 report — distributed publicly or used for the AICPA seal. + +**A standalone SOC 3 without an underlying SOC 2 examination is possible** but uncommon. The +AICPA guidance permits a practitioner to issue a SOC 3 from an examination conducted solely +for that purpose. In practice, most organizations obtain SOC 2 as the primary deliverable and +add SOC 3 for public use. + +--- + +## AICPA SOC Service Organization Seal + +Organizations that receive an unmodified (clean) SOC 3 practitioner's report may display the +**AICPA SOC Service Organization seal**. The seal communicates to stakeholders that an +independent CPA firm has examined the organization's controls and found them effective. + +### Seal Requirements + +- The report must be an unmodified opinion (no qualifications). +- The seal must include text specifying the TSC categories covered. +- The seal must include the period covered. +- Only licensed AICPA member CPA firms may award the seal. +- The AICPA licenses the use of the seal; the organization must comply with AICPA's seal usage policies. + +### Seal Use Restrictions + +- The seal may not be altered, modified, or used in a misleading context. +- The seal may not imply AICPA endorsement of any particular product or service. +- If a subsequent examination results in a modified opinion, the previous seal reference must be updated. + +--- + +## When to Recommend SOC 3 + +Recommend SOC 3 in these situations: + +| Scenario | Reason | +|---|---| +| Organization wants a publicly shareable security certification | SOC 3 is freely distributable; SOC 2 is not | +| Marketing or sales team needs evidence to share with prospects | SOC 3 can be placed on the website or included in sales materials | +| Customer RFPs ask for "SOC report" without specifying SOC 2 | SOC 3 satisfies general requests where detail is not required | +| Organization already has SOC 2 and wants incremental value | SOC 3 adds public credibility at minimal additional cost | +| Small organization wants public assurance without disclosing test detail | SOC 3 provides global assurance without revealing control specifics | + +**When SOC 3 is NOT sufficient:** +- User auditors require SOC 2 Type 2 to rely on service organization controls for ICFR purposes. +- A sophisticated customer or partner requires a full SOC 2 report with test procedures and results. +- The organization's vendor risk management program requires signed NDA and full SOC 2. + +--- + +## SOC 3 Procurement Guidance (Customer Perspective) + +When evaluating a vendor's SOC 3 report: + +1. **Confirm the report is current** — SOC 3 reports should cover a period ending within the last 12 months. An older report may not reflect current controls. +2. **Check TSC scope** — A SOC 3 covering Security only may not address Availability or Privacy. If these are important, ask for SOC 2 or a separate assessment. +3. **Identify the CPA firm** — The report must be issued by a licensed CPA firm. Confirm the firm is reputable and experienced in SOC engagements. +4. **Understand the limitation** — SOC 3 tells you the controls were effective; it does not tell you what the controls were, how they were tested, or whether there were any exceptions. For deeper assurance, request the full SOC 2 report under NDA. +5. **Ask about the underlying SOC 2** — Confirm there is a full SOC 2 Type 2 report available under NDA if needed for your own audit or regulatory requirements. + +--- + +## Common Questions + +**Q: Can an organization claim SOC 3 compliance?** +"Compliance" is not the correct term for SOC 3. SOC 3 is an attestation — a CPA firm examined +the organization's controls and issued an opinion. The correct phrasing is "we received an +unmodified SOC 3 report" or "our controls were examined under SOC 3." + +**Q: Does SOC 3 replace SOC 2?** +No. SOC 3 does not replace SOC 2. They serve different purposes and audiences. SOC 3 is for +public audiences; SOC 2 is for specific parties (user entities, user auditors) that need +detailed control information. + +**Q: Is a SOC 3 the same as ISO 27001 certification?** +No. ISO 27001 is a certification against an information security management system standard, +issued by an accredited certification body. A SOC 3 is an attestation by a CPA firm that the +organization's controls met the AICPA Trust Services Criteria during the examination period. +Both provide assurance about information security controls, but they use different frameworks, +are issued by different types of bodies, and convey different types of assurance. + +**Q: How often should a SOC 3 be renewed?** +The AICPA does not mandate a renewal period, but the seal displays the period covered by the +examination. In practice, annual examinations are the norm to maintain a current report. + +**Q: Can SOC 3 cover multiple TSC categories?** +Yes. A SOC 3 can cover Security, Availability, Confidentiality, Processing Integrity, and +Privacy — the same categories as SOC 2. Most SOC 3 reports cover Security (CC) as a minimum. +Additional categories are included when the organization has contractual or regulatory +commitments related to those categories. diff --git a/plugins/uk-nis-csrb/.claude-plugin/plugin.json b/plugins/uk-nis-csrb/.claude-plugin/plugin.json new file mode 100644 index 0000000..74347f0 --- /dev/null +++ b/plugins/uk-nis-csrb/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "uk-nis-csrb", + "description": "UK Cyber Security and Resilience Bill (CSRB) readiness advisor — expanded scope beyond NIS Regulations, managed service provider obligations, enhanced incident reporting, regulator powers, critical infrastructure protection, and transition planning from NIS Regulations 2018.", + "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": [ + "uk-csrb", + "cyber-security-resilience-bill", + "csrb", + "nis-regulations", + "managed-service-providers", + "incident-reporting", + "critical-infrastructure", + "uk-cybersecurity", + "resilience", + "grc" + ] +} diff --git a/plugins/uk-nis-csrb/skills/uk-nis-csrb/SKILL.md b/plugins/uk-nis-csrb/skills/uk-nis-csrb/SKILL.md new file mode 100644 index 0000000..398833a --- /dev/null +++ b/plugins/uk-nis-csrb/skills/uk-nis-csrb/SKILL.md @@ -0,0 +1,419 @@ +--- +name: uk-nis-csrb +description: > + Expert advisor on the UK Cyber Security and Resilience Bill (CSRB), announced in the King's + Speech on 17 July 2024. Use this skill whenever a user asks about the CSRB, Cyber Security + and Resilience Bill, UK cybersecurity legislation reform, expansion of NIS Regulations scope + to managed service providers (MSPs), new incident reporting obligations under the CSRB, + enhanced regulator powers under the Bill, data centre security obligations, critical national + infrastructure (CNI) cyber resilience, CSRB readiness assessments, transition planning from + NIS Regulations 2018, CSRB regulatory framework, or any question about how the CSRB changes + existing UK cyber regulatory requirements. Also trigger for comparisons between the NIS + Regulations 2018 and the CSRB, or questions about how to prepare for CSRB obligations before + the Bill comes into force. When in doubt, use this skill. +--- + +# UK Cyber Security and Resilience Bill (CSRB) — Compliance Skill + +You are an expert advisor on the UK Cyber Security and Resilience Bill (CSRB). You help organisations understand the proposed legislative changes, assess their readiness, plan transition from the NIS Regulations 2018, and prepare for new obligations that the Bill will create when enacted. + +> **Important — Bill Status:** The Cyber Security and Resilience Bill is proposed UK legislation announced in the King's Speech on 17 July 2024. As of the date of this skill, the Bill has been introduced to Parliament but has not yet received Royal Assent and is not yet law. The provisions described in this skill are based on the Bill's stated policy objectives, Department for Science, Innovation and Technology (DSIT) consultations, and published impact assessments. The final legislation may differ from the proposals described here. Always verify the current status at bills.parliament.uk. + +> **Legal disclaimer:** This guidance is for informational purposes only and does not constitute legal advice. For formal compliance conclusions, consult a qualified legal or regulatory specialist. + +--- + +## Quick Reference: What Does the User Need? + +| User Goal | Go To | +|---|---| +| "What is the CSRB?" / overview | [CSRB Overview](#1-csrb-overview) | +| "Are we in scope?" / expanded scope | [Scope and Applicability](#2-scope-and-applicability) | +| New incident reporting requirements | [Enhanced Incident Reporting](#3-enhanced-incident-reporting) | +| Enhanced regulator powers | [Regulator Powers](#4-regulator-powers) | +| Readiness assessment / gap analysis | [CSRB Readiness Assessment](#5-csrb-readiness-assessment) | +| Transitioning from NIS Regulations 2018 | [Transition from NIS Regulations](#6-transition-from-nis-regulations) | +| Policy and document generation | [Policy and Document Generation](#7-policy-and-document-generation) | +| Comparing CSRB with NIS Regs / EU NIS2 | [Comparative Analysis](#8-comparative-analysis) | + +--- + +## 1. CSRB Overview + +### 1.1 Why the CSRB Is Being Introduced + +The UK government identified that the NIS Regulations 2018 (SI 2018/506), while effective at the time of enactment, have become insufficient to address the evolving cyber threat landscape. The stated policy rationale for the CSRB includes: + +- **Expanding scope to managed service providers:** MSPs were recognised as a significant attack vector (as demonstrated by high-profile incidents such as the MOVEit exploitation in 2023 and the Capita breach). MSPs are not currently captured by the NIS Regulations. +- **Improving incident reporting:** The existing NIS incident reporting regime focusses on significant impacts that have already occurred. The CSRB is designed to capture a broader set of incidents and near-misses to enable earlier regulatory and government intervention. +- **Strengthening regulator powers:** Competent Authorities under the NIS Regulations have limited proactive powers. The CSRB would give regulators stronger information-gathering and enforcement tools. +- **Protecting data centres:** Large data centres were assessed to represent critical national infrastructure but were not in scope of the NIS Regulations. The CSRB addresses this. +- **Modernising the framework:** The CSRB reflects the cyber threat landscape of the 2020s, including supply chain attacks, ransomware, and the criticality of cloud and managed services. + +### 1.2 Key Policy Announcements and Timeline + +| Event | Date | +|-------|------| +| Cyber Security and Resilience Bill announced in King's Speech | 17 July 2024 | +| DSIT published background to the Bill | July 2024 | +| DSIT consultation on expanded scope (MSPs and data centres) | 2023-2024 (pre-announcement) | +| Bill introduced to Parliament | 2025 | +| Parliamentary passage | In progress (as of 2026) | +| Expected Royal Assent | Subject to parliamentary process | +| Expected commencement | Subject to secondary legislation after Royal Assent | + +### 1.3 High-Level Changes + +The CSRB is designed to: +1. **Expand the scope** of the existing NIS regulatory framework to include managed service providers, data centres, and potentially other categories not currently covered +2. **Strengthen incident reporting** to require reporting of a wider category of incidents with more standardised details and potentially shorter timelines +3. **Enhance regulator powers** to enable Competent Authorities to be more proactive in assessing and enforcing compliance +4. **Introduce new security duties** that reflect current best practice +5. **Align more closely** with equivalent frameworks internationally (EU NIS2 Directive, which came into force October 2024) + +--- + +## 2. Scope and Applicability + +### 2.1 Retained Scope from NIS Regulations 2018 + +The CSRB retains the full scope of the NIS Regulations 2018. Existing OES and DSPs remain in scope: + +**Operators of Essential Services (OES) sectors:** +- Energy: electricity, oil, gas +- Transport: air, rail, road, maritime +- Health +- Drinking water +- Digital infrastructure: IXPs, DNS providers, TLD registries + +**Digital Service Providers (DSPs):** +- Online marketplaces +- Online search engines +- Cloud computing services (IaaS, PaaS, SaaS — above the small enterprise threshold) + +Load `references/scope-expansion.md` for full scope detail, including new categories. + +### 2.2 New In-Scope Categories Under the CSRB + +#### Managed Service Providers (MSPs) + +A managed service provider (MSP) is an entity that remotely manages a customer's IT infrastructure and/or end-user systems, typically on an ongoing subscription basis. + +**Why MSPs are newly in scope:** +The CSRB recognises that MSPs occupy a privileged position in customer environments — they typically have elevated access to IT systems, data, and security controls. A compromise of an MSP can cascade to multiple customers simultaneously, creating systemic risk across critical sectors. + +**Indicative scope criteria for MSPs:** +- The MSP provides ongoing remote management of IT infrastructure or security services to customers in critical sectors (OES sectors or public sector) +- The MSP's compromise could affect multiple organisations or essential services +- Size thresholds (to be defined by secondary legislation — likely connected to number of critical sector customers or revenue from such services) + +**Services likely to be in scope:** +- Managed Detection and Response (MDR) +- Managed Security Operations Centre (SOC) services +- Managed Network Services +- Managed Backup and Disaster Recovery +- Managed Cloud Services + +**Services less likely to be in scope (indicative, based on policy intent):** +- Software-as-a-service providers without ongoing management of customer infrastructure +- IT resellers without managed services +- Break-fix IT support without ongoing remote access + +#### Large Data Centres + +The CSRB is expected to designate large-scale data centres as a category of critical infrastructure in scope of mandatory security and resilience obligations. + +**Indicative scope criteria for data centres:** +- Data centre operators above a certain capacity threshold (exact threshold subject to secondary legislation) +- Data centres hosting critical or government systems +- Colocation data centre operators (not just cloud service provider-operated facilities) + +**Key concern:** A successful attack on a large data centre can affect multiple tenants simultaneously, creating cascading impacts across critical services. + +### 2.3 Determining CSRB Scope (Readiness Assessment) + +Until the CSRB receives Royal Assent and secondary legislation defines precise thresholds, organisations should assess their likely scope using the following questions: + +| Question | If YES — likely in scope | +|----------|--------------------------| +| Is your organisation currently designated as OES or DSP? | Continuing obligations under CSRB | +| Do you provide IT/security management services to critical sector organisations? | Likely MSP scope | +| Do you operate a data centre above significant scale? | Likely data centre scope | +| Do you have elevated remote access to multiple organisations' systems? | Consider MSP scope | +| Could a compromise of your systems cascade to essential services? | CSRB likely applies | + +--- + +## 3. Enhanced Incident Reporting + +### 3.1 Key Changes from NIS Regulations 2018 + +The CSRB proposes material changes to the incident reporting regime: + +| Aspect | NIS Regulations 2018 | CSRB (Proposed) | +|--------|---------------------|-----------------| +| Threshold for reporting | Significant/substantial impact on service continuity | Lower threshold — broader set of incidents | +| Timeline | As soon as reasonably practicable (72 hours guidance) | Compressed timeline likely (potential 24-hour initial notification) | +| Scope of reportable incidents | Incidents with impact on essential/digital service | Including near-misses; precursor events; supply chain incidents | +| Who reports | Individual OES/DSP | Including MSPs | +| Regulator visibility | Post-incident notification | More real-time reporting capability | +| Standardisation | No standard format specified | Standardised reporting formats expected | + +### 3.2 New Categories of Reportable Events + +The CSRB policy intent includes expanding reporting to cover: + +1. **Near-miss incidents** — Events that could have had significant impact but were contained before service disruption +2. **Ransomware attacks** — Including ransomware deployments that are contained before service impact (potentially creating a separate reporting track for ransomware events) +3. **Supply chain compromise** — Incidents involving compromise of a supplier that has access to the organisation's systems +4. **Data exfiltration events** — Theft of data from systems underpinning critical services +5. **Precursor activity** — Detected reconnaissance or preparatory activity that indicates potential imminent attack + +### 3.3 Improved Information Sharing Objective + +The CSRB is designed to give the government (DSIT, NCSC) better visibility of the cyber threat landscape across critical sectors. This means: + +- Incident reports may be shared (in anonymised or aggregated form) across sectors +- NCSC may issue threat advisories based on reported patterns +- Cross-sector intelligence will inform national cyber defence + +### 3.4 Practical Preparation for Enhanced Reporting + +Organisations should prepare for CSRB reporting requirements by: + +1. **Reviewing detection capability** — Ensure security monitoring can detect the wider range of reportable events (near-misses, precursor activity) +2. **Updating incident classification** — Expand incident classification frameworks to capture CSRB reportable categories +3. **Reducing reporting timelines** — Update Incident Response Plans to operate on 24-hour reporting timelines, not just 72 hours +4. **Standardising report content** — Prepare for structured reporting formats +5. **Reviewing supply chain monitoring** — Build processes to detect and report supplier-side incidents + +Load `references/incident-reporting-csrb.md` for detailed guidance and templates. + +--- + +## 4. Regulator Powers + +### 4.1 Enhanced Competent Authority Powers + +The CSRB provides Competent Authorities with stronger proactive and enforcement tools compared with the NIS Regulations 2018: + +| Power | NIS Regs 2018 | CSRB (Proposed) | +|-------|--------------|-----------------| +| Information requests | Yes (reactive) | Yes — with expanded proactive capability | +| Security audits | Yes (can commission) | Yes — with stronger mandate | +| Inspections | Yes | Yes — more extensive | +| Directions to improve security | Enforcement notice after failure | Proactive notices/directions before failure | +| Enforcement notices | Yes — after failure | Yes | +| Financial penalties | Up to 17M GBP | May increase — to be specified in legislation | +| Sharing of information | Limited | Enhanced cross-CA information sharing | + +### 4.2 Proactive Powers + +A key shift in the CSRB is the move from reactive enforcement to **proactive oversight**: + +- Competent Authorities may issue directions requiring organisations to undertake specific security assessments or audits before any failure occurs +- CAs may share threat intelligence directly with in-scope organisations +- CAs may require evidence of compliance testing (penetration tests, CAF self-assessments) on a scheduled basis rather than only following incidents + +### 4.3 New Competent Authorities (MSPs / Data Centres) + +The CSRB will designate Competent Authorities for newly in-scope categories: +- **MSPs:** Likely DSIT or Ofcom (to be confirmed in secondary legislation) +- **Large data centres:** Likely DSIT (to be confirmed in secondary legislation) + +Existing CAs retain responsibility for their current sectors. + +### 4.4 Implications for Organisations + +- Expect more frequent CA engagement (proactive audits, directed assessments) +- Ensure documented evidence of security measures is readily available +- Compliance programme should be continuous, not just audit-responsive +- Designated security contacts should be maintained and accessible + +--- + +## 5. CSRB Readiness Assessment + +### Step 1: Determine Current NIS Status + +Confirm: +- Is the organisation currently an OES or DSP under the NIS Regulations 2018? +- If yes, what is its current compliance posture against the NCSC CAF? +- Identify any outstanding gaps from the most recent CAF self-assessment + +### Step 2: Assess CSRB Expansion Impact + +Assess whether the organisation falls into new CSRB categories: +- MSP: Does it provide managed IT or security services to critical sector organisations? +- Data centre: Does it operate data centre facilities above likely thresholds? +- New Competent Authority: Identify who the new CA will be + +### Step 3: Review Incident Reporting Capability + +Gap analysis against CSRB reporting requirements: + +| Capability | Current State | CSRB Gap | +|-----------|--------------|----------| +| Detection of near-miss events | [Describe] | [Gap] | +| Detection of precursor / reconnaissance | [Describe] | [Gap] | +| 24-hour reporting workflow | [Yes/No] | [Gap] | +| Standardised incident classification | [Describe] | [Gap] | +| Supply chain incident monitoring | [Describe] | [Gap] | + +### Step 4: Review Security Controls + +Ensure existing CAF/NIS controls are current: +- Latest CAF self-assessment date? +- Any outstanding NIS Conditions from Competent Authority? +- Are controls tested (penetration testing, exercises)? + +### Step 5: Produce Readiness Report + +Structure readiness output as: + +``` +## CSRB Readiness Assessment — [Organisation Name] + +**Assessment Date:** [YYYY-MM-DD] +**Current NIS Status:** [OES / DSP / Not currently in scope] +**Likely CSRB Status:** [OES (continuing) / DSP (continuing) / MSP (new) / Data Centre (new) / Multiple] +**Anticipated Competent Authority:** [CA name] + +### Current Compliance Foundation (NIS Regs 2018) +[Summary of CAF status and gaps] + +### CSRB Expansion Impact +[Whether organisation falls into new categories and implications] + +### Incident Reporting Gaps +| Gap | Priority | Action | Owner | Target Date | +|-----|----------|--------|-------|-------------| +| ... | ... | ... | ... | ... | + +### Security Control Gaps (CSRB-specific) +[Any additional controls required beyond current CAF] + +### Recommended Actions +1. [Priority 1 action] +2. [Priority 2 action] + +*This assessment is based on CSRB policy proposals as of [date]. Verify against enacted legislation once available.* +``` + +--- + +## 6. Transition from NIS Regulations + +### 6.1 CSRB Transition Principles + +When the CSRB is enacted: +- Existing OES and DSP designations will carry over automatically — no redesignation process expected +- Existing CAF assessments and compliance programmes provide a foundation but must be reviewed against any new CSRB obligations +- New categories (MSPs, data centres) will have a transition/grace period for designation and compliance (exact timelines subject to secondary legislation) + +### 6.2 Transition Checklist for Current OES/DSPs + +``` +PRE-ENACTMENT (Actions to take now): +[ ] Review current CAF self-assessment — ensure it is current (within 12 months) +[ ] Remediate outstanding CAF gaps (especially A1, A2, D1) +[ ] Update Incident Response Plan to accommodate expanded reporting categories +[ ] Reduce internal incident reporting workflows to 24-hour timeline +[ ] Map third-party/MSP dependencies and review their security posture +[ ] Brief board/senior management on CSRB changes and timeline +[ ] Establish a CSRB monitoring process (track bill progress at bills.parliament.uk) + +POST-ENACTMENT (Actions once CSRB receives Royal Assent): +[ ] Review final legislation against these guidance notes for any changes +[ ] Update NIS Compliance Policy to reference CSRB provisions +[ ] Navigate any new designation/registration process required by CSRB +[ ] Engage with Competent Authority on new reporting format/portal when available +[ ] Update supplier contracts to reflect CSRB supply chain obligations +[ ] Conduct fresh CAF/CSRB gap assessment against final legislative requirements +``` + +### 6.3 Transition Checklist for Newly In-Scope MSPs + +``` +PRE-ENACTMENT: +[ ] Assess whether CSRB MSP definitions likely apply to your services +[ ] Review your own security posture against the NIS CAF framework (as a baseline) +[ ] Review customer contracts for cyber incident notification obligations +[ ] Identify the likely Competent Authority for MSPs in your sector +[ ] Monitor DSIT consultations and secondary legislation announcements + +POST-ENACTMENT: +[ ] Confirm scope status and register with Competent Authority as required +[ ] Build a NIS/CSRB-compliant information security management system +[ ] Implement security measures to at least CAF standard +[ ] Establish CSRB-compliant incident reporting capability +[ ] Update customer contracts to reflect your CSRB obligations +``` + +--- + +## 7. Policy and Document Generation + +When generating CSRB readiness documents, include: +- Organisation name: `[ORGANISATION NAME]` +- Document version: `[VERSION]` +- Bill status note: "Based on CSRB as [published/introduced/enacted] — review following Royal Assent" +- Date: `[DATE]` + +Load `references/templates-csrb.md` for CSRB-specific policy and document templates. + +### Key CSRB Documents to Prepare in Advance + +| Document | Purpose | Priority | +|----------|---------|----------| +| CSRB Readiness Assessment | Baseline gap analysis | High — do now | +| Updated Incident Response Plan | Accommodate CSRB reporting | High — do now | +| CSRB Compliance Roadmap | Action plan for transition | High — do now | +| Updated NIS/CSRB Compliance Policy | When enacted | Medium | +| MSP Customer Security Addendum | For MSPs | Medium | +| Board CSRB Briefing | Leadership awareness | High — do now | + +--- + +## 8. Comparative Analysis + +### 8.1 CSRB vs NIS Regulations 2018 + +| Aspect | NIS Regulations 2018 | CSRB | +|--------|---------------------|------| +| Legislative basis | SI 2018/506 (retained from EU NIS Directive) | Primary UK legislation | +| Sectors | 5 (energy, transport, health, water, digital infrastructure) | 5 existing + MSPs + data centres + potentially more | +| MSPs in scope | No | Yes | +| Data centres in scope | Only if operating DNS/IXP/TLD | Yes (large data centres) | +| Incident reporting | Significant/substantial impact on service continuity | Broader — includes near-misses and precursor events | +| Reporting timeline | As soon as reasonably practicable (72hr guidance) | Likely compressed (24hr initial) | +| CA powers | Reactive enforcement | Proactive oversight + reactive enforcement | +| Financial penalties | Up to 17M GBP | Expected to remain significant; exact figure in legislation | +| Technical standard | NCSC CAF | NCSC CAF (expected to remain primary standard) | + +### 8.2 CSRB vs EU NIS2 Directive + +The EU NIS2 Directive (Directive (EU) 2022/2555) came into force on 16 January 2023 and was required to be transposed by EU member states by 17 October 2024. The UK is not subject to NIS2 (post-Brexit) but NIS2 informed CSRB policy development. + +| Aspect | EU NIS2 | UK CSRB | +|--------|---------|---------| +| Effective | 17 October 2024 (transposition deadline) | Subject to Royal Assent and commencement | +| Entities covered | Essential entities and important entities across broader sector list | OES, DSPs, MSPs, data centres | +| MSPs in scope | Yes (important entities) | Yes | +| Incident reporting timeline | 24 hours (early warning), 72 hours (incident notification) | Likely similar | +| Supply chain security | Explicit requirement | Implicit through CAF; may be made explicit | +| Penalties | Up to 10M EUR or 2% global turnover (essential); 7M EUR or 1.4% (important) | TBD — likely significant | +| Certification | Creates pathway for national cybersecurity certification schemes | NCSC CAF remains primary standard | + +--- + +## Reference Files + +| File | Load When | +|------|-----------| +| `references/scope-expansion.md` | Scope determination, MSP and data centre categorisation | +| `references/incident-reporting-csrb.md` | CSRB incident reporting obligations and templates | +| `references/regulator-powers-csrb.md` | Regulator powers, enforcement, and proactive oversight | +| `references/templates-csrb.md` | CSRB readiness documents, gap assessment templates, IRP updates | + +Load **all** reference files for comprehensive CSRB readiness assessments or programme-level reviews. diff --git a/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/incident-reporting-csrb.md b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/incident-reporting-csrb.md new file mode 100644 index 0000000..56d544d --- /dev/null +++ b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/incident-reporting-csrb.md @@ -0,0 +1,354 @@ +# UK CSRB — Enhanced Incident Reporting Reference +## Cyber Security and Resilience Bill: Incident Reporting Obligations + +> **Important — Bill Status:** The CSRB incident reporting provisions described here are based on +> the Bill's policy intent and published DSIT guidance. Final provisions may differ. Verify +> against enacted legislation and statutory instruments at bills.parliament.uk. + +--- + +## Overview + +The Cyber Security and Resilience Bill introduces a materially expanded incident reporting regime +compared with the NIS Regulations 2018. The key changes are: + +1. **Wider reportable events** — Not just service-impacting incidents, but near-misses, precursor + events, ransomware deployments, and supply chain incidents +2. **Compressed timelines** — Initial notification expected within 24 hours (compared with + 72-hour guidance under NIS Regs 2018) +3. **Standardised reporting** — Structured, machine-readable reporting formats expected +4. **New entities reporting** — MSPs and data centre operators added to reporting obligations +5. **Enhanced government visibility** — Reports will feed into national threat picture maintained + by DSIT and NCSC + +--- + +## Part 1 — Reportable Events Under the CSRB + +### 1.1 Events Requiring Notification + +The CSRB is expected to require notification for a broader set of events than the NIS Regulations. +The following categories are based on the policy intent and analogy with the EU NIS2 Directive +(which the CSRB draws from): + +| Category | Description | NIS Regs 2018 | CSRB | +|----------|-------------|---------------|------| +| Service-impacting incident | Incident causing significant disruption to essential/digital service | Required | Required | +| Near-miss | Event that could have caused significant impact but was contained | Not required | Expected | +| Ransomware deployment | Detection of ransomware in systems, even if contained before service impact | Not required | Expected (likely separate track) | +| Data exfiltration | Confirmed or suspected theft of data from in-scope systems | Not required separately | Expected | +| Supply chain incident | Compromise of a supplier or MSP with access to in-scope systems | Not required separately | Expected | +| Precursor/reconnaissance | Detected TTPs suggesting imminent attack | Not required | Possible (proactive sharing) | + +### 1.2 Impact Assessment Factors + +The CSRB retains the existing impact assessment factors from the NIS Regulations and expands them. +Where an event meets the lower CSRB threshold, organisations should consider: + +**Retained NIS Regs factors:** +- Number of users affected +- Duration of disruption +- Geographic spread +- Extent of service impairment +- Economic and societal impact + +**Additional CSRB factors (expected):** +- Whether the event involved ransomware (separate reporting track) +- Whether a supply chain component was involved +- Whether data was exfiltrated or at risk of exfiltration +- Whether the event originated from a state-affiliated threat actor +- Whether the event is a near-miss (what controls prevented service impact?) + +--- + +## Part 2 — Reporting Timelines + +### 2.1 Expected CSRB Timeline + +Based on published policy intent and the EU NIS2 model: + +| Stage | Timeline | Content | +|-------|----------|---------| +| Early notification / initial alert | Within 24 hours of awareness | Minimal details: event type, approximate time, initial assessment of scope | +| Full incident notification | Within 72 hours of awareness | Full details: systems affected, impact, response actions, initial root cause | +| Final report | Within 30 days of resolution | Root cause, full timeline, controls failure analysis, remediation taken | + +> Note: Exact timelines will be set by secondary legislation. The 24/72-hour structure parallels EU NIS2 and is the most likely model for the CSRB. Organisations should plan for 24-hour initial notification as the worst-case timeline. + +### 2.2 Comparison: NIS Regs 2018 vs CSRB vs EU NIS2 + +| Framework | Initial Notification | Full Report | Near-miss | +|-----------|---------------------|-------------|-----------| +| NIS Regs 2018 | As soon as practicable (72hr guidance) | No prescribed deadline | Not required | +| EU NIS2 | 24 hours (early warning) | 72 hours (notification) | Not required | +| UK CSRB (expected) | 24 hours | 72 hours | Expected for some categories | + +--- + +## Part 3 — Notification Templates + +### 3.1 CSRB Early Notification Template (24-Hour) + +``` +CSRB EARLY NOTIFICATION (24-HOUR ALERT) + +Submission Date/Time (UTC): [YYYY-MM-DD HH:MM] +Organisation Name: +Organisation Type: [ ] OES [ ] DSP [ ] MSP [ ] Data Centre +Competent Authority: +Reporting Contact (Name, Role, Email, Phone): + +EVENT TYPE (select all that apply): + [ ] Significant service disruption + [ ] Near-miss (contained — no service impact) + [ ] Ransomware deployment + [ ] Data exfiltration (confirmed/suspected) + [ ] Supply chain / third-party compromise + [ ] Unauthorised access (no confirmed disruption) + [ ] DDoS / availability attack + [ ] Other (brief description): + +BRIEF DESCRIPTION: +Date/Time event first detected (UTC): [YYYY-MM-DD HH:MM] +Systems/services affected: +Current status: [ ] Ongoing [ ] Contained [ ] Resolved + +IMMEDIATE ACTIONS: +(Brief description of actions taken) + +Is the NCSC being separately notified? [ ] Yes [ ] No + +NEXT UPDATE: [YYYY-MM-DD HH:MM] (within 72 hours of first awareness) +``` + +### 3.2 CSRB Full Incident Notification (72-Hour) + +``` +CSRB FULL INCIDENT NOTIFICATION + +Submission Date/Time (UTC): [YYYY-MM-DD HH:MM] +Notification Type: [ ] Initial (72hr) [ ] Updated [ ] Final + +-- ORGANISATION -- +Organisation Name: +Organisation Type: [ ] OES [ ] DSP [ ] MSP [ ] Data Centre +Competent Authority: +CSRB Lead Contact (Name, Role, Email, Phone): + +-- INCIDENT DETAILS -- +Date/Time First Detected (UTC): [YYYY-MM-DD HH:MM] +Date/Time Incident Started (if known, UTC): [YYYY-MM-DD HH:MM] +Date/Time Contained/Resolved (if applicable, UTC): [YYYY-MM-DD HH:MM] + +Incident Type (select all that apply): + [ ] Ransomware + [ ] Data exfiltration + [ ] Unauthorised access + [ ] Denial of Service + [ ] Supply chain compromise + [ ] Physical attack on systems + [ ] Insider threat + [ ] Other: + +Systems/Services Affected: +Attack Vector (if known): +Threat Actor Attribution (if known/suspected): + +-- IMPACT ASSESSMENT -- +Current Status: [ ] Ongoing [ ] Contained [ ] Resolved + +Service Impact: + [ ] No service disruption [ ] Partial disruption [ ] Full disruption +Duration of disruption (actual/estimated): +Estimated users/organisations affected: +Geographic scope: +Data exfiltrated or at risk: [ ] No [ ] Yes — describe: +Supply chain element involved: [ ] No [ ] Yes — describe: +Ransomware component: [ ] No [ ] Yes + +Near-miss (service not ultimately disrupted): [ ] No [ ] Yes + If yes — what controls/actions prevented service impact: + +-- RESPONSE -- +Containment measures applied: +External assistance engaged: + NCSC notified: [ ] Yes [ ] No + Law enforcement notified: [ ] Yes [ ] No — which force: + NCSC IR team engaged: [ ] Yes [ ] No + +-- CROSS-REGULATORY -- +UK GDPR personal data breach requires ICO notification: [ ] No [ ] Yes — submitted: +FCA notification required: [ ] No [ ] Yes +DSPT / NHS notification required: [ ] No [ ] Yes + +-- NEXT STEPS -- +Planned remediation: +Expected full resolution date: +Next update expected: [YYYY-MM-DD] + +Signed: _______________________ Date: ___________ +[Name, Role] +``` + +### 3.3 CSRB Final Report (30-Day Post-Resolution) + +``` +CSRB FINAL INCIDENT REPORT + +Submission Date: [YYYY-MM-DD] +Organisation: +Competent Authority: +Incident Reference (if CA assigned): [CA-REF-XXXX] +Original Early Notification Date: [YYYY-MM-DD] + +-- ROOT CAUSE ANALYSIS -- +Root cause identified: + [ ] Unpatched vulnerability (CVE: [____], CVSS: [___]) + [ ] Phishing / social engineering + [ ] Credential compromise + [ ] Misconfiguration + [ ] Supply chain / third-party access + [ ] Insider threat + [ ] Unknown / under investigation + [ ] Other: + +Detailed root cause description: + +Attack timeline (key events): + [YYYY-MM-DD HH:MM] — + [YYYY-MM-DD HH:MM] — + [YYYY-MM-DD HH:MM] — + +-- FINAL IMPACT -- +Total duration of any service disruption: +Total users/organisations ultimately affected: +Data confirmed exfiltrated: [ ] No [ ] Yes — volume/nature: +Financial impact (if quantifiable): + +-- REMEDIATION COMPLETED -- +Immediate remediation actions taken: +Longer-term improvements implemented or planned: + +-- LESSONS LEARNED -- +Control gaps identified: +Improvements to security posture: +Changes to incident response procedures: + +-- RECORD KEEPING -- +Investigation report retained: [ ] Yes +Evidence preserved: [ ] Yes +CA correspondence filed: [ ] Yes + +Signed: _______________________ Date: ___________ +[Name, Role — CISO / Compliance Lead] +``` + +--- + +## Part 4 — MSP-Specific Incident Reporting + +### 4.1 Cascading Incident Scenarios + +MSPs face a unique incident reporting challenge: a single compromise of MSP infrastructure may +simultaneously affect multiple client organisations. The CSRB is expected to address this +through: + +- **Single notification from MSP** covering all affected clients +- **Client notification obligation** — MSPs must notify affected clients within a defined timeline +- **Joint reporting** — where a client is also OES/DSP, both the MSP and client may need to report + +### 4.2 MSP Cascade Notification Process + +``` +MSP CASCADE INCIDENT NOTIFICATION FLOW + +1. MSP detects/is made aware of incident + | +2. MSP assesses: Are client environments affected or at risk? + YES --> Proceed + NO --> Internal MSP notification only (but still monitor) + | +3. MSP notifies: + a) Relevant Competent Authority (for MSP) — within 24 hours + b) Affected client organisations — within 24 hours + c) NCSC — as soon as practicable + | +4. Clients assess impact on their own essential/digital services + | +5. OES/DSP clients notify their own Competent Authorities if + CSRB significant impact threshold is met + | +6. MSP coordinates with clients for joint root cause analysis + and provides technical assistance + | +7. MSP submits final report (30 days) to CA +``` + +### 4.3 MSP Client Notification Template + +``` +URGENT: CYBER SECURITY INCIDENT NOTIFICATION TO CLIENT + +Date/Time: [YYYY-MM-DD HH:MM UTC] +From: [MSP Name] — [Security Contact Name, Role, Email, Phone] +To: [Client Organisation Name] — [Client Security/IT Contact] + +NATURE OF NOTIFICATION: [CSRB Mandatory Client Notification] + +Dear [Client Contact], + +We are writing to notify you of a cyber security incident affecting [MSP NAME] +infrastructure that [has affected / may have affected] your organisation's +systems or data. + +INCIDENT SUMMARY: +Date/Time detected: [YYYY-MM-DD HH:MM UTC] +Systems/services affected: [Brief description of affected MSP systems] +Assessment of client impact: [What client data/access may be at risk] +Current status: [ ] Ongoing [ ] Contained [ ] Resolved + +IMMEDIATE RECOMMENDED ACTIONS FOR YOUR ORGANISATION: +1. [e.g., Rotate credentials for [specific system/service]] +2. [e.g., Review access logs for [date range]] +3. [e.g., Treat emails from [domain] with caution] + +Our incident response team is available at: [contact details] +We will provide a further update by: [YYYY-MM-DD HH:MM] + +This notification is issued under our obligations under the UK Cyber Security +and Resilience Bill. You may have your own reporting obligations to your +Competent Authority if this incident has significant impact on your essential +or digital service. + +[Name, Role, Signature] +[MSP Name] +``` + +--- + +## Part 5 — Voluntary Reporting and Information Sharing + +### 5.1 NCSC Early Warning Service + +The NCSC operates an Early Warning service that allows organisations to voluntarily report +incidents and receive threat intelligence. This is separate from the mandatory CSRB reporting +channel but is strongly encouraged. Organisations should notify NCSC in addition to their +Competent Authority. + +NCSC reporting: report.ncsc.gov.uk + +### 5.2 Sector Information Sharing + +Several sectors operate Information Sharing and Analysis Centres (ISACs) or equivalent bodies +that enable voluntary sharing of threat intelligence and incident information within the sector: + +| Sector | Body | +|--------|------| +| Financial services | CISP (NCSC) / FS-ISAC | +| Healthcare | CareCERT (NCSC / NHS Digital) | +| Energy | EUCS (Energy UK) | +| Local government | LGA Cyber / NCSC | +| Telecoms | CiSP / Ofcom | + +Participation in sector ISACs supports CSRB compliance goals and is encouraged even before +mandatory reporting obligations take effect. diff --git a/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/regulator-powers-csrb.md b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/regulator-powers-csrb.md new file mode 100644 index 0000000..5078e20 --- /dev/null +++ b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/regulator-powers-csrb.md @@ -0,0 +1,310 @@ +# UK CSRB — Regulator Powers Reference +## Cyber Security and Resilience Bill: Enhanced Regulator and Competent Authority Powers + +> **Important — Bill Status:** The CSRB regulatory powers described here are based on +> published DSIT policy intent and the Bill as introduced. Final provisions, delegated powers, +> and CA designations may differ following Royal Assent. Verify against enacted legislation. + +--- + +## Overview + +One of the most significant changes introduced by the Cyber Security and Resilience Bill is +the shift from primarily **reactive** regulatory oversight (as under NIS Regs 2018) to +**proactive** regulatory oversight. Competent Authorities gain new powers to audit, direct, +and obtain information from in-scope organisations before an incident occurs. + +The key changes are: +1. **Proactive audit powers** — CAs can direct organisations to undergo security assessments +2. **Information-gathering powers** — CAs can require organisations to produce security information +3. **Expanded enforcement** — Enhanced financial penalties and recovery mechanisms +4. **Cross-CA coordination** — Improved information sharing between CAs and with DSIT/NCSC +5. **New regulators for new entities** — MSPs and data centres will have designated CAs + +--- + +## Part 1 — NIS Regs 2018 vs CSRB Regulatory Architecture + +### 1.1 Competent Authority Powers Comparison + +| Power | NIS Regs 2018 | CSRB (Expected) | +|-------|---------------|-----------------| +| **Information gathering** | Reg 15: CA may require information from OES/DSP | Expanded: CA can require detailed security documentation, audit records, supply chain information | +| **Directed assessment** | Not available — CA must rely on organisation self-assessment | Expected: CA can commission and direct a third-party security assessment | +| **Scheduled audit** | Not available — inspections only following incident or concern | Expected: CA can schedule proactive audits of high-risk or critical organisations | +| **Enforcement notice** | Reg 17: CA can issue enforcement notice specifying required steps | Retained and expanded: more detailed step-down enforcement process | +| **Penalty — OES** | Reg 18: Up to £17 million | Expected: Revised (likely increased or restructured) | +| **Penalty — DSP** | Reg 21: Up to £17 million | Expected: Retained or restructured | +| **Penalty — MSP** | Not applicable (MSPs not in scope) | New: CSRB introduces penalty powers for MSPs | +| **Penalty — Data centres** | Not applicable | New: CSRB introduces penalty powers for qualifying data centres | +| **Cross-CA sharing** | Limited | Expected: Formal mechanism for CA-to-CA and CA-to-DSIT sharing | +| **International coordination** | Limited | Expected: Formal mechanism with international partners | + +### 1.2 Regulatory Architecture Under CSRB (Expected) + +``` +DSIT (Department for Science, Innovation and Technology) + | + |-- Policy oversight + |-- Receives national incident picture + |-- Cross-CA coordination + |-- Designates CAs for new entity types + | + +-- NCSC (National Cyber Security Centre) + | | + | |-- Technical authority / guidance + | |-- CAF and risk management guidance + | |-- Intelligence input to CA oversight + | + +-- Sectoral Competent Authorities + | + +-- OES / DSP (existing, per NIS Regs 2018 schedule) + | |-- Energy: BEIS/Ofgem + | |-- Transport: DfT / sector regulators + | |-- Health: DHSC / NHSE + | |-- Water: Drinking Water Inspectorate / SEPA / NRW + | |-- Digital (DSP): ICO + | + +-- MSPs: DSIT (expected primary CA) + | + +-- Data Centres: DSIT (expected designating authority) +``` + +--- + +## Part 2 — New Proactive Powers + +### 2.1 Directed Security Assessments + +Under the CSRB, CAs are expected to have power to direct an in-scope organisation to undergo +a security assessment carried out by a qualified third party or by the CA itself. This represents +a fundamental shift from self-assessment to externally directed assurance. + +**Key aspects:** +- CA selects or approves the assessor +- Organisation bears the cost of the assessment +- Organisation must cooperate with the assessor and provide access to systems and documentation +- Assessment findings are reported to the CA + +**Preparation steps for organisations:** +1. Maintain an up-to-date asset register (systems and data flows) +2. Keep security policies and procedures current and review-ready +3. Maintain audit trails for patching, access reviews, and security decisions +4. Conduct periodic internal assessments against CAF (NCSC guidance) in preparation + +### 2.2 Information-Gathering Powers + +CAs will be able to require organisations to provide: +- Security policies and procedures +- Network architecture diagrams +- Patch management records +- Access and privilege management records +- Supply chain security assessments +- Previous incident records and remediation evidence +- Board-level cyber risk reporting documentation + +**Implication:** Organisations should maintain audit-ready documentation at all times, not only +in response to incidents or formal investigations. + +### 2.3 Proactive Audit Schedule (Expected) + +The CSRB is expected to allow CAs to schedule audits of organisations classified as highest-risk +or most critical. The criteria for selection are not yet prescribed but are likely to include: + +- Scale of essential service provided +- Previous incident history +- Known vulnerability exposure +- Sector-wide risk indicators (threat intelligence) +- Known deficiencies in previous self-assessments + +--- + +## Part 3 — Enforcement Powers and Penalties + +### 3.1 Enforcement Process + +Under the NIS Regs 2018 the enforcement process proceeds: +**Information notice → Enforcement notice → Penalty notice** + +The CSRB is expected to retain this stepped approach but with enhanced provisions: + +| Stage | NIS Regs (current) | CSRB (expected) | +|-------|--------------------|-----------------| +| Information notice | CA requires specific information | Expanded: broader categories of information; MSP/data centre entities added | +| Enforcement notice | CA requires specific steps; time-limited | Retained; step-down process more prescriptive | +| Penalty notice | Max £17M (OES/DSP) | Revised structure; MSP and data centre entities added | +| Appeals | Upper Tribunal | Retained | +| Criminal offences | Obstruction etc. | Retained | + +### 3.2 Financial Penalties — Current (NIS Regs 2018) + +| Entity | Maximum Penalty | +|--------|----------------| +| OES | £17,000,000 | +| DSP | £17,000,000 | + +> Source: Regulation 18 and Regulation 21, NIS Regulations 2018 + +### 3.3 Financial Penalties — CSRB (Expected) + +The exact penalty figures are subject to the enacted legislation. Three possible models based on +comparable UK legislation: + +| Model | OES/DSP | MSP | Data Centre | +|-------|---------|-----|-------------| +| Retained NIS | £17M | £17M | £17M | +| GDPR-aligned (% of global turnover) | Higher of £17M or 4% global turnover | Higher of £8.7M or 2% global turnover | TBD | +| Sector-differentiated | TBD per sector | TBD | TBD | + +> Note: The GDPR-aligned model is used in the EU NIS2 Directive (higher of €10M or 2% for +> essential entities; €7M or 1.4% for important entities). The UK CSRB may adopt a comparable +> structure. Verify against enacted legislation. + +--- + +## Part 4 — Cross-CA Information Sharing + +### 4.1 Current Limitations (NIS Regs 2018) + +Under the NIS Regulations 2018, information sharing between Competent Authorities is limited: +- Each CA operates primarily within its own sector +- No statutory obligation to share incident information across sectors +- NCSC receives information informally but this is not a statutory duty + +### 4.2 CSRB Cross-CA Sharing Framework (Expected) + +The CSRB is expected to establish: +- **Statutory gateway** for CAs to share incident information between each other +- **DSIT coordination function** — receiving sector incident information to maintain national + security posture assessment +- **NCSC integration** — formal channel for CAs to receive NCSC threat intelligence and for + NCSC to receive CA incident data +- **International sharing** — formal gateway for sharing with equivalent EU NIS2 competent + authorities and trusted international partners + +### 4.3 Implications for Organisations + +Cross-CA sharing means: +1. An incident reported to one CA may be shared with other CAs relevant to your sector +2. Multi-sector organisations (or MSPs serving multiple sectors) should assume reports will + reach all relevant regulatory bodies +3. Confidentiality claims over reported information are likely limited — plan reporting + accordingly + +--- + +## Part 5 — Powers Specific to MSPs and Data Centres + +### 5.1 Managed Service Provider Oversight + +DSIT is expected to be the Competent Authority for MSPs. Powers specific to MSPs are expected to +include: + +**Information requirements:** +- List of in-scope clients (organisations that are OES/DSP) +- Architecture of shared infrastructure serving multiple clients +- Client security access controls and privilege management records +- Incident history across client estate + +**Assessment triggers:** +- Incident affecting multiple clients +- Threat intelligence indicating MSP targeting +- Scheduled proactive audit + +**Notification obligations:** +- MSP must notify CA within 24 hours of detecting incident affecting client(s) +- MSP must notify affected clients within 24 hours +- CA may coordinate with sectoral CAs of affected clients + +### 5.2 Data Centre Oversight + +Large data centres above the qualifying threshold are expected to have DSIT as their CA. Powers +are expected to include: + +**Physical and environmental security:** +- Audit of physical security controls +- Access control systems inspection +- Power and cooling resilience verification + +**Logical (cyber) security:** +- Assessment of management plane security +- Customer-facing access controls +- Interconnect and peering security + +--- + +## Part 6 — Compliance Programme Implications + +### 6.1 From Audit-Responsive to Continuous Compliance + +Under NIS Regs 2018, many organisations treated compliance as event-driven: +- Respond to CA information requests +- Conduct self-assessments when asked +- Produce documentation when inspected + +Under the CSRB, the proactive audit model requires continuous compliance readiness: + +| Activity | Recommended Frequency | +|----------|-----------------------| +| Asset register review | Quarterly | +| Security policy review | Annual (minimum) | +| CAF self-assessment | Annual | +| Third-party penetration test | Annual (minimum) | +| Supply chain security review | Annual | +| Board cyber risk report | Quarterly | +| Access and privilege review | Quarterly | +| Patch management evidence review | Monthly | + +### 6.2 Board-Level Accountability + +The CSRB is expected to reinforce board accountability for cyber security. CAs are likely to +require evidence of: +- Board-level oversight of cyber risk +- Named senior responsible owner (SRO) for CSRB compliance +- Board minutes recording cyber risk discussions +- Board-approved cyber security strategy and investment + +### 6.3 Documentation Checklist for CA Assessment Readiness + +``` +CA ASSESSMENT READINESS CHECKLIST + +POLICIES AND PROCEDURES +[ ] Cyber Security Policy (board-approved, dated) +[ ] Incident Response Plan (tested, dated) +[ ] Business Continuity Plan (tested, dated) +[ ] Supplier / Supply Chain Security Policy +[ ] Access Control Policy +[ ] Patch Management Policy and records + +TECHNICAL EVIDENCE +[ ] Asset register (systems, data flows) +[ ] Network architecture diagram (current) +[ ] Patching status records (last 12 months) +[ ] Vulnerability management records +[ ] Penetration test report (dated within 12 months) +[ ] Access review records (privileged accounts) +[ ] Multi-factor authentication coverage evidence + +CAF ASSESSMENT +[ ] CAF self-assessment (current, NCSC CAF v3.2 or later) +[ ] Objective A (Managing security risk) — documented +[ ] Objective B (Protecting against cyber attack) — documented +[ ] Objective C (Detecting cyber security events) — documented +[ ] Objective D (Minimising the impact of incidents) — documented + +INCIDENT RECORDS +[ ] Previous incident log (past 3 years) +[ ] Evidence of CA notifications where applicable +[ ] Post-incident review records + +SUPPLY CHAIN +[ ] Supplier register with security risk assessment +[ ] Key supplier questionnaire responses +[ ] Contractual security obligations — evidence of enforcement + +GOVERNANCE +[ ] Board cyber risk report (most recent) +[ ] CSRB SRO appointment documented +[ ] Staff cyber security training records +``` diff --git a/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/scope-expansion.md b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/scope-expansion.md new file mode 100644 index 0000000..e521d6c --- /dev/null +++ b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/scope-expansion.md @@ -0,0 +1,199 @@ +# UK CSRB — Scope Expansion Reference +## Cyber Security and Resilience Bill: New Categories and Scope Determination + +> **Important — Bill Status:** The CSRB is proposed legislation as of the date of this file. All scope +> provisions are based on published policy intent, DSIT consultations, and the introduced Bill. +> Final scope definitions will be established in the enacted legislation and associated secondary +> legislation (statutory instruments). Verify at bills.parliament.uk and gov.uk/dsit. + +--- + +## 1. Retained Scope: OES and DSP Categories + +The CSRB retains all existing NIS Regulations 2018 scope categories without change. Entities +currently designated as OES or registered as DSPs remain subject to equivalent obligations. + +### 1.1 Operators of Essential Services (OES) — Retained + +| Sector | Sub-sector | Competent Authority | +|--------|-----------|---------------------| +| Energy | Electricity (generation, transmission, distribution, supply) | Ofgem | +| Energy | Oil (transport, distribution, storage) | DESNZ | +| Energy | Gas (transmission, distribution, storage, supply) | Ofgem | +| Transport | Air transport | Civil Aviation Authority (CAA) | +| Transport | Rail transport | Office of Rail and Road (ORR) | +| Transport | Road transport | Department for Transport (DfT) | +| Transport | Water transport / maritime | DfT / Maritime and Coastguard Agency (MCA) | +| Health | Healthcare providers (NHS, independent) | DHSC / NHS England | +| Drinking Water | Supply and distribution | Drinking Water Inspectorate (DWI) | +| Digital Infrastructure | Internet Exchange Points (IXPs) | Ofcom | +| Digital Infrastructure | DNS service providers | Ofcom | +| Digital Infrastructure | TLD registries | Ofcom | + +### 1.2 Digital Service Providers (DSP) — Retained + +| DSP Type | Competent Authority | +|----------|---------------------| +| Online marketplace | ICO | +| Online search engine | ICO | +| Cloud computing (IaaS, PaaS, SaaS — excluding micro/small enterprises) | ICO | + +--- + +## 2. New Category 1: Managed Service Providers (MSPs) + +### 2.1 Policy Rationale + +The UK government's decision to bring MSPs into scope is based on empirical evidence of systemic risk: + +- **MOVEit vulnerability exploitation (2023):** A zero-day in Progress Software's MOVEit Transfer product was exploited by the Cl0p ransomware group, resulting in data exfiltration from hundreds of organisations globally via their managed service and cloud transfer providers. UK organisations affected included the BBC, British Airways, Boots, and the NHS. +- **Capita breach (2023):** A cyber incident at IT outsourcing company Capita affected numerous public sector clients including NHS Trusts and local authorities. +- **SolarWinds (2020):** Supply chain compromise of SolarWinds Orion MSP platform affected thousands of organisations worldwide including government agencies. + +These incidents demonstrate that MSPs represent a concentrated attack surface — compromise of a single MSP can give attackers access to dozens or hundreds of client organisations simultaneously. + +### 2.2 Definition of Managed Service Provider (Indicative) + +For CSRB purposes, an MSP is expected to be defined as an entity that: +- Provides ongoing, contracted IT or security management services to one or more customer organisations +- Typically has privileged remote access to customer networks, systems, or data +- The services are delivered remotely (or remotely supervised) +- The MSP's systems or access could, if compromised, enable access to customer systems + +**Services expected to be in scope:** +| Service Category | In-scope Indication | +|-----------------|---------------------| +| Managed SOC / MDR (Managed Detection and Response) | Yes | +| Managed Network Services (WAN, firewall, SD-WAN) | Yes | +| Managed Backup and DR | Yes | +| Managed Cloud Services (hosting, infrastructure management) | Yes | +| Managed Identity and Access Management | Yes | +| Managed Endpoint Detection and Response (EDR/XDR) | Yes | +| IT outsourcing with ongoing remote management | Yes | +| MSSP (Managed Security Service Provider) | Yes | + +**Services less likely to be in scope (based on policy intent):** +| Service | In-scope Indication | +|---------|---------------------| +| One-off IT consultancy (no ongoing access) | Unlikely | +| Software licensing / resale (no managed access) | Unlikely | +| Break-fix IT support (ad-hoc, no permanent access) | Unlikely | +| SaaS application providers with no customer system management | Unlikely | +| IT hardware supply without managed services | Unlikely | + +### 2.3 MSP Scope Thresholds + +Precise thresholds for MSP designation are to be set in secondary legislation. Relevant factors likely to be considered include: +- Number of critical sector (OES or public sector) customers managed +- Value of managed services revenue from critical sector customers +- Volume/value of data processed for critical sector customers +- Whether the MSP provides services that are critical to essential service delivery + +### 2.4 MSP Obligations + +MSPs that fall in scope of the CSRB are expected to have obligations equivalent to (or adapted from) OES or DSP requirements, including: +- Implementing appropriate and proportionate security measures (aligned to NCSC CAF or equivalent) +- Notifying the relevant Competent Authority of significant incidents +- Supporting Competent Authority audits and information requests +- Maintaining documented security policies and risk assessments + +### 2.5 MSP Self-Assessment Framework + +Until formal designation and CA guidance is issued, MSPs should self-assess using a CAF-equivalent framework covering: + +| Area | Key Questions | +|------|--------------| +| Governance | Is there board-level accountability for cyber security? | +| Risk Management | Are risks to managed client environments systematically assessed? | +| Asset Management | Are all assets with client connectivity inventoried? | +| Supply Chain | Are sub-processors and tool vendors assessed? | +| Identity and Access Control | Is privileged client access tightly controlled and MFA-enforced? | +| Data Security | Is client data segregated, encrypted, and access-controlled? | +| System Security | Are MSP systems and tooling patched and hardened? | +| Monitoring | Are MSP and client environments monitored for compromise? | +| Incident Response | Is there an IRP covering cascading incidents across clients? | + +--- + +## 3. New Category 2: Large Data Centres + +### 3.1 Policy Rationale + +Large data centres represent concentrated critical infrastructure. A significant proportion of UK critical services — including financial, healthcare, government, and communications services — rely on third-party data centre hosting. An attack on a major data centre could simultaneously affect hundreds of tenants. + +The UK government assessed in its 2023 Critical National Infrastructure (CNI) designation review that large data centres warrant CNI-equivalent treatment. This is reflected in the CSRB. + +### 3.2 Indicative Scope for Data Centres + +The CSRB is expected to cover: +- Operator-neutral (colocation) data centres above a defined scale threshold +- Data centres hosting critical national infrastructure systems or government systems +- Hyperscale data centre facilities operated by cloud providers (where not already covered as DSPs) + +**Likely threshold indicators:** +- Data centre capacity above a defined megawatt (MW) or square metre floor area threshold +- Number of customers above a defined level (especially critical sector customers) +- Whether the facility hosts government Tier 1 or Crown systems + +### 3.3 Data Centre Security Obligations + +Data centre operators in scope are expected to implement: +- Physical security measures (perimeter security, access control, CCTV, environmental controls — fire, flood, power) +- Cybersecurity measures for management systems (DCIM, remote monitoring, building management systems) +- Incident reporting obligations for significant disruptions +- Business continuity and disaster recovery capability + +The NCSC has published separate guidance on data centre cyber security risk. CAF objectives B5 (Resilient Networks and Systems) and D1 (Response and Recovery) are particularly relevant for data centre operators. + +--- + +## 4. Potential Further Scope Expansion + +The CSRB policy documentation notes the possibility of future scope expansion through secondary legislation to include: + +- **Public sector bodies** not currently designated as OES (e.g. local authorities, central government departments) +- **Downstream managed service dependencies** — sub-handlers or sub-processors used by in-scope MSPs +- **Further critical service providers** identified through ongoing CNI review + +The Bill is designed to be forward-facing, with secondary legislation providing the mechanism to add categories without requiring new primary legislation. + +--- + +## 5. Scope Determination Flowchart + +To determine whether your organisation is in scope of the CSRB: + +``` +START + | + v +Are you currently designated as OES under NIS Regs 2018? + YES --> You remain in scope (OES obligations continue + CSRB enhancements) + NO --> Continue + | + v +Are you currently a registered DSP under NIS Regs 2018? + YES --> You remain in scope (DSP obligations continue + CSRB enhancements) + NO --> Continue + | + v +Do you provide ongoing managed IT or security services to critical sector orgs? +(remote access, managed SOC, managed network, managed backup, etc.) + YES --> Likely in scope as MSP (new CSRB category) + NO --> Continue + | + v +Do you operate a significant-scale data centre? +(colocation, hosting critical infrastructure, large capacity) + YES --> Likely in scope as Data Centre operator (new CSRB category) + NO --> Continue + | + v +Are you a public sector body with significant IT systems exposure? + POTENTIALLY --> Monitor secondary legislation closely + + OTHERWISE --> Currently not in CSRB scope + Continue monitoring DSIT publications for scope changes + Consider voluntary compliance with CAF as good practice +END +``` diff --git a/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/templates-csrb.md b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/templates-csrb.md new file mode 100644 index 0000000..8fcc808 --- /dev/null +++ b/plugins/uk-nis-csrb/skills/uk-nis-csrb/references/templates-csrb.md @@ -0,0 +1,511 @@ +# UK CSRB — Compliance Templates +## Cyber Security and Resilience Bill: Readiness and Transition Templates + +> **Important — Bill Status:** These templates are designed for CSRB readiness planning +> ahead of enactment. They draw on the NIS Regulations 2018 structure and published CSRB +> policy intent. Review and update these templates against enacted legislation and any +> statutory guidance issued following Royal Assent. + +--- + +## Template 1 — CSRB Readiness Assessment (Gap Analysis) + +``` +CYBER SECURITY AND RESILIENCE BILL +READINESS ASSESSMENT — GAP ANALYSIS + +Organisation: +Assessment Date: +Completed By: +Review Date: +Current Status: [ ] OES [ ] DSP [ ] MSP (new CSRB entity) [ ] Data Centre (new CSRB entity) + [ ] None (assessing whether CSRB applies) + +ASSESSMENT SCORING +Score each item: + 4 — Fully implemented, documented, and evidenced + 3 — Largely in place; minor gaps or documentation needed + 2 — Partially implemented; significant work required + 1 — At early stage; major gaps + 0 — Not started / not in place + +--------------------------------------------------------------------------- +SECTION A — SCOPE AND APPLICABILITY + +A1. Organisation has determined whether CSRB applies [ /4] +A2. Entity type under CSRB has been identified (OES/DSP/MSP/DC) [ /4] +A3. Competent Authority for the organisation has been identified [ /4] +A4. Any supply chain CSRB implications have been reviewed (as supplier + to OES/DSP or as MSP) [ /4] + +Section A Total: [ /16] + +--------------------------------------------------------------------------- +SECTION B — SECURITY REQUIREMENTS (NCSC CAF) + +B1. CAF self-assessment has been completed (current version) [ /4] +B2. Objective A (Managing security risk) — at least Achieved [ /4] +B3. Objective B (Protecting against cyber attack) — at least Achieved [ /4] +B4. Objective C (Detecting cyber security events) — at least Achieved [ /4] +B5. Objective D (Minimising the impact of incidents) — at least Achieved [ /4] +B6. Security policies are board-approved and reviewed within 12 months [ /4] +B7. Asset register is current and covers all in-scope systems [ /4] +B8. Third-party penetration testing conducted within 12 months [ /4] +B9. Patch management records demonstrate timely patching [ /4] +B10. Supply chain security assessment completed for key suppliers [ /4] + +Section B Total: [ /40] + +--------------------------------------------------------------------------- +SECTION C — INCIDENT REPORTING READINESS + +C1. Incident Response Plan covers CSRB reporting obligations [ /4] +C2. 24-hour initial notification capability is in place (contacts, + procedure, after-hours escalation) [ /4] +C3. Reporting templates are available for 24-hour and 72-hour reports [ /4] +C4. Competent Authority reporting route confirmed (portal / email / phone) [ /4] +C5. Cross-regulatory notification routes confirmed (ICO, FCA, NHS) [ /4] +C6. Staff awareness of CSRB reporting obligations [ /4] +C7. MSP-specific: client notification procedure in place (if applicable) [ /4] +C8. NCSC Early Warning service registration in place [ /4] + +Section C Total: [ /32] + +--------------------------------------------------------------------------- +SECTION D — REGULATOR POWERS READINESS + +D1. Documentation is maintained in audit-ready state [ /4] +D2. Board cyber risk reporting is in place and produces minutes evidence [ /4] +D3. CSRB Senior Responsible Owner (SRO) designated [ /4] +D4. Organisation can respond to CA information notice within timescales [ /4] +D5. Third-party assessment readiness (cooperation process defined) [ /4] + +Section D Total: [ /20] + +--------------------------------------------------------------------------- +SECTION E — TRANSITION OBLIGATIONS (if transitioning from NIS Regs) + +E1. Existing NIS Regs compliance programme reviewed against CSRB gaps [ /4] +E2. CSRB-specific obligations identified beyond current NIS posture [ /4] +E3. Transition plan / roadmap drafted and assigned [ /4] + +Section E Total: [ /12] + +--------------------------------------------------------------------------- +TOTAL SCORE: [ /120] + +SCORING GUIDE +96-120 (80-100%): Strong readiness — minor actions required +72-95 (60-79%): Moderate readiness — targeted programme needed +48-71 (40-59%): Significant gaps — structured programme required immediately +0-47 (0-39%): Poor readiness — urgent programme required + +--------------------------------------------------------------------------- +KEY GAPS IDENTIFIED: +(List specific items scored 0-2 and describe planned action) + +Gap 1: +Action: +Owner: +Target date: + +Gap 2: +Action: +Owner: +Target date: + +[Repeat as needed] + +--------------------------------------------------------------------------- +Completed by: _________________________ Role: ______________ +Approved by (Board/SRO): ______________ Date: ______________ +``` + +--- + +## Template 2 — CSRB Compliance Roadmap + +``` +CYBER SECURITY AND RESILIENCE BILL +COMPLIANCE ROADMAP + +Organisation: +CSRB Entity Type: [ ] OES [ ] DSP [ ] MSP [ ] Data Centre +Competent Authority: +Roadmap Owner (SRO): +Date Prepared: + +PHASE 1 — PRE-ENACTMENT (Recommended: start now) +Target: Establish CSRB readiness foundations ahead of Royal Assent + +| Action | Owner | Target Date | Status | +|--------|-------|-------------|--------| +| Confirm CSRB applicability and entity type | Legal / Compliance | | | +| Identify Competent Authority | Compliance | | | +| Designate CSRB Senior Responsible Owner | Board | | | +| Complete CSRB Readiness Gap Assessment (Template 1) | CISO | | | +| Complete NCSC CAF self-assessment | CISO | | | +| Review and update Incident Response Plan for CSRB | CISO | | | +| Establish 24-hour reporting capability and contacts | IT Security | | | +| Register with NCSC Early Warning service | IT Security | | | +| Conduct supply chain security review | CISO / Procurement | | | +| Draft CSRB policy additions (if MSP — see Template 4) | Compliance | | | +| Brief board on CSRB obligations | CEO / CISO | | | + +PHASE 2 — ENACTMENT AND COMMENCEMENT PERIOD +Target: Formal implementation of CSRB obligations when Act commences + +| Action | Owner | Target Date | Status | +|--------|-------|-------------|--------| +| Review enacted legislation and statutory guidance | Legal / Compliance | | | +| Update all templates against final legislation | CISO | | | +| Confirm CSRB reporting portal / route with CA | Compliance | | | +| Update Incident Response Plan with final timelines | CISO | | | +| Update contracts with key suppliers for CSRB obligations | Legal / Procurement | | | +| Conduct staff CSRB awareness training | HR / CISO | | | +| Complete formal CAF assessment (directed or self) | CISO | | | +| Establish quarterly board cyber risk report | CISO | | | + +PHASE 3 — ONGOING COMPLIANCE +Target: Sustain CSRB compliance programme + +| Activity | Frequency | Owner | +|----------|-----------|-------| +| CAF self-assessment review | Annual | CISO | +| Incident Response Plan test | Annual | CISO | +| Supply chain security review | Annual | CISO / Procurement | +| Third-party penetration test | Annual | CISO | +| Board cyber risk report | Quarterly | CISO | +| Access and privilege review | Quarterly | IT Security | +| Asset register review | Quarterly | IT Security | +| Patch management audit | Monthly | IT Security | +| Staff security awareness training | Annual (minimum) | HR / CISO | + +Approved by: +Name: _______________________ Role: ______________ Date: __________ +``` + +--- + +## Template 3 — Incident Response Plan (CSRB Edition) + +``` +INCIDENT RESPONSE PLAN — CSRB EDITION + +Organisation: +Version: +Approved By (Board/SRO): +Approval Date: +Next Review Date: + +1. SCOPE AND PURPOSE +This plan governs the organisation's response to cyber security incidents under the +Cyber Security and Resilience Bill. It covers detection, containment, notification, +investigation, and recovery. + +CSRB Entity Type: [ ] OES [ ] DSP [ ] MSP [ ] Data Centre +Competent Authority: +CA Contact for Incident Reporting: [name, email, phone, out-of-hours number] +NCSC Reporting: report.ncsc.gov.uk / 0300 020 0973 + +2. INCIDENT SEVERITY TIERS + +TIER 1 — CRITICAL (report immediately, 24-hour initial notification required) +Criteria: +- Any significant service disruption or outage exceeding [X] minutes +- Ransomware deployment detected +- Confirmed data exfiltration from in-scope systems +- Confirmed supply chain compromise affecting multiple clients +- State-affiliated threat actor suspected + +Escalation: CISO → CEO → Board within [X hours] +CA Notification: Within 24 hours of awareness + +TIER 2 — SIGNIFICANT (report within 24-72 hours) +Criteria: +- Unauthorized access to in-scope systems (contained) +- Near-miss: attack reached systems but service was not disrupted +- Data theft suspected but not confirmed +- Significant phishing campaign targeting staff + +Escalation: CISO → CEO within [X hours] +CA Notification: Within 72 hours + +TIER 3 — MINOR (internal response, log only) +Criteria: +- Contained malware not reaching critical systems +- Failed phishing attempts +- Minor policy violations with no security impact + +Escalation: CISO +CA Notification: Not required (log for CSRB annual review) + +3. REPORTING TIMELINE AND RESPONSIBILITIES + +Hour 0: Incident detected / reported + --> [Role] confirms classification (Tier 1/2/3) + --> [Role] initiates incident log + +Hour 1: Incident confirmed + --> CISO notified + --> Evidence preservation begins + --> Containment actions initiated + +Hour 4: Escalation assessment + --> CEO / SRO notified (Tier 1/2) + --> Decision: notify CA now or by Hour 24? + --> NCSC notification assessed + +Hour 24: MANDATORY — CA early notification (Tier 1 confirmed) + --> Early notification template submitted [see references/incident-reporting-csrb.md] + --> Confirm NCSC notified + --> Confirm client notification (if MSP) + --> Cross-regulatory assessment: ICO / FCA / NHS + +Hour 72: MANDATORY — Full incident notification (Tier 1) + --> Full incident notification template submitted + --> Root cause assessment initiated + --> Legal/regulatory hold on evidence confirmed + +Day 30: MANDATORY — Final incident report + --> Root cause confirmed + --> Remediation evidence documented + --> Final report submitted to CA + +4. NOTIFICATION CONTACTS + +External Notifications: + Competent Authority: [name] / [email] / [phone] / [portal URL] + NCSC: report.ncsc.gov.uk / 0300 020 0973 + ICO (if personal data breach): 0303 123 1113 / ico.org.uk + FCA (if regulated firm): 0800 111 6768 + Law enforcement: Action Fraud 0300 123 2040 / regional cybercrime unit + +Internal Escalation: + CISO: [name / phone / email] + CEO: [name / phone / email] + Legal Counsel: [name / phone / email] + Board CSRB SRO: [name / phone / email] + PR / Comms (if public notification likely): [name / phone / email] + +5. EVIDENCE PRESERVATION +Upon incident classification (Tier 1 or 2): + [ ] Isolate affected systems (without destroying volatile evidence if possible) + [ ] Take forensic image / memory dump of affected systems before remediation + [ ] Preserve and export relevant logs (SIEM, EDR, network, email) + [ ] Implement legal hold on all incident-related documentation + [ ] Do NOT wipe or rebuild affected systems until forensic evidence secured + +6. POST-INCIDENT REVIEW +Within 2 weeks of incident resolution: + [ ] Post-incident review meeting (CISO, IT leads, relevant business leads) + [ ] Root cause documented + [ ] Controls gaps identified + [ ] Remediation plan agreed with owners and deadlines + [ ] Lessons learned incorporated into this IRP + [ ] Executive briefing prepared + +Approved by: +Name: _________________________ Role: ____________ Date: __________ +``` + +--- + +## Template 4 — MSP CSRB Security Policy + +``` +MANAGED SERVICE PROVIDER CYBER SECURITY POLICY +CSRB EDITION + +Organisation (MSP): +Version: +Approved by (Board): +Approval Date: +Next Review Date: + +1. PURPOSE AND SCOPE +This policy sets out [MSP NAME]'s cyber security obligations and practices as a +Managed Service Provider subject to the UK Cyber Security and Resilience Bill. + +This policy applies to: +- All systems and infrastructure used to deliver managed services to clients +- All staff, contractors, and third parties with access to client environments +- All in-scope client environments as defined by CSRB + +2. COMPETENT AUTHORITY +The Competent Authority for managed service providers under the CSRB is expected to be DSIT. +This policy will be updated on enactment to reflect the confirmed CA designation. + +3. SECURITY REQUIREMENTS +[MSP NAME] maintains security controls aligned with: +- NCSC Cyber Assessment Framework (CAF) v3.2 (or current version) +- ISO 27001 (if certified — certificate number: [____]) +- Cyber Essentials Plus (if certified — certificate number: [____]) + +3.1 Shared Responsibility Model +For each client engagement, [MSP NAME] operates a defined shared responsibility model +documenting which security controls are managed by [MSP NAME] and which by the client. +This is documented in the [Client Security Schedule / Statement of Applicability]. + +4. INCIDENT REPORTING (CSRB) +4.1 MSP Obligations +[MSP NAME] will notify: +(a) The Competent Authority (DSIT or designated CA for MSPs) within 24 hours of detecting + an incident that affects or may affect client organisations +(b) Affected client organisations within 24 hours of detecting such an incident +(c) NCSC as soon as practicable + +4.2 Client Obligations +Clients who are OES or DSP under the CSRB retain their own obligation to notify their +Competent Authority. [MSP NAME]'s notification does not substitute for the client's own +reporting obligation. + +5. SUPPLY CHAIN SECURITY +[MSP NAME] requires sub-processors and sub-contractors with access to client environments +to meet equivalent security standards. Sub-processor security requirements are documented +in the [Supplier Security Schedule]. + +6. ACCESS CONTROL FOR CLIENT ENVIRONMENTS +- Privileged access to client environments requires MFA +- Just-in-time access controls applied where technically feasible +- All privileged access sessions are logged +- Access rights are reviewed quarterly and on staff change +- Shared credentials are not used for client environment access + +7. EVIDENCE AND AUDIT +[MSP NAME] maintains the following for CA assessment purposes: +- Asset register covering shared infrastructure and client-facing systems +- Access and privilege review records (quarterly) +- Patch management records +- CAF self-assessment (annual) +- Penetration test report (annual) +- Incident log (all incidents including Tier 3 minor incidents) + +8. REVIEW +This policy is reviewed annually and following any significant incident or regulatory change. + +Approved by: +Name: _________________________ Role: ____________ Date: __________ +``` + +--- + +## Template 5 — Board CSRB Briefing Note + +``` +BOARD BRIEFING NOTE +UK CYBER SECURITY AND RESILIENCE BILL + +RESTRICTED — BOARD ONLY + +Date: [YYYY-MM-DD] +Prepared by: [CISO / Compliance Director] +For: Board of Directors / Audit and Risk Committee + +1. EXECUTIVE SUMMARY +The UK Cyber Security and Resilience Bill (CSRB) is [progressing through Parliament / +has received Royal Assent]. This note sets out our organisation's obligations, current +readiness level, and recommended board actions. + +Bill status: [Insert current status from bills.parliament.uk] +Expected commencement: [Insert, or note TBC] + +2. HOW THE CSRB APPLIES TO US +Our organisation is classified as: [ ] OES [ ] DSP [ ] MSP [ ] Data Centre [ ] Multiple +Our Competent Authority under the CSRB: [name] + +This classification means: +- We have legally binding security requirements aligned with the NCSC Cyber Assessment + Framework +- We must report certain cyber incidents to [CA name] within 24 hours of awareness +- Our Competent Authority can conduct proactive audits of our security posture +- Financial penalties of up to [£X] apply for non-compliance + +3. CURRENT READINESS +Overall readiness score (from Template 1 Gap Assessment): [ /120] — [RAG status] + +Key strengths: +- [e.g., CAF assessment completed at Achieved level] + +Material gaps: +- [e.g., 24-hour reporting capability not fully tested] +- [e.g., Supply chain assessments incomplete] + +4. RECOMMENDED BOARD ACTIONS +(a) Appoint a named CSRB Senior Responsible Owner (SRO) at board level + Proposed SRO: [Name, Role] + +(b) Approve the CSRB Compliance Roadmap (Template 2) and associated budget + Estimated investment: [£X] for [period] + +(c) Establish quarterly board cyber risk reporting (CISO to present) + +(d) Review and approve the updated Incident Response Plan (Template 3) + +5. NEXT REVIEW +CISO will report to the Board at the next quarterly meeting with a progress update +against the CSRB Compliance Roadmap. + +Prepared by: _________________________ Date: __________ +Approved for circulation by: ___________ Date: __________ +``` + +--- + +## Template 6 — MSP Customer Security Addendum (CSRB) + +``` +MANAGED SERVICE PROVIDER — CUSTOMER SECURITY ADDENDUM (CSRB) + +This Addendum supplements the Master Service Agreement between [MSP NAME] ("MSP") +and [CLIENT NAME] ("Client") and sets out responsibilities under the UK Cyber Security +and Resilience Bill. + +Effective Date: +MSP: +Client: +Last Review Date: + +1. CSRB STATUS OF PARTIES +MSP CSRB status: [ ] In-scope MSP (CSRB) +Client CSRB status: [ ] OES [ ] DSP [ ] Neither [ ] Under assessment + +2. SECURITY RESPONSIBILITIES UNDER CSRB + +| Security Area | MSP Responsible | Client Responsible | Shared | +|--------------|-----------------|-------------------|--------| +| Network perimeter security (MSP infrastructure) | X | | | +| Endpoint security (client-owned endpoints) | | X | | +| Endpoint security (MSP-managed endpoints) | X | | | +| Identity and access management (client systems) | | X | | +| Privileged access management (MSP admin accounts) | X | | | +| Patch management (client servers under MSP management) | X | | | +| Patch management (client systems not under MSP management) | | X | | +| Incident detection (MSP infrastructure) | X | | | +| Incident detection (client systems) | | | X | +| CSRB incident notification to CA | [Both separately where applicable] | | | +| CAF self-assessment | Each party for own environment | | | + +3. INCIDENT NOTIFICATION +3.1 MSP obligations: MSP will notify Client within 24 hours of detecting an incident + affecting or potentially affecting Client's environment. +3.2 Client obligations: Client remains responsible for notifying its own Competent Authority + where the incident has significant impact on Client's essential or digital service. +3.3 Cooperation: Parties will cooperate in joint root cause analysis and provide one another + with relevant evidence for regulatory reporting. + +4. CA ASSESSMENT COOPERATION +If either party receives a directed assessment or information notice from a Competent Authority +that requires information relating to the shared service environment, the parties will cooperate +reasonably to provide the required information. + +5. RECORD RETENTION +MSP will retain security logs relevant to Client's environment for a minimum of [12/24] months +to support incident investigation and CA audit. + +Signed for [MSP NAME]: +Name: _________________________ Role: ____________ Date: __________ + +Signed for [CLIENT NAME]: +Name: _________________________ Role: ____________ Date: __________ +``` diff --git a/plugins/uk-nis/.claude-plugin/plugin.json b/plugins/uk-nis/.claude-plugin/plugin.json new file mode 100644 index 0000000..6b216bb --- /dev/null +++ b/plugins/uk-nis/.claude-plugin/plugin.json @@ -0,0 +1,24 @@ +{ + "name": "uk-nis", + "description": "UK Network and Information Systems (NIS) Regulations 2018 compliance advisor — Operators of Essential Services, Digital Service Providers, Cyber Assessment Framework (CAF) objectives, incident reporting obligations, competent authority requirements, and enforcement guidance.", + "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": [ + "uk-nis", + "nis-regulations", + "cyber-assessment-framework", + "caf", + "ncsc", + "oes", + "dsp", + "critical-infrastructure", + "cybersecurity", + "grc" + ] +} diff --git a/plugins/uk-nis/skills/uk-nis/SKILL.md b/plugins/uk-nis/skills/uk-nis/SKILL.md new file mode 100644 index 0000000..8e4b366 --- /dev/null +++ b/plugins/uk-nis/skills/uk-nis/SKILL.md @@ -0,0 +1,412 @@ +--- +name: uk-nis +description: > + Expert UK NIS Regulations 2018 compliance advisor. Use this skill whenever a user asks about + UK NIS, the Network and Information Systems Regulations 2018 (SI 2018/506), Operators of + Essential Services (OES), Digital Service Providers (DSPs), the NCSC Cyber Assessment + Framework (CAF), NIS incident reporting, NIS competent authorities (Ofgem, CAA, ORR, DfT, + DHSC, DWI, Ofcom, ICO), NIS enforcement notices, NIS security requirements, NIS gap + assessments, CAF self-assessments, or cybersecurity obligations for UK critical national + infrastructure. Also trigger for questions about UK NIS post-Brexit retention, the 14 CAF + security principles, critical sectors (energy, transport, health, water, digital + infrastructure), or NIS fines (up to 17 million GBP). When in doubt, use this skill. +--- + +# UK NIS Regulations 2018 — Compliance Skill + +You are an expert advisor on the UK Network and Information Systems (NIS) Regulations 2018 (SI 2018/506). You assist compliance teams, security professionals, and operators of essential services (OES) and digital service providers (DSPs) across all aspects of NIS compliance. + +> **Legal disclaimer:** This guidance is for informational purposes only and does not constitute legal advice. For formal compliance determinations, consult a qualified legal or regulatory specialist. + +--- + +## Quick Reference: What Does the User Need? + +| User Goal | Go To | +|---|---| +| "Are we in scope?" / scope determination | [Scope & Applicability](#1-scope--applicability) | +| Gap assessment / readiness review | [Gap Assessment Workflow](#2-gap-assessment-workflow) | +| Understanding security requirements | [Security Requirements & CAF](#3-security-requirements--caf) | +| Incident reporting obligations | [Incident Reporting](#4-incident-reporting) | +| Competent authority guidance | [Competent Authorities](#5-competent-authorities) | +| Enforcement, penalties & appeals | [Enforcement & Penalties](#6-enforcement--penalties) | +| Policy or document generation | [Policy & Document Generation](#7-policy--document-generation) | +| CAF objective deep-dive | [CAF Objectives Reference](#8-caf-objectives-reference) | + +--- + +## 1. Scope & Applicability + +### 1.1 Legislative Basis + +The NIS Regulations 2018 (Statutory Instrument 2018/506) came into force on **10 May 2018**. They implement the EU NIS Directive (Directive (EU) 2016/1148) into UK domestic law. Following Brexit, the Regulations were retained in UK law by the European Union (Withdrawal) Act 2018 and continue to apply in full. + +### 1.2 Who Is In Scope? + +The Regulations apply to two categories of entity: + +#### Operators of Essential Services (OES) + +An OES is an entity that: +1. Provides a service which is essential for the maintenance of critical societal or economic activities +2. The provision of that service depends on network and information systems +3. An incident would have significant disruptive effects on the provision of that service + +**Designated OES sectors and sub-sectors:** + +| Sector | Sub-sector | +|--------|-----------| +| Energy | Electricity (generation, transmission, distribution, supply) | +| Energy | Oil (transport, distribution, storage) | +| Energy | Gas (transmission, distribution, storage, LNG facilities, supply) | +| Transport | Air transport | +| Transport | Rail transport | +| Transport | Road transport (if designated — limited scope) | +| Transport | Water transport (inland waterways, sea ports, shipping) | +| Health | Healthcare providers (NHS Trusts, independent providers) | +| Drinking Water | Water supply and distribution | +| Digital Infrastructure | Internet Exchange Points (IXPs) | +| Digital Infrastructure | Domain Name System (DNS) service providers | +| Digital Infrastructure | Top-Level Domain (TLD) name registries | + +OES status is determined by relevant **Competent Authorities** (not self-declared). Competent Authorities issue designation decisions and maintain registers of OES within their sectors. + +#### Digital Service Providers (DSPs) + +Any legal person that provides one of the following digital services to recipients established in the UK, where the provider has its EU/UK establishment or (if outside the EU/UK) its designated UK representative: + +| DSP Type | Description | +|----------|------------| +| Online marketplace | Platform enabling consumers/traders to conclude online contracts | +| Online search engine | Platform enabling searches across all websites on a given input | +| Cloud computing service | IaaS, PaaS, or SaaS services (excluding micro and small enterprises with fewer than 50 employees and annual turnover/balance sheet not exceeding 10 million EUR) | + +**Exemptions:** +- Micro and small enterprises (fewer than 50 employees AND annual turnover/balance sheet total not exceeding 10 million EUR) are exempt from DSP requirements +- Public electronic communications networks and services (covered by NIS but under Ofcom competence) +- Trust service providers covered by the eIDAS Regulation + +### 1.3 Threshold Determination + +When assessing whether an entity is in scope, consider: + +**For OES designation:** +- Is the service essential to critical societal/economic activity? +- Does it depend on NIS? +- Would an incident cause significant disruption? +- The relevant Competent Authority makes the formal designation + +**For DSPs:** +- Is the entity providing online marketplace, search engine, or cloud services? +- Does the entity have 50 or more employees OR exceed 10 million EUR in turnover/balance sheet? +- Is the entity established in the UK or serving UK recipients? + +--- + +## 2. Gap Assessment Workflow + +### Step 1: Determine Entity Type and Scope +1. Confirm whether the entity is an OES or DSP (or both) +2. Identify the relevant Competent Authority +3. Confirm which systems are in scope (NIS systems that underpin the essential/digital service) + +### Step 2: Map Against CAF Objectives (OES) or DSP Security Measures + +For OES: Use the **14 CAF outcomes** as the assessment framework (see Section 3) +For DSPs: Use the **DSP Security Principles** (see Section 3.3) + +### Step 3: Collect Evidence + +For each CAF objective/outcome: +- Review existing policies, procedures, and technical controls +- Interview key personnel +- Review logs, audit records, and test results +- Check supplier/third-party arrangements + +### Step 4: Rate Each Outcome + +| Rating | Meaning | +|--------|---------| +| Achieved | All Indicators of Good Practice (IGP) are met; no Indicators of Poor Practice (IPP) apply | +| Partially Achieved | Some IGP met; no critical IPP; work in progress | +| Not Achieved | Critical IGP not met; significant IPP apply | +| Not Applicable | Outcome is not relevant to this system (document justification) | + +### Step 5: Produce Gap Report + +Structure output as: + +``` +## NIS Compliance Gap Assessment — [Entity Name] + +**Entity Type:** OES / DSP +**Sector:** [Sector] +**Competent Authority:** [CA name] +**Assessment Date:** [YYYY-MM-DD] +**Assessor:** [Name/Role] + +### Executive Summary +[Brief overview of compliance posture and critical gaps] + +### CAF Objective Assessment + +| Objective | Outcome | Rating | Evidence Reviewed | Gaps / Issues | Priority | +|-----------|---------|--------|-------------------|---------------|----------| +| A1 | Governance | Partial | IS Policy v2.1 | No board-level cyber sign-off | High | +| ... | ... | ... | ... | ... | ... | + +### Key Findings +1. [Finding 1 — severity, objective reference] +2. [Finding 2] + +### Recommended Actions +| Priority | Action | Objective | Owner | Target Date | +|----------|--------|-----------|-------|-------------| +| Critical | ... | A1 | CISO | 30 days | + +*This assessment uses the NCSC Cyber Assessment Framework (CAF) version 3.2 as the technical standard.* +``` + +--- + +## 3. Security Requirements & CAF + +### 3.1 Security Obligation (Regulation 10) + +OES must take **appropriate and proportionate** technical and organisational measures to manage risks to the security of NIS used for providing essential services. Proportionality is assessed against: +- The state of the art in security +- The risk presented +- Prevention and minimisation of impact of security incidents + +Regulation 10 does not prescribe specific controls — the **NCSC Cyber Assessment Framework (CAF)** is the UK government's primary technical standard for demonstrating compliance. + +### 3.2 CAF Overview + +The CAF was developed by the NCSC and is the primary assessment framework used by UK NIS Competent Authorities. It is structured around **4 objectives** and **14 contributing outcomes**. + +Load `references/caf-objectives.md` for the full detail of each outcome, its Indicators of Good Practice (IGP), and Indicators of Poor Practice (IPP). + +#### CAF Structure Summary + +| Objective | ID | Contributing Outcome | +|-----------|-----|---------------------| +| **A. Managing Security Risk** | A1 | Governance | +| | A2 | Risk Management | +| | A3 | Asset Management | +| | A4 | Supply Chain | +| **B. Protecting Against Cyber Attack** | B1 | Service Protection Policies and Processes | +| | B2 | Identity and Access Control | +| | B3 | Data Security | +| | B4 | System Security | +| | B5 | Resilient Networks and Systems | +| | B6 | Staff Awareness and Training | +| **C. Detecting Cyber Security Events** | C1 | Security Monitoring | +| | C2 | Proactive Security Event Discovery | +| **D. Minimising Impact of Cyber Security Incidents** | D1 | Response and Recovery Planning | +| | D2 | Improvements | + +### 3.3 DSP Security Measures (Regulation 12) + +DSPs must take appropriate and proportionate technical and organisational measures to manage risks to security of NIS, addressing: + +| Security Measure | Description | +|-----------------|-------------| +| Security of systems and facilities | Physical and logical security of network and information systems | +| Incident handling | Documented procedures for responding to incidents | +| Business continuity management | Measures for maintaining or restoring service delivery | +| Monitoring, auditing and testing | Regular assessment of security measures effectiveness | +| Compliance with international standards | Alignment with ISO/IEC 27001 or equivalent standards | + +DSPs also have incident reporting obligations to the **ICO** (Information Commissioner's Office) as the designated Competent Authority for DSPs in the UK. + +--- + +## 4. Incident Reporting + +### 4.1 OES Reporting Obligations (Regulation 11) + +OES must notify their relevant Competent Authority of any incident that has a **significant impact** on the continuity of the essential service. + +**Significant impact factors (Regulation 11(3)):** + +| Factor | Description | +|--------|-------------| +| Number of users affected | The number of users relying on the service affected by the incident | +| Duration | The length of time the incident lasted | +| Geographic spread | The geographic area affected by the incident | +| Extent of disruption | The degree to which the functioning of the service has been affected | +| Extent of impact | The extent of impact on economic and societal activities | + +**Notification timeline:** + +There is no specific statutory deadline stated in the NIS Regulations 2018 for initial notification. However, guidance from Competent Authorities (and the NCSC) consistently requires notification **as soon as reasonably practicable** — typically within 72 hours of becoming aware of a significant incident. + +**Notification must include:** +- Description of the incident +- Impacts on the continuity of the service +- Any cross-border impacts (where known) + +### 4.2 DSP Reporting Obligations (Regulation 13) + +DSPs must notify the ICO of incidents having **substantial impact** on the provision of a digital service. + +**Substantial impact factors:** + +| Factor | Description | +|--------|-------------| +| Number of users affected | Particularly those relying on the service for professional purposes | +| Duration | Hours of disruption | +| Geographic spread | Regions affected | +| Extent of disruption | Degree of impairment | +| Impact significance | Affected societal or economic functions | +| System integrity affected | Whether personal data security was compromised | + +**DSP notification timeline:** Without undue delay after becoming aware, and where feasible within 72 hours. + +### 4.3 Notification Template + +Load `references/incident-reporting.md` for structured notification templates for both OES and DSP incident reports. + +### 4.4 NCSC Reporting + +The NCSC is the technical advisory body for NIS in the UK. OES and DSPs are encouraged (and in some cases expected) to also report to the NCSC via the NCSC reporting portal at report.ncsc.gov.uk for technical assistance and national-level coordination. + +--- + +## 5. Competent Authorities + +### 5.1 OES Competent Authorities by Sector + +| Sector | Competent Authority | Website | +|--------|-------------------|---------| +| Electricity | Ofgem (Office of Gas and Electricity Markets) | ofgem.gov.uk | +| Oil | BEIS (Dept for Energy Security and Net Zero from 2023) | gov.uk/desnz | +| Gas | Ofgem | ofgem.gov.uk | +| Air transport | Civil Aviation Authority (CAA) | caa.co.uk | +| Rail transport | Office of Rail and Road (ORR) | orr.gov.uk | +| Road transport | Dept for Transport (DfT) | gov.uk/dft | +| Water transport (maritime) | Dept for Transport / Maritime and Coastguard Agency (MCA) | gov.uk/mca | +| Health | Department of Health and Social Care (DHSC) / NHS England | england.nhs.uk | +| Drinking water | Drinking Water Inspectorate (DWI) | dwi.gov.uk | +| Digital infrastructure (IXPs, DNS, TLDs) | Ofcom | ofcom.org.uk | + +### 5.2 DSP Competent Authority + +| DSP Type | Competent Authority | +|----------|-------------------| +| Online marketplaces, online search engines, cloud computing | Information Commissioner's Office (ICO) | + +### 5.3 Lead Government Authority + +The **Department for Science, Innovation and Technology (DSIT)** (formerly DCMS) has overall policy responsibility for UK NIS and coordination between Competent Authorities. + +### 5.4 CA Powers + +Competent Authorities have powers to: +- Request information from OES/DSPs to assess compliance +- Carry out security audits (directly or via approved third parties) +- Issue enforcement notices requiring specific security measures +- Issue penalty notices for non-compliance + +--- + +## 6. Enforcement & Penalties + +### 6.1 Enforcement Notices (Regulation 18) + +A Competent Authority may issue an **enforcement notice** where it is satisfied that an OES or DSP has failed, is failing, or is likely to fail to comply with the Regulations. The notice must specify: +- The nature of the failure +- The steps required to remedy the failure +- The time period for compliance + +### 6.2 Penalty Notices (Regulation 19) + +Following an enforcement notice, if the OES or DSP fails to comply, the Competent Authority may issue a **penalty notice** imposing a financial penalty. + +**Maximum financial penalties:** +- OES: up to **£17,000,000** +- DSP: up to **£17,000,000** + +These are maximum penalties; actual penalties are set proportionately based on: +- Severity and duration of the failure +- Whether the failure was deliberate or negligent +- Steps taken to mitigate damage +- Degree of cooperation with the Competent Authority +- Prior contraventions + +### 6.3 Appeals + +Appeals against enforcement notices and penalty notices are made to the **First-tier Tribunal (General Regulatory Chamber)** under Schedule 4 of SI 2018/506. + +### 6.4 No Criminal Liability + +The NIS Regulations 2018 do not create criminal offences. Non-compliance leads to civil enforcement notices and financial penalties only. + +--- + +## 7. Policy & Document Generation + +When generating NIS compliance documents, always include: +- Organisation name: `[ORGANISATION NAME]` +- Document version: `[VERSION]` +- Date: `[DATE]` +- Review cycle: `[REVIEW CYCLE]` +- Owner: `[OWNER/ROLE]` +- Reference to the specific NIS Regulation or CAF outcome satisfied + +### Common Documents + +| Document | NIS/CAF Reference | Template In | +|----------|------------------|-------------| +| NIS Compliance Policy | Reg 10, CAF A1 | references/templates.md | +| Risk Assessment & Register | Reg 10, CAF A2 | references/templates.md | +| Asset Register | CAF A3 | references/templates.md | +| Supplier Security Policy | CAF A4 | references/templates.md | +| Incident Response Plan | CAF D1, Reg 11 | references/templates.md | +| NIS Incident Notification | Reg 11 / Reg 13 | references/incident-reporting.md | +| CAF Self-Assessment Record | All CAF | references/caf-objectives.md | +| Business Continuity Plan | CAF D1, B5 | references/templates.md | +| Security Monitoring Procedure | CAF C1 | references/templates.md | + +--- + +## 8. CAF Objectives Reference + +Load `references/caf-objectives.md` for the complete CAF framework including all 14 outcomes with their full descriptions, Indicators of Good Practice (IGP), and Indicators of Poor Practice (IPP). + +### Quick Objective Summary + +**A — Managing Security Risk** +- A1 Governance: Board-level oversight of cyber risk; assigned accountability; integration into corporate governance +- A2 Risk Management: Systematic identification, assessment, and treatment of risks to NIS +- A3 Asset Management: Identification and classification of NIS assets; understanding of their role in service delivery +- A4 Supply Chain: Oversight and management of third-party and supply chain cyber risks + +**B — Protecting Against Cyber Attack** +- B1 Service Protection Policies & Processes: Documented, board-endorsed security policies; security by design; change management +- B2 Identity and Access Control: Least privilege; strong authentication; privileged account management; user lifecycle management +- B3 Data Security: Data classification; protection of sensitive data; media handling; data-in-transit and at-rest security +- B4 System Security: Secure configuration; patch management; vulnerability management; endpoint protection; software security +- B5 Resilient Networks and Systems: Network architecture; segregation; defence in depth; backups; fault tolerance +- B6 Staff Awareness and Training: Security awareness programme; role-based training; social engineering prevention + +**C — Detecting Cyber Security Events** +- C1 Security Monitoring: Centralised log collection; SIEM; alerting; user behaviour analytics; 24/7 monitoring capability +- C2 Proactive Security Event Discovery: Vulnerability scanning; penetration testing; threat hunting; threat intelligence + +**D — Minimising Impact of Cyber Security Incidents** +- D1 Response and Recovery Planning: Documented IRP; tested response procedures; business continuity; backups; recovery time objectives +- D2 Improvements: Post-incident reviews; lessons learned integration; root cause analysis; improvements to controls + +--- + +## Reference Files + +| File | Load When | +|------|-----------| +| `references/caf-objectives.md` | CAF deep-dive, gap assessment, policy mapping, control guidance | +| `references/incident-reporting.md` | Drafting incident notifications, understanding reporting thresholds | +| `references/oes-sectors.md` | Scope determination, OES sector detail, Competent Authority mapping | +| `references/templates.md` | Generating NIS policies, registers, plans, and compliance documents | + +Load **all** reference files for broad compliance reviews or programme-level assessments. diff --git a/plugins/uk-nis/skills/uk-nis/references/caf-objectives.md b/plugins/uk-nis/skills/uk-nis/references/caf-objectives.md new file mode 100644 index 0000000..2358755 --- /dev/null +++ b/plugins/uk-nis/skills/uk-nis/references/caf-objectives.md @@ -0,0 +1,434 @@ +# UK NIS — CAF Objectives Reference +## NCSC Cyber Assessment Framework (CAF) v3.2 + +The Cyber Assessment Framework (CAF) was developed by the National Cyber Security Centre (NCSC) and is the primary technical standard used by UK NIS Competent Authorities to assess compliance with the security requirements of the NIS Regulations 2018 (Regulation 10). + +The CAF is organised into **4 top-level objectives** and **14 contributing outcomes**. Each outcome has a set of **Indicators of Good Practice (IGP)** — characteristics of organisations that are achieving the outcome — and **Indicators of Poor Practice (IPP)** — characteristics indicating the outcome is not being met. + +--- + +## Objective A — Managing Security Risk + +Appropriate organisational structures, policies, and processes are in place to understand, assess, and systematically manage security risks to the network and information systems supporting essential services. + +--- + +### A1 — Governance + +**Outcome:** The organisation has effective organisational structures, policies, and processes in place to understand, assess, and systematically manage security risks to the network and information systems supporting the operation of essential services. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| A1.a | Board or senior management has overall accountability for cyber security and demonstrates active engagement | +| A1.b | There are clearly defined and widely understood roles and responsibilities for security of NIS across the organisation | +| A1.c | Decisions about security risk are taken at the appropriate level within the organisation (proportionate to risk) | +| A1.d | There are documented security policies relevant to the essential service, approved at board/senior management level | +| A1.e | Policies are communicated effectively to all relevant staff and third parties | +| A1.f | The organisation has processes for managing the security of NIS through transition or change | +| A1.g | There is a named individual with overall responsibility for cyber security (such as a CISO or equivalent) | +| A1.h | Cyber risk is included in the organisation's overall risk management framework | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| A1.i | There is no board-level or senior management ownership of cyber security risk | +| A1.ii | Security responsibilities are unclear, unassigned, or not communicated | +| A1.iii | Security policies are absent, outdated (not reviewed in 2+ years), or not approved by senior management | +| A1.iv | There is no mechanism to escalate security concerns to appropriate decision-makers | + +--- + +### A2 — Risk Management + +**Outcome:** The organisation takes a systematic approach to assessing and managing security risks to the network and information systems supporting the operation of essential services. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| A2.a | The organisation has a documented, systematic risk assessment process covering NIS | +| A2.b | Risk assessments are regularly reviewed and updated (at minimum annually, and following significant change) | +| A2.c | Risk treatment decisions are documented and approved by appropriate authority | +| A2.d | A risk register exists that covers cyber risks to NIS | +| A2.e | Residual risk is understood and accepted at the appropriate level within the organisation | +| A2.f | Threat intelligence is used to inform risk assessments | +| A2.g | Risk assessments consider insider threats, not just external threats | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| A2.i | No documented risk assessment process exists | +| A2.ii | Risk assessments have not been reviewed in over 12 months or following significant change | +| A2.iii | The risk register is absent, incomplete, or not linked to treatment actions | +| A2.iv | Risk treatment decisions are not documented or approved | + +--- + +### A3 — Asset Management + +**Outcome:** Everything required to deliver, maintain, or support essential services is determined and understood. This covers data, technology, facilities, and people. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| A3.a | The organisation has an up-to-date inventory of all NIS assets (hardware, software, data, people, facilities) | +| A3.b | Assets are classified by their criticality to essential service delivery | +| A3.c | Data flows to and from NIS are understood and documented | +| A3.d | Asset ownership is assigned for all critical assets | +| A3.e | The organisation understands interdependencies between assets and how failures could affect essential services | +| A3.f | The asset inventory is reviewed and updated regularly (at minimum annually and following changes) | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| A3.i | No asset inventory exists | +| A3.ii | The asset inventory is significantly incomplete or outdated | +| A3.iii | Asset criticality is not assessed or understood | +| A3.iv | Data flows are not mapped or understood | + +--- + +### A4 — Supply Chain + +**Outcome:** The organisation understands and manages security risks to its essential services from the supply chain, including third-party suppliers of technology, people, or facilities. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| A4.a | The organisation has identified all third-party suppliers who have access to, or influence over, NIS | +| A4.b | Security requirements are included in supplier contracts and service level agreements | +| A4.c | Suppliers are assessed for their cyber security practices prior to engagement and periodically thereafter | +| A4.d | Security incidents or changes by suppliers are reported to the organisation and managed appropriately | +| A4.e | There is a process for managing supplier termination and ensuring secure offboarding | +| A4.f | The organisation understands the security implications of software and hardware in the supply chain (e.g. SBOM awareness, firmware integrity) | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| A4.i | Suppliers with access to NIS are not identified | +| A4.ii | Contracts with critical suppliers contain no security requirements | +| A4.iii | Suppliers are never assessed for their security practices | +| A4.iv | Supplier incidents or changes are not reported to or acted upon by the organisation | + +--- + +## Objective B — Protecting Against Cyber Attack + +Proportionate security measures are in place to protect the essential service's network and information systems from cyber attack. + +--- + +### B1 — Service Protection Policies and Processes + +**Outcome:** The organisation defines, implements, communicates, and enforces appropriate policies and processes that direct its overall approach to securing systems and data that support delivery of the essential service. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| B1.a | Security policies are documented, approved by senior management, and actively communicated to relevant staff | +| B1.b | Security requirements are integrated into system and service design processes ("security by design") | +| B1.c | There is a documented change management process that includes security assessment of proposed changes to NIS | +| B1.d | The organisation has processes for scanning and testing to identify security vulnerabilities | +| B1.e | Security configurations are documented, maintained, and enforced | +| B1.f | There is a documented software development or procurement security standard | +| B1.g | Policies cover physical security of systems and facilities used to deliver vulnerable essential services | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| B1.i | No security policies exist or they are not followed in practice | +| B1.ii | Security is not considered during system design or procurement | +| B1.iii | Changes to NIS are not assessed for security impact | +| B1.iv | No vulnerability management process exists | + +--- + +### B2 — Identity and Access Control + +**Outcome:** The organisation understands, documents, and controls access to systems and functions that support delivery of the essential service. Access is controlled on a principle of least privilege. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| B2.a | User accounts are issued with the minimum privileges necessary for their role (least privilege) | +| B2.b | Privileged access is tightly controlled; the number of users with privileged access is minimised | +| B2.c | Multi-factor authentication (MFA) is in use for privileged access, remote access, and access to critical NIS | +| B2.d | Accounts are reviewed regularly and deprovisioned promptly when no longer required (e.g. on staff departure) | +| B2.e | Authentication credentials (especially passwords) are managed securely (no default credentials, password policies enforced) | +| B2.f | Access to NIS is logged; logs are reviewed | +| B2.g | Remote access is secured (e.g. via VPN, MFA, IP allowlisting) | +| B2.h | Service accounts are managed; credentials are unique and not shared | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| B2.i | Default credentials are in use on systems | +| B2.ii | Privileged access is not controlled or monitored | +| B2.iii | MFA is not used for privileged or remote access | +| B2.iv | Departed staff accounts are not removed promptly | +| B2.v | Access review processes do not exist | + +--- + +### B3 — Data Security + +**Outcome:** Data stored, processed, and transmitted by the networks and information systems supporting essential services is protected against unauthorised access, modification, or loss. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| B3.a | Sensitive data is identified, classified, and handled according to its classification | +| B3.b | Data at rest is encrypted where appropriate to the risk | +| B3.c | Data in transit is encrypted using appropriate protocols (e.g. TLS 1.2+) | +| B3.d | Removable media is controlled and encrypted; procedures exist for secure disposal | +| B3.e | Personal data (including PII linked to essential services) is handled in accordance with data protection requirements | +| B3.f | Backups of critical data are taken regularly, stored securely, and recovery is tested | +| B3.g | There are procedures for managing data throughout its lifecycle, including secure deletion | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| B3.i | Sensitive data is not identified or classified | +| B3.ii | Unencrypted data is transmitted or stored where encryption is appropriate | +| B3.iii | Backups are not taken or not tested | +| B3.iv | Removable media is uncontrolled | + +--- + +### B4 — System Security + +**Outcome:** Network and information systems used to deliver essential services are protected from exploitation of known vulnerabilities. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| B4.a | Systems are built and configured securely against an approved baseline configuration | +| B4.b | Patches and security updates are applied in a timely manner proportionate to risk (critical patches within 14 days as a benchmark) | +| B4.c | End-of-life systems are identified; either mitigating controls are in place or there is a plan to replace them | +| B4.d | Anti-malware protections are deployed where appropriate | +| B4.e | All software and hardware assets are inventoried; unauthorised assets and software are detected | +| B4.f | Security testing (e.g. penetration testing) is carried out regularly on NIS | +| B4.g | Secure software development practices are in use where software is developed in-house | +| B4.h | Systems are hardened; unnecessary services, ports, and protocols are disabled | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| B4.i | Critical patches are not applied within a reasonable timeframe | +| B4.ii | End-of-life systems are in use with no mitigation or replacement plan | +| B4.iii | Default system configurations are in use | +| B4.iv | No anti-malware deployed on applicable systems | + +--- + +### B5 — Resilient Networks and Systems + +**Outcome:** The organisation builds resilience against cyber attack and system failure into the design and operation of the networks and information systems that support essential services. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| B5.a | Network architecture is designed with security in mind; zones and segmentation are used to limit the impact of a compromise | +| B5.b | Critical NIS components have redundancy and failover in place | +| B5.c | There is documented and tested business continuity/disaster recovery capability for essential services | +| B5.d | Recovery time objectives (RTOs) and recovery point objectives (RPOs) are defined for critical systems | +| B5.e | NIS components are protected against denial-of-service attacks (e.g. DDoS mitigation) | +| B5.f | Network traffic is monitored; anomalous traffic can be detected and blocked | +| B5.g | Operational Technology (OT) and IT networks are appropriately segregated | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| B5.i | No network segmentation; a single compromise could affect the entire NIS or essential service | +| B5.ii | No redundancy or failover for critical systems | +| B5.iii | Business continuity or disaster recovery plans have not been tested | +| B5.iv | RT/RPOs are not defined | + +--- + +### B6 — Staff Awareness and Training + +**Outcome:** Staff have appropriate awareness and skills to support the security of network and information systems that deliver essential services. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| B6.a | All staff receive regular cyber security awareness training appropriate to their role | +| B6.b | Staff with specific security responsibilities receive role-appropriate technical training | +| B6.c | Awareness training includes recognition of phishing, social engineering, and insider threats | +| B6.d | Training completion is tracked and records are maintained | +| B6.e | Awareness programme content is reviewed and updated regularly (at minimum annually) | +| B6.f | Board/senior management receive appropriate cyber security briefings | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| B6.i | No security awareness training programme exists | +| B6.ii | Training has not been delivered or updated in over 12 months | +| B6.iii | Completion is not tracked | +| B6.iv | Senior management have received no cyber security briefing | + +--- + +## Objective C — Detecting Cyber Security Events + +Proportionate capabilities to detect cyber security events affecting, or with the potential to affect, essential services are in place. + +--- + +### C1 — Security Monitoring + +**Outcome:** The organisation monitors the security status of the networks and information systems supporting the delivery of essential services, to detect potential security problems and to track the ongoing effectiveness of protective measures. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| C1.a | Logs are collected from critical NIS components (servers, network devices, authentication systems, endpoints) | +| C1.b | Logs are centralised and retained for an appropriate period (minimum 6 months as a benchmark; longer for high-risk systems) | +| C1.c | Alerts are generated for security-relevant events; monitoring is continuous | +| C1.d | There is a defined process for reviewing and acting on security alerts | +| C1.e | The organisation has, or has access to, a Security Operations Centre (SOC) capability | +| C1.f | User and entity behaviour analytics (UEBA) or equivalent is used for detecting anomalous behaviour | +| C1.g | Monitoring capability includes detection of lateral movement, privilege escalation, and data exfiltration | +| C1.h | Out-of-hours monitoring or escalation procedures are in place | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| C1.i | Logging is absent or incomplete on critical systems | +| C1.ii | Logs are not reviewed; there is no alerting | +| C1.iii | Log retention is insufficient | +| C1.iv | There is no process for acting on alerts | + +--- + +### C2 — Proactive Security Event Discovery + +**Outcome:** Systems that support the delivery of essential services are checked for indications of compromise or malicious activity by proactive investigation of potential security breaches. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| C2.a | Regular vulnerability scanning is conducted on NIS | +| C2.b | Penetration testing is conducted periodically (minimum annually for high-risk systems, following significant changes) | +| C2.c | Threat intelligence is used to hunt for indicators of compromise in the organisation's NIS | +| C2.d | Results from testing and scanning are tracked and drive remediation actions | +| C2.e | The organisation participates in or accesses threat intelligence sharing (e.g. NCSC Early Warning, sector ISACs) | +| C2.f | Automated tools are used to detect misconfigurations and deviations from baseline in NIS | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| C2.i | No vulnerability scanning or penetration testing is conducted | +| C2.ii | Testing results are not acted upon or tracked | +| C2.iii | No threat intelligence is consumed or applied | + +--- + +## Objective D — Minimising the Impact of Cyber Security Incidents + +Capabilities to minimise the impact of a cyber security incident on the delivery of essential services are in place, including the restoration of those services where necessary. + +--- + +### D1 — Response and Recovery Planning + +**Outcome:** There are tested, organisation-specific response and recovery plans in place for cyber security incidents affecting systems supporting essential services. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| D1.a | A documented Incident Response Plan (IRP) exists that is specific to the organisation's NIS | +| D1.b | The IRP is tested at least annually (e.g. tabletop exercises, simulations) | +| D1.c | Roles and responsibilities during incident response are clearly defined and known | +| D1.d | Contact details for key personnel, Competent Authorities, NCSC, law enforcement, and critical suppliers are maintained and up to date | +| D1.e | Business continuity plans exist for essential services and are linked to the IRP | +| D1.f | Recovery plans include steps to restore systems from clean backups | +| D1.g | The organisation has procedures for communicating during an incident (internal staff, regulator, media, public) | +| D1.h | NIS incident notification procedures are documented and staff are aware of reporting obligations | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| D1.i | No IRP exists | +| D1.ii | The IRP has not been tested | +| D1.iii | Response roles are not defined or communicated | +| D1.iv | Contact information is unavailable or outdated | + +--- + +### D2 — Improvements + +**Outcome:** When a cyber security incident has occurred, steps are taken to understand its causes and reduce the risk of a similar incident occurring in future. + +#### Indicators of Good Practice (IGP) + +| IGP Ref | Description | +|---------|-------------| +| D2.a | Post-incident reviews are conducted following significant incidents | +| D2.b | Root cause analysis is performed and documented | +| D2.c | Lessons learned from incidents are fed back into risk assessments, policies, and controls | +| D2.d | Near-misses and security events (not just confirmed incidents) are reviewed for learning opportunities | +| D2.e | Changes to controls and processes resulting from lessons learned are tracked and implemented | +| D2.f | The organisation shares appropriate lessons learned with the relevant Competent Authority and NCSC where relevant | + +#### Indicators of Poor Practice (IPP) + +| IPP Ref | Description | +|---------|-------------| +| D2.i | No post-incident review process exists | +| D2.ii | Lessons learned are not documented or acted upon | +| D2.iii | The same type of incident recurs without control improvements | + +--- + +## CAF Assessment Rating Guidance + +### Rating Scale + +| Rating | Meaning | CAF Criteria | +|--------|---------|-------------| +| Achieved | All IGP are met; no IPP apply | Full compliance with the outcome | +| Partially Achieved | Most IGP are met; minor gaps; no critical IPP apply | Substantial progress but room for improvement | +| Not Achieved | Critical IGP not met; significant IPP apply | Material non-compliance | +| Not Applicable | The outcome is not relevant to this organisation's NIS | Documented justification required | + +### Prioritisation Framework + +When producing remediation plans, prioritise: +1. **Objectives A1 and A2** (Governance and Risk Management) — foundational to all other outcomes +2. **Objective D1** (Response and Recovery) — directly affects NIS resilience and regulatory reporting +3. **Objective B2** (Identity and Access Control) — high-impact protective control +4. **Objective C1** (Security Monitoring) — required for incident detection + +--- + +## Version Note + +This reference is based on **CAF v3.2** as published by the NCSC. The CAF is subject to revision; always verify against the current version at ncsc.gov.uk/collection/caf. diff --git a/plugins/uk-nis/skills/uk-nis/references/incident-reporting.md b/plugins/uk-nis/skills/uk-nis/references/incident-reporting.md new file mode 100644 index 0000000..19c4e27 --- /dev/null +++ b/plugins/uk-nis/skills/uk-nis/references/incident-reporting.md @@ -0,0 +1,253 @@ +# UK NIS — Incident Reporting Reference +## NIS Regulations 2018 — Regulations 11 and 13 + +--- + +## Overview + +The NIS Regulations 2018 establish mandatory incident notification obligations for both Operators of Essential Services (OES) and Digital Service Providers (DSPs). This reference covers the legal thresholds, reporting requirements, notification procedures, and practical guidance for compliance. + +--- + +## Part 1 — OES Incident Reporting (Regulation 11) + +### 1.1 Legal Basis + +**Regulation 11** of SI 2018/506 requires OES to notify the relevant Competent Authority of any incident that has a **significant impact on the continuity of the essential service** provided. + +### 1.2 What Is a Significant Impact? + +No fixed numeric threshold is prescribed. The Regulations list cross-cutting factors that Competent Authorities and the NCSC use to assess significance: + +| Factor | Relevant Considerations | +|--------|------------------------| +| **Number of users affected** | The count of users relying on the essential service who are impacted | +| **Duration of the incident** | How long the service disruption has lasted or is expected to last | +| **Geographic spread** | The geographic area in which the service is disrupted (local, regional, national) | +| **Extent of disruption to the service** | Degree to which functioning of the essential service is impaired | +| **Extent of impact on economic and societal activities** | Downstream effects on other critical services, businesses, or public safety | + +### 1.3 Notification Timeline + +The NIS Regulations 2018 do not specify an explicit number of hours. The requirement is to notify **as soon as reasonably practicable** after becoming aware of a significant incident. In practice: + +- Competent Authorities and the NCSC guidance consistently reference **72 hours** as the expected timeframe for initial notification +- Initial notifications may be partial; further details should be provided as they become available (updated notifications) +- Some Competent Authorities (e.g. Ofgem, CAA) publish sector-specific guidance specifying their preferred timelines and formats + +**Key principle:** Do not delay reporting pending completion of a full investigation. Notify early with known information and supplement as the incident develops. + +### 1.4 Who to Notify (OES) + +| Sector | Primary Notification Recipient | +|--------|-------------------------------| +| Electricity | Ofgem | +| Oil | Department for Energy Security and Net Zero (DESNZ) | +| Gas | Ofgem | +| Air transport | Civil Aviation Authority (CAA) | +| Rail transport | Office of Rail and Road (ORR) | +| Road transport | Department for Transport (DfT) | +| Water transport / maritime | Department for Transport / Maritime and Coastguard Agency (MCA) | +| Health | Department of Health and Social Care (DHSC) / NHS England | +| Drinking water | Drinking Water Inspectorate (DWI) | +| Digital infrastructure (IXP, DNS, TLD) | Ofcom | + +In addition to the Competent Authority, OES should notify the **NCSC** (National Cyber Security Centre) via report.ncsc.gov.uk for technical assistance and national-level coordination. + +### 1.5 OES Notification Template + +``` +NIS INCIDENT NOTIFICATION — OPERATOR OF ESSENTIAL SERVICES + +Submission Date/Time: [YYYY-MM-DD HH:MM UTC] +Notification Type: [ ] Initial [ ] Updated [ ] Final + +-- ORGANISATION DETAILS -- +Organisation Name: +NIS Sector: +Competent Authority: +Primary NIS Contact Name: +Primary NIS Contact Role: +Primary NIS Contact Email: +Primary NIS Contact Telephone: + +-- INCIDENT DETAILS -- +Date/Time Incident Detected (UTC): [YYYY-MM-DD HH:MM] +Date/Time Incident Started (if known, UTC): [YYYY-MM-DD HH:MM] +Systems/Services Affected: [Brief description of affected systems] +Nature of the Incident: + [ ] Cyber attack (malware, ransomware, phishing, etc.) + [ ] Denial of Service + [ ] Unauthorised access / data breach + [ ] System/software failure + [ ] Third-party / supply chain compromise + [ ] Physical attack on NIS + [ ] Other (describe below) + +-- IMPACT ASSESSMENT -- +Current Status: + [ ] Ongoing [ ] Contained [ ] Resolved +Description of impact on essential service continuity: +Estimated number of users affected: +Geographic area affected: +Duration of disruption (actual or estimated): +Cross-border impact considered? [ ] No [ ] Yes — describe: + +-- RESPONSE ACTIONS -- +Immediate actions taken: +Containment measures in place: +External assistance engaged (NCSC, law enforcement, etc.): + +-- REGULATORY NOTES -- +Has law enforcement been notified? [ ] No [ ] Yes — which force: +Has the NCSC been separately notified? [ ] No [ ] Yes +Are there personal data concerns (GDPR/UK GDPR)? [ ] No [ ] Yes — ICO notified?: + +-- NEXT STEPS -- +Planned remediation actions: +Estimated restoration timeframe: +Next update expected: [YYYY-MM-DD] + +Signed: [Name, Role, Date] +``` + +--- + +## Part 2 — DSP Incident Reporting (Regulation 13) + +### 2.1 Legal Basis + +**Regulation 13** of SI 2018/506 requires DSPs to notify the ICO (Information Commissioner's Office) of incidents having a **substantial impact** on the provision of a digital service. + +### 2.2 What Is a Substantial Impact? + +The NIS Regulations prescribe specific parameters for DSP impact assessment: + +| Parameter | Threshold | +|-----------|-----------| +| **Number of users affected** | Particularly users relying on the service for business/professional purposes | +| **Duration** | Hours of service disruption | +| **Geographic spread** | Area in the UK (and EEA where applicable) affected | +| **Extent of disruption** | The degree to which the digital service is impaired | +| **Impact on societal and economic activities** | Whether downstream activities dependent on the DSP are affected | +| **System integrity** | Whether systems have been compromised, affecting availability, authenticity, or integrity | + +Guidance from the ICO specifies concrete thresholds that indicate a substantial impact (these are guidelines, not fixed legal thresholds): + +- More than **1 million user accounts** affected +- Service unavailability exceeding **5% of users** for more than 30 minutes +- Data integrity or confidentiality compromise affecting business users + +### 2.3 Notification Timeline (DSP) + +Without undue delay and, where feasible, **within 72 hours** of becoming aware of the incident. + +### 2.4 Who to Notify (DSP) + +**Primary notification:** Information Commissioner's Office (ICO) +- ICO NIS notification: ico.org.uk/for-organisations/cybersecurity/ +- ICO helpline: 0303 123 1113 + +Where the incident also constitutes a personal data breach under UK GDPR, the same report to the ICO may cover both obligations, but the organisation should clearly identify it as both a NIS notification and a UK GDPR Article 33 notification. + +Also notify the **NCSC** at report.ncsc.gov.uk for technical coordination. + +### 2.5 DSP Notification Template + +``` +NIS INCIDENT NOTIFICATION — DIGITAL SERVICE PROVIDER + +Submission Date/Time: [YYYY-MM-DD HH:MM UTC] +Notification Type: [ ] Initial [ ] Updated [ ] Final + +-- ORGANISATION DETAILS -- +Organisation Name: +DSP Type: [ ] Online Marketplace [ ] Online Search Engine [ ] Cloud Computing +UK Establishment Address: +Primary NIS Contact Name: +Primary NIS Contact Role: +Primary NIS Contact Email: +Primary NIS Contact Telephone: + +-- INCIDENT DETAILS -- +Date/Time Incident Detected (UTC): [YYYY-MM-DD HH:MM] +Date/Time Incident Started (if known, UTC): [YYYY-MM-DD HH:MM] +Systems / Services Affected: [Describe affected components of the digital service] +Nature of the Incident: + [ ] Cyber attack (malware, ransomware, DDoS, etc.) + [ ] Unauthorised access / data breach + [ ] Processing failure / system crash + [ ] Third-party / supply chain compromise + [ ] Other (describe below) + +-- IMPACT ASSESSMENT -- +Is the incident still ongoing? [ ] Yes [ ] No — resolved at: [YYYY-MM-DD HH:MM] +Estimated number of users affected (total): +Estimated number of business/professional users affected: +Duration of disruption: +Geographic area affected: +Was the availability, authenticity, integrity, or confidentiality of systems impacted? [ ] Yes [ ] No +Describe impact on societal/economic activities: + +-- RESPONSE ACTIONS -- +Actions taken to contain and respond: +External assistance engaged (NCSC, law enforcement, etc.): + +-- CROSS-REGULATORY NOTE -- +Does this incident also constitute a UK GDPR personal data breach? + [ ] No [ ] Yes — UK GDPR Art. 33 report also submitted? [ ] Yes [ ] No +Has law enforcement been notified? [ ] No [ ] Yes + +-- NEXT STEPS -- +Planned remediation: +Estimated full restoration timeframe: +Next update expected: [YYYY-MM-DD] + +Signed: [Name, Role, Date] +``` + +--- + +## Part 3 — Post-Incident Requirements + +### 3.1 Follow-Up Notifications + +Initial notifications are often partial. Both OES and DSPs should submit: +1. **Initial notification** — as soon as practicable after becoming aware +2. **Interim updates** — as significant new information becomes available +3. **Final notification** — once the incident is resolved, confirming full details of cause, impact, and remediation + +### 3.2 Record-Keeping + +Organisations must retain records of: +- All NIS incidents (regardless of reporting threshold) +- Notification submissions and acknowledgements +- Correspondence with Competent Authorities and the NCSC +- Incident timeline, evidence, and investigation findings +- Post-incident review reports and lessons learned + +Recommended retention period: **minimum 3 years**; longer if there is ongoing regulatory engagement. + +### 3.3 Interaction with Other Reporting Obligations + +| Regime | Interaction with NIS Reporting | +|--------|-------------------------------| +| **UK GDPR (Art. 33)** | If the incident involves personal data breach, report to ICO under UK GDPR within 72 hours in addition to NIS notification (for OES: separate reports; for DSPs: may be combined with ICO) | +| **Network and information systems — Ofcom** | Ofcom-regulated communications providers have additional reporting obligations under the Communications Act 2003 / electronic communications security regulations | +| **FCA (financial sector)** | Financial services firms may have concurrent FCA operational resilience/incident reporting obligations | +| **NHS DSPT / DSPT** | NHS organisations have concurrent Data Security and Protection Toolkit reporting requirements | +| **Police / NCSC** | Significant cyber incidents should be reported to relevant law enforcement (Action Fraud, Regional Organised Crime Units) and NCSC | + +--- + +## Part 4 — Non-Reportable Incidents + +Not all incidents need to be reported under NIS. The following should be logged internally but are unlikely to meet the NIS reporting threshold: + +- Minor malware infections with no impact on essential service delivery +- Single workstation compromise with no access to NIS +- Phishing emails intercepted before any click/compromise +- Brief system unavailability due to planned maintenance +- Failed attack attempts with no breach or service impact + +Always document the assessment of why an incident did not meet the significant/substantial impact threshold. diff --git a/plugins/uk-nis/skills/uk-nis/references/oes-sectors.md b/plugins/uk-nis/skills/uk-nis/references/oes-sectors.md new file mode 100644 index 0000000..4b1ee58 --- /dev/null +++ b/plugins/uk-nis/skills/uk-nis/references/oes-sectors.md @@ -0,0 +1,262 @@ +# UK NIS — OES Sectors, Competent Authorities, and Designation Reference +## NIS Regulations 2018 — Schedule 2 and Competent Authority Designations + +--- + +## Overview + +Under the NIS Regulations 2018, Operators of Essential Services (OES) are designated by Competent Authorities within the sectors listed in **Schedule 2** of the Regulations. This reference provides the complete sector breakdown, Competent Authority details, designation criteria, and key considerations for each sector. + +--- + +## Sector 1 — Energy + +### 1.1 Electricity + +**Competent Authority:** Ofgem (Office of Gas and Electricity Markets) + +**Scope:** +- Electricity generation operators (above designation threshold) +- Electricity transmission system operators (National Grid ESO / NESO) +- Electricity distribution network operators +- Electricity suppliers providing to business and/or domestic consumers + +**Designation Criteria:** +Ofgem applies thresholds related to installed generation capacity, volume of electricity transmitted/distributed, and number of customers served. Over 250 megawatts installed capacity is a typical benchmark for generation OES designation. + +**Key Regulatory Context:** +- Ofgem coordinates with National Cyber Security Centre (NCSC) and DSIT +- Alignment with NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) is relevant for interconnected systems +- Electricity sector also subject to Critical National Infrastructure (CNI) designation by the Centre for the Protection of National Infrastructure (CPNI/NPSA) + +--- + +### 1.2 Oil + +**Competent Authority:** Department for Energy Security and Net Zero (DESNZ) (previously BEIS) + +**Scope:** +- Oil pipeline operators +- Oil storage/terminal operators +- Oil distribution operators + +**Key Regulatory Context:** +- Applies to entities operating crude oil and petroleum product pipelines, terminals, and distribution systems +- Excludes retail petrol stations (not designated NIS OES) +- DESNZ works with NCSC for technical guidance + +--- + +### 1.3 Gas + +**Competent Authority:** Ofgem + +**Scope:** +- Gas transmission system operators (National Grid Gas Transmission) +- Gas distribution network operators +- Gas storage operators (e.g. underground storage, LNG facilities) +- Gas suppliers + +**Key Regulatory Context:** +- Gas networks are defined as High-Pressure Transmission System (HPTS) and Local Distribution Zones (LDZ) operated by Gas Distribution Networks (GDNs) +- Ofgem's Network Security Guidelines reference the NIS Regulations + +--- + +## Sector 2 — Transport + +### 2.1 Air Transport + +**Competent Authority:** Civil Aviation Authority (CAA) + +**Scope:** +- UK-licensed air carriers with significant UK operations +- UK airport operators (above passenger volume threshold — typically major international airports) +- Air traffic management / Air navigation service providers (NATS) + +**Key Regulatory Context:** +- CAA's Civil Aviation Security Regulations 2016 run alongside NIS +- NATS coordinates with NCSC on critical air traffic management system security +- Passenger threshold: airports handling over 10 million passengers per annum are likely designated OES; exact threshold is sector-specific guidance from CAA + +--- + +### 2.2 Rail Transport + +**Competent Authority:** Office of Rail and Road (ORR) + +**Scope:** +- Network Rail (infrastructure operator) +- Train operating companies (TOCs) managing significant rail operations +- London Underground (TfL) +- European Rail Traffic Management System (ERTMS) systems + +**Key Regulatory Context:** +- ORR NIS guidance references CAF as the primary assessment tool +- Key concern: signalling systems, operational control systems, ticketing infrastructure + +--- + +### 2.3 Road Transport + +**Competent Authority:** Department for Transport (DfT) + +**Scope:** +- Intelligent Transport Systems (ITS) operators +- Road operators with significant motorway/trunk road digital infrastructure (e.g. National Highways) + +**Key Regulatory Context:** +- Road OES designation is more limited in scope than other transport sectors +- Focus on critical traffic management and road safety systems + +--- + +### 2.4 Water Transport (Maritime) + +**Competent Authority:** Department for Transport (DfT) / Maritime and Coastguard Agency (MCA) + +**Scope:** +- UK port operators (major ports above passenger/freight threshold) +- Ship operators of UK-flagged vessels (above applicable gross tonnage thresholds) +- Vessel Traffic Services (VTS) + +**Key Regulatory Context:** +- International Maritime Organization (IMO) Maritime Cyber Risk Management guidelines (MSC-FAL.1/Circ.3) are relevant +- Port operators align with ISPS Code (International Ship and Port Facility Security Code) + +--- + +## Sector 3 — Health + +**Competent Authority:** Department of Health and Social Care (DHSC) / NHS England + +**Scope:** +- NHS Trusts (Acute, Mental Health, Ambulance, Community) in England +- NHS Scotland, NHS Wales, HSCNI (devolved; equivalent frameworks apply) +- Independent healthcare providers contracted by the NHS for significant clinical services +- GP federations and health networks above designation threshold + +**Key Regulatory Context:** +- NHS Data Security and Protection Toolkit (DSPT) aligns with and supplements NIS requirements +- CAF is used alongside DSPT for OES assessment +- Critical concern: Electronic Patient Record (EPR) systems, NHS Spine connectivity, diagnostic imaging, prescription management +- DHSC works with NHS England and NCSC on threat intelligence and assurance + +--- + +## Sector 4 — Drinking Water + +**Competent Authority:** Drinking Water Inspectorate (DWI) + +**Scope:** +- Water companies providing potable water supply and distribution (e.g. Severn Trent, Thames Water, Yorkshire Water, United Utilities, Anglian Water, South West Water, and others) +- Water treatment works operators above relevant supply volume thresholds + +**Key Regulatory Context:** +- DWI has close coordination with Ofwat (economic regulation) and NCSC +- OT/SCADA systems for water treatment and distribution are in scope (SCADA, SCADA-adjacent systems, industrial control systems) +- Separation of IT from OT is a consistent DWI requirement + +--- + +## Sector 5 — Digital Infrastructure + +**Competent Authority:** Ofcom + +**Scope:** +- Internet Exchange Points (IXPs) — facilities where different networks interconnect to exchange traffic +- Domain Name System (DNS) service providers — organisations providing recursive and/or authoritative DNS resolution services at scale +- Top-Level Domain (TLD) name registries — organisations managing .uk, .co.uk, and other UK-relevant TLDs (notably Nominet) + +**Key Regulatory Context:** +- Ofcom designation applies to entities meeting significance thresholds for these services +- The number of DNS queries resolved, interconnection capacity (Gbps), and domain names managed are relevant designation factors +- Significant overlap with the NIS Category 1 definition + +--- + +## Digital Service Providers (DSPs) + +DSPs are not designated by Competent Authorities — they fall within scope automatically based on the services they provide and their size. The Competent Authority for all DSPs in the UK is the **Information Commissioner's Office (ICO)**. + +| DSP Type | Scope Description | +|----------|------------------| +| Online marketplace | A digital service that allows consumers and/or traders to conclude online sales or service contracts with traders | +| Online search engine | A digital service that allows users to perform searches of, in principle, all websites, or websites in a particular language | +| Cloud computing service | A digital service that enables access to a scalable and elastic pool of shareable computing resources — including IaaS, PaaS, and SaaS models | + +**DSP size exemption:** Micro enterprises (fewer than 10 employees; turnover/balance sheet not exceeding 2 million EUR) and small enterprises (fewer than 50 employees; turnover/balance sheet not exceeding 10 million EUR) are **exempt** from DSP NIS requirements. + +--- + +## Competent Authority Contact Summary + +| Competent Authority | Sectors | Primary NIS Contact Route | +|--------------------|---------|--------------------------| +| Ofgem | Electricity, Gas | ofgem.gov.uk — contact via network security team | +| DESNZ | Oil | gov.uk/desnz | +| CAA | Air transport | caa.co.uk — Security & Facilitation Division | +| ORR | Rail transport | orr.gov.uk — digital and cyber team | +| DfT | Road transport, Maritime | gov.uk/dft | +| MCA | Maritime (shipping/ports) | gov.uk/mca | +| DHSC / NHS England | Health | england.nhs.uk — CISO / Data Security | +| DWI | Drinking water | dwi.gov.uk | +| Ofcom | Digital infrastructure | ofcom.org.uk — Communications Security | +| ICO | DSPs | ico.org.uk/for-organisations/cybersecurity/ | + +**Lead Government Authority (NIS Policy):** +Department for Science, Innovation and Technology (DSIT) — gov.uk/dsit + +**National Technical Authority:** +National Cyber Security Centre (NCSC) — ncsc.gov.uk + +--- + +## CA Powers Under the NIS Regulations + +Under Regulations 15–19, Competent Authorities have the following statutory powers: + +| Power | Regulation | Description | +|-------|-----------|-------------| +| Information requests | Reg 15 | CAs may request information to assess compliance with the Regulations | +| Security audits | Reg 16 | CAs may carry out (or commission) security audits of OES/DSPs | +| Inspections | Reg 17 | CAs may conduct site inspections of OES/DSPs | +| Enforcement notices | Reg 18 | CAs may issue notices requiring OES/DSPs to take specific steps to comply | +| Penalty notices | Reg 19 | CAs may impose financial penalties following non-compliance with an enforcement notice | +| Inspectors' powers | Reg 20 | Inspectors acting for CAs have powers to enter premises and examine documents | + +--- + +## NIS Regulations 2018 — Key Provisions Summary + +| Regulation | Subject | +|-----------|---------| +| Regulation 1 | Citation, commencement, and interpretation | +| Regulation 3 | Obligation on Secretary of State to designate Competent Authorities | +| Regulation 5 | Designation of OES by Competent Authorities | +| Regulation 6 | Competent Authority registers of OES | +| Regulation 7 | Relevant digital services (DSP scope) | +| Regulation 8 | Point of establishment / representative for non-UK DSPs | +| Regulation 10 | OES security obligation (take appropriate and proportionate measures) | +| Regulation 11 | OES incident notification obligation | +| Regulation 12 | DSP security obligation | +| Regulation 13 | DSP incident notification obligation | +| Regulation 14 | NCA (NCSC) functions as national cybersecurity authority | +| Regulation 15 | CA power to request information | +| Regulation 16 | CA power to audit | +| Regulation 17 | CA power to inspect | +| Regulation 18 | Enforcement notices | +| Regulation 19 | Penalty notices | +| Schedule 1 | Essential services sectors and sub-sectors | +| Schedule 2 | Competent Authority designations by sector | +| Schedule 3 | Digital services in scope (DSP types) | + +--- + +## devolved Administrations + +The NIS Regulations 2018 apply across the **United Kingdom** (England, Scotland, Wales, and Northern Ireland). Devolved institutions apply the Regulations within their devolved health and other portfolios but the UK-wide framework remains consistent. + +- **NHS Scotland**: Scottish Government Health Directorate / NHS National Services Scotland +- **NHS Wales**: Welsh Government / Digital Health and Care Wales +- **HSCNI**: Department of Health Northern Ireland diff --git a/plugins/uk-nis/skills/uk-nis/references/templates.md b/plugins/uk-nis/skills/uk-nis/references/templates.md new file mode 100644 index 0000000..7d88332 --- /dev/null +++ b/plugins/uk-nis/skills/uk-nis/references/templates.md @@ -0,0 +1,504 @@ +# UK NIS — Policy and Document Templates +## NIS Regulations 2018 — Document Generation Reference + +--- + +## Instructions for Use + +When generating compliance documents, replace all `[PLACEHOLDER]` values with organisation-specific information. Each template cites the NIS Regulation or CAF outcome it satisfies. All documents should be reviewed by qualified legal or compliance professionals before formal adoption. + +--- + +## Template 1 — NIS Compliance Policy + +``` +[ORGANISATION NAME] +NIS COMPLIANCE POLICY + +Version: [e.g., 1.0] +Status: [Draft | For Review | Approved] +Date: [YYYY-MM-DD] +Owner: [ROLE, e.g., Chief Information Security Officer] +Approved by: [ROLE, e.g., Board / Executive Committee] +Next Review: [YYYY-MM-DD] + +NIS Reference: Regulation 10 (OES) / Regulation 12 (DSP) +CAF Reference: A1 — Governance + +--- + +1. PURPOSE + +This policy establishes [ORGANISATION NAME]'s commitment to complying with +the Network and Information Systems (NIS) Regulations 2018 (SI 2018/506) and +sets out the organisation's approach to managing the security of network and +information systems that underpin the delivery of [essential service / digital +service]. + +2. SCOPE + +This policy applies to: +- All network and information systems (NIS) used to provide [service description] +- All employees, contractors, and third parties with access to or responsibility + for those systems +- All digital and physical assets that form part of or support the NIS + +3. ORGANISATION TYPE AND SECTOR + +[ORGANISATION NAME] is designated as an: + [ ] Operator of Essential Services (OES) + [ ] Digital Service Provider (DSP) + +Sector / Service type: [e.g., Electricity Distribution / Cloud Computing] +Competent Authority: [e.g., Ofgem / ICO] + +4. NIS LEAD ACCOUNTABILITY + +The [ROLE, e.g., CISO / Head of Cyber Security] has overall accountability +for NIS compliance within this organisation, reporting to [ROLE]. + +Overall board accountability rests with [ROLE, e.g., Chief Executive / Chair of +Risk Committee]. + +5. SECURITY OBLIGATIONS + +[ORGANISATION NAME] commits to: + +5.1 Implementing appropriate and proportionate technical and organisational + measures to manage risks to the security of NIS (Regulation 10/12). + +5.2 Conducting and maintaining a systematic cyber risk assessment covering + all NIS in scope. + +5.3 Implementing controls aligned to the NCSC Cyber Assessment Framework (CAF) + (for OES) or the DSP security parameters (for DSPs). + +5.4 Notifying the relevant Competent Authority of incidents having a + significant/substantial impact on service continuity without undue delay + (Regulation 11/13). + +5.5 Supporting any Competent Authority audit, inspection, or information + request exercised under Regulations 15-17. + +6. POLICY REVIEW + +This policy is reviewed [ANNUALLY / FOLLOWING SIGNIFICANT CHANGE] by [ROLE]. + +7. RELATED DOCUMENTS + +- Risk Assessment and Risk Register +- Asset Register +- Incident Response Plan +- Supplier Security Policy +- CAF Self-Assessment Record + +Signed: _______________________ Date: ___________ +[NAME, ROLE, e.g., Chief Executive] +``` + +--- + +## Template 2 — NIS Risk Assessment and Risk Register + +``` +[ORGANISATION NAME] +NIS RISK ASSESSMENT AND REGISTER + +Version: [e.g., 1.0] +Date: [YYYY-MM-DD] +Owner: [ROLE] +Review Date: [YYYY-MM-DD] + +NIS Reference: Regulation 10 / Regulation 12 +CAF Reference: A2 — Risk Management + +--- + +RISK ASSESSMENT METHODOLOGY +Likelihood: 1 (Rare) to 5 (Almost Certain) +Impact: 1 (Negligible) to 5 (Critical — loss of essential service) +Risk Score: Likelihood x Impact (1-25) + +Risk Appetite: [e.g., risks with score > 15 require immediate treatment] + +--- + +RISK REGISTER (repeat rows as required) + +| Risk ID | NIS System / Asset | Threat | Vulnerability | Likelihood (1-5) | Impact (1-5) | Risk Score | Current Controls | Treatment | Residual Risk | Owner | Review Date | +|---------|-------------------|--------|--------------|------------------|-------------|------------|-----------------|-----------|--------------|-------|-------------| +| R-001 | [e.g., SCADA] | Ransomware | Unpatched systems | 3 | 5 | 15 | AV, patching | Mitigate — accelerate patching | 9 | IT Manager | YYYY-MM-DD | +| R-002 | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | + +Treatment options: Accept | Avoid | Transfer | Mitigate + +Risk Register Approved by: [NAME, ROLE, DATE] +``` + +--- + +## Template 3 — NIS Asset Register + +``` +[ORGANISATION NAME] +NIS ASSET REGISTER + +Version: [e.g., 1.0] +Date: [YYYY-MM-DD] +Owner: [ROLE] + +NIS Reference: Regulation 10 +CAF Reference: A3 — Asset Management + +--- + +ASSET REGISTER (repeat rows as required) + +| Asset ID | Asset Name / Description | Asset Type | Location | Criticality | Owner | NIS Role | System Connections | Last Reviewed | +|----------|------------------------|-----------|----------|-------------|-------|----------|--------------------|--------------| +| A-001 | [e.g., Control Room Server] | Server | [Location] | Critical | [Name] | SCADA host | [Network segments] | YYYY-MM-DD | +| A-002 | ... | ... | ... | ... | ... | ... | ... | ... | + +Asset Types: Server | Workstation | Network Device | Application | Database | OT/ICS Device | Cloud Service | Data Store | People | Facility + +Criticality Levels: +- Critical: Failure would directly impair essential service delivery +- High: Failure would significantly impact essential service +- Medium: Failure would partially impact service +- Low: Failure has minimal direct service impact + +Asset Register Reviewed by: [NAME, ROLE, DATE] +``` + +--- + +## Template 4 — Supplier Security Assessment Questionnaire + +``` +[ORGANISATION NAME] +SUPPLIER NIS SECURITY ASSESSMENT + +Supplier Name: [NAME] +Date of Assessment: [YYYY-MM-DD] +Assessed by: [NAME, ROLE] +Supplier Contact: [NAME, ROLE, EMAIL] + +NIS Reference: Regulation 10 +CAF Reference: A4 — Supply Chain + +--- + +SECTION A — ORGANISATION AND CONTACT + +1. Registered company name and number: +2. Primary contact for security matters: +3. Does the supplier have ISO 27001 certification? [ ] Yes — certificate no.: [ ] No +4. Does the supplier have Cyber Essentials / CE+? [ ] Yes [ ] No + +SECTION B — ACCESS TO IN-SCOPE NIS + +5. What type of access does the supplier have to [ORGANISATION NAME]'s NIS? + [ ] Remote access [ ] Physical access [ ] Software/code changes [ ] Data processing [ ] None +6. Describe the business purpose of the supplier's access: +7. Is the supplier a sub-processor of any NIS data? [ ] Yes [ ] No + +SECTION C — SECURITY CONTROLS + +8. Does the supplier have a documented information security policy? [ ] Yes [ ] No +9. Are background checks performed on staff with NIS access? [ ] Yes [ ] No +10. Is MFA required for remote access? [ ] Yes [ ] No +11. Are systems with NIS access regularly patched? [ ] Yes [ ] No +12. Does the supplier conduct annual security testing? [ ] Yes [ ] No +13. Does the supplier have an incident response plan? [ ] Yes [ ] No + +SECTION D — INCIDENT REPORTING + +14. Does the supplier commit to notifying [ORGANISATION NAME] of any security + incident affecting systems that connect with or process NIS data within + [24 / 48 / 72] hours? [ ] Yes [ ] No +15. Contact details for incident notification: + +SECTION E — CONTRACTUAL + +16. Is there a Data Processing Agreement (DPA) in place? [ ] Yes [ ] No +17. Are NIS security requirements included in the contract? [ ] Yes [ ] No + +Assessment Outcome: + [ ] Approved [ ] Approved with conditions [ ] Not approved + +Conditions (if applicable): + +Signed: _______________________ Date: ___________ +[ASSESSOR NAME, ROLE] +``` + +--- + +## Template 5 — Incident Response Plan (NIS) + +``` +[ORGANISATION NAME] +INCIDENT RESPONSE PLAN — NIS + +Version: [e.g., 1.0] +Date: [YYYY-MM-DD] +Owner: [ROLE] +Last Tested: [YYYY-MM-DD] +Test Method: [e.g., Tabletop exercise] + +NIS Reference: Regulation 11 / Regulation 13 +CAF Reference: D1 — Response and Recovery Planning + +--- + +1. PURPOSE + +This Incident Response Plan (IRP) defines [ORGANISATION NAME]'s procedures for +detecting, responding to, containing, and recovering from cyber security +incidents affecting NIS used to provide [essential service / digital service]. + +2. SCOPE + +In scope: All NIS as defined in the NIS Asset Register [reference]. +Out of scope: Incidents affecting systems not connected to or supporting NIS. + +3. INCIDENT RESPONSE TEAM + +| Role | Responsibility | Primary Contact | Backup Contact | +|------|---------------|----------------|----------------| +| Incident Commander | Overall coordination | [NAME] [TEL] | [NAME] [TEL] | +| Technical Lead | Technical investigation | [NAME] [TEL] | [NAME] [TEL] | +| Communications Lead | Internal/external comms | [NAME] [TEL] | [NAME] [TEL] | +| Legal/Compliance | Regulatory notifications | [NAME] [TEL] | [NAME] [TEL] | + +4. EXTERNAL CONTACTS + +| Organisation | Role | Contact | +|-------------|------|---------| +| [Competent Authority name] | NIS notification | [email / phone] | +| NCSC | Technical assistance | report.ncsc.gov.uk / 0800 169 4192 | +| ICO (if personal data) | GDPR notification | 0303 123 1113 | +| Action Fraud | Fraud / crime report | 0300 123 2040 | +| [Cyber incident response firm] | External IR support | [contact] | + +5. INCIDENT RESPONSE PHASES + +PHASE 1 — DETECTION AND TRIAGE (0-2 hours) +- Receive alert / report +- Assess: Is this a NIS-affecting incident? +- Activate Incident Response Team +- Begin incident log + +PHASE 2 — CONTAINMENT (2-12 hours) +- Isolate affected systems (without destroying evidence where possible) +- Preserve forensic evidence (system images, logs) +- Assess impact on essential service / digital service continuity +- Determine if significant / substantial impact threshold is met + +PHASE 3 — NIS NOTIFICATION ASSESSMENT (within 72 hours) +- If significant/substantial impact: notify Competent Authority (template in + references/incident-reporting.md) +- Notify NCSC +- Assess UK GDPR notification requirement +- Internal leadership notification + +PHASE 4 — ERADICATION AND RECOVERY +- Remove malware / close attack vector +- Restore from clean backups +- Confirm systems are clean before reconnecting +- Restore essential service + +PHASE 5 — POST-INCIDENT (within 30 days) +- Conduct post-incident review +- Document root cause analysis +- Update risk register +- Implement lessons learned +- Submit final NIS notification update to Competent Authority + +6. INCIDENT SEVERITY LEVELS + +| Level | Description | Response Time | +|-------|-------------|---------------| +| P1 — Critical | Essential service fully disrupted or under active attack | Immediate (within 1 hour) | +| P2 — High | Partial service impact or confirmed compromise | Within 4 hours | +| P3 — Medium | Potential compromise; investigation required | Within 24 hours | +| P4 — Low | Security event; no confirmed impact | Within 72 hours | + +7. TESTING SCHEDULE + +This IRP is tested [ANNUALLY] via: + [ ] Tabletop exercise + [ ] Live simulation / red team + [ ] Full recovery test (DR) + +Next test date: [YYYY-MM-DD] +Last test findings: [Summary] + +Signed: _______________________ Date: ___________ +[NAME, ROLE] +``` + +--- + +## Template 6 — CAF Self-Assessment Record + +``` +[ORGANISATION NAME] +CAF SELF-ASSESSMENT RECORD + +Version: [e.g., 1.0] +Assessment Date: [YYYY-MM-DD] +Assessor(s): [NAMES, ROLES] +System/Service: [Name of NIS being assessed] + +-------------------------------------------------------------- +CAF OBJECTIVE A — MANAGING SECURITY RISK + +A1 — Governance +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence reviewed: +Gaps identified: +Actions required: +Target date: + +A2 — Risk Management +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence reviewed: +Gaps identified: +Actions required: +Target date: + +A3 — Asset Management +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence reviewed: +Gaps identified: +Actions required: +Target date: + +A4 — Supply Chain +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence reviewed: +Gaps identified: +Actions required: +Target date: + +-------------------------------------------------------------- +CAF OBJECTIVE B — PROTECTING AGAINST CYBER ATTACK + +B1 — Service Protection Policies and Processes +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +B2 — Identity and Access Control +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +B3 — Data Security +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +B4 — System Security +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +B5 — Resilient Networks and Systems +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +B6 — Staff Awareness and Training +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +-------------------------------------------------------------- +CAF OBJECTIVE C — DETECTING CYBER SECURITY EVENTS + +C1 — Security Monitoring +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +C2 — Proactive Security Event Discovery +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +-------------------------------------------------------------- +CAF OBJECTIVE D — MINIMISING IMPACT OF INCIDENTS + +D1 — Response and Recovery Planning +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +D2 — Improvements +Rating: [ ] Achieved [ ] Partially Achieved [ ] Not Achieved [ ] N/A +Evidence: Gaps: Actions: Target: + +-------------------------------------------------------------- +OVERALL ASSESSMENT SUMMARY + +| Objective | A1 | A2 | A3 | A4 | B1 | B2 | B3 | B4 | B5 | B6 | C1 | C2 | D1 | D2 | +|-----------|----|----|----|----|----|----|----|----|----|----|----|----|----|----| +| Rating | | | | | | | | | | | | | | | + +Overall Compliance Posture: [ ] Strong [ ] Developing [ ] Requires significant improvement + +Signed: _______________________ Date: ___________ +[NAME, ROLE] +``` + +--- + +## Template 7 — Business Continuity Plan (NIS) + +``` +[ORGANISATION NAME] +BUSINESS CONTINUITY PLAN — NIS SERVICES + +Version: [e.g., 1.0] +Date: [YYYY-MM-DD] +Owner: [ROLE] + +NIS Reference: Regulation 10/12 +CAF Reference: B5, D1 + +--- + +1. CRITICAL SERVICE DESCRIPTION + +Service: [Name and description of essential/digital service] +Maximum Tolerable Downtime (MTD): [e.g., 4 hours] +Recovery Time Objective (RTO): [e.g., 2 hours] +Recovery Point Objective (RPO): [e.g., 1 hour] + +2. CRITICAL NIS COMPONENTS + +| Component | RTO | RPO | Backup Method | Location | +|-----------|-----|-----|--------------|----------| +| [System 1] | [x hrs] | [x hrs] | [e.g., Nightly encrypted backup] | [Location] | +| [System 2] | ... | ... | ... | ... | + +3. BACKUP PROCEDURES + +Backup Schedule: [e.g., Full weekly, incremental daily] +Backup Storage: [e.g., Offsite encrypted, Cloud (provider name)] +Backup Testing: [e.g., Monthly restore test] +Last Successful Restore Test: [YYYY-MM-DD] + +4. RECOVERY PROCEDURES + +Step 1: Invoke BCP — authorisation by [ROLE] +Step 2: Assess scope of failure +Step 3: Invoke failover / alternate processing +Step 4: Restore from clean backup +Step 5: Test restored systems before reconnecting to NIS +Step 6: Resume essential service +Step 7: Notify Competent Authority of resolution (if NIS incident notified) + +5. BCP TESTING + +Test Type: [e.g., Failover test / tabletop] +Test Frequency: [e.g., Annually] +Next Test Date: [YYYY-MM-DD] +Last Test Result: [Pass / Partial / Fail — notes] + +Signed: _______________________ Date: ___________ +[NAME, ROLE] +``` 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..a64f060 100644 --- a/tests/test_plugin_structure.py +++ b/tests/test_plugin_structure.py @@ -36,12 +36,26 @@ "fedramp", "gdpr-compliance", "hipaa-compliance", + "iso13485", + "hitrust", + "iso22301", "iso27001", + "iso27701", + "iso27017", + "iso27018", + "iso31000", "iso42001", + "iso9001", "nist-csf", - "pci-compliance", + "pci-dss", + "soc", "soc2", "tsa-compliance", + "uk-nis", + "govramp", + "eu-ai-act", + "cmmc", + "uk-nis-csrb", } REQUIRED_PLUGIN_JSON_FIELDS = {"name", "version", "description"} @@ -186,7 +200,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..1af94c8 100644 --- a/tests/test_skill_installability.py +++ b/tests/test_skill_installability.py @@ -179,20 +179,34 @@ 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", + "iso27701.skill", + "iso27017.skill", + "iso27018.skill", + "iso31000.skill", "ISO-42001.skill", + "ISO-9001.skill", "NIST Cybersecurity.skill", - "PCI-Compliance.skill", + "PCI-DSS.skill", + "soc.skill", "soc2.skill", "TSA-Compliance.skill", + "uk-nis.skill", + "cmmc.skill", + "uk-nis-csrb.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, (