Review ISO 27001 procedure documents in: $ARGUMENTS
Reviews ISO 27001 procedure documents for compliance gaps and transforms them into standardized formats.
/plugin marketplace add Cloud-Officer/claude-code-plugin-iso/plugin install cloud-officer-co-iso@Cloud-Officer/claude-code-plugin-isoReview ISO 27001 procedure documents in: $ARGUMENTS
When asked to review a folder, identify and categorize files as follows:
| File Type | Identification | Purpose |
|---|---|---|
| Procedure Document | Markdown file with "Procedure" in the filename | Primary document to review and transform. Apply all review guidelines to this file. |
| Control Reference Files | Markdown files with "control" in the filename (e.g., iso27001-control-5.9.md) | ISO 27002:2022 guidance excerpts. Use these to validate that the procedure adequately covers each control's requirements. Do NOT review or transform these files. |
| Legacy Procedure PDFs | PDF files in the folder | Previous standalone procedures that have been consolidated into the main procedure document. These contain operational details that may be missing from the consolidated procedure. |
Review Workflow:
Important: Do NOT output notes explaining that control files or PDFs are "reference material" or "not requiring review." This is understood. Focus the review output entirely on the procedure document.
If no markdown file with "Procedure" in the filename exists in the folder:
Construction Workflow:
[Topic]-Procedure.md (e.g., Asset-Management-Procedure.md)If the procedure document exists but is missing required sections or control coverage:
Identify missing sections by comparing:
Construct missing sections using this approach:
| Source | How to Use |
|---|---|
| Control Reference Files | Extract Purpose, transform "should" → "shall", address all guidance elements |
| Legacy PDFs | Extract specific frequencies, thresholds, checklists, role assignments |
| Organizational Context | Apply small org principles — simplify roles, reduce approval layers |
# [Section Title Based on Control]
[Introductory sentence linking to control objective]
The [Role] shall [action] as specified in the following table:
| Requirement | Frequency | Responsible | Verification |
|-------------|-----------|-------------|--------------|
| [From control guidance + PDF details] | [From PDF or reasonable default] | [Appropriate role] | [How to verify] |
[Additional procedural statements as needed]
When constructing new content:
[TBD: specify X] placeholdersWhen constructing new content, present it as:
## Proposed New Section: [Section Name]
**Sources used:**
- Control: [control ID and title]
- PDF: [filename and relevant sections]
**Proposed content:**
[The constructed section content]
---
Confirm to add this section to the procedure, or provide feedback for revisions.
Apply the principle of minimal necessary intervention:
Template Variables:
Text containing {{...}} syntax (e.g., {{tenant.subdomain}}, {{company.name}}) represents template variables that will be replaced by a templating engine. Do NOT flag these as:
Examples of valid template usage (do not flag):
[isms@{{tenant.subdomain}}.com](mailto:isms@{{tenant.subdomain}}.com){{organization.legal_name}}Contact: {{contact.email}}This review targets procedures for a small organization (under 50 employees). Apply the following principles:
| Principle | Application |
|---|---|
| Role Consolidation | Accept that one person may hold multiple roles (e.g., CISO also performs IT Admin functions). Document compensating controls for segregation of duties where needed. |
| Process Simplicity | Avoid multi-layer approval chains. Single approval authority is acceptable for most controls. |
| Documentation Proportionality | Favor concise requirements over exhaustive procedures. If a control can be stated in one sentence, do not expand to a paragraph. |
| Practical Implementation | Remove or simplify requirements that assume dedicated teams (e.g., "the security operations center shall..."). Adapt to reality of small teams. |
| Tool Agnosticism | Avoid prescribing enterprise tools. Use generic terms (e.g., "ticket system" not "ServiceNow"). |
When reviewing, actively remove:
Acceptable simplifications:
The Scope section shall be validated against the document body:
| Validation | Action Required |
|---|---|
| Coverage Alignment | Verify all topics mentioned in scope are addressed in the procedure body. Flag any scope items with no corresponding content. |
| Exclusion Clarity | If exclusions are stated, verify they are specific and justified |
| Organizational Applicability | Verify scope defines who/what is covered (departments, systems, personnel, locations) |
| Boundary Definition | Verify scope clearly delineates what is in/out of scope for this procedure |
Flag for review if:
The References section shall be audited for accuracy and relevance:
| Check | Requirement |
|---|---|
| Standard Currency | All referenced ISO standards shall use current version numbers (e.g., ISO 27001:2022, not ISO 27001:2013) |
| Internal References | All referenced internal documents shall exist and use correct document IDs |
| Relevance | Each reference shall be cited or applicable within the document body |
| Completeness | Any standard or document cited in the body shall appear in References |
Common standards with official titles:
| Standard | Official Title |
|---|---|
| ISO/IEC 27001:2022 | Information security, cybersecurity and privacy protection — Information security management systems — Requirements |
| ISO/IEC 27002:2022 | Information security, cybersecurity and privacy protection — Information security controls |
| ISO/IEC 27005:2022 | Information security, cybersecurity and privacy protection — Guidance on managing information security risks |
| ISO/IEC 27701:2019 | Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management |
| CIS Controls v8.1 | CIS Critical Security Controls Version 8.1 |
The Terms and Definitions section shall be validated for completeness and consistency:
Step 1: Extract all acronyms and specialized terms from document body
Step 2: Cross-reference against definitions table
| Validation | Action |
|---|---|
| Missing Definitions | Any acronym or specialized term used in the body without definition shall be added to the table |
| Orphaned Definitions | Any term defined but never used in the document shall be flagged for removal |
| First-Use Expansion | Verify acronyms are expanded on first use in body text (e.g., "Information Security Management System (ISMS)") |
| Consistency | Verify acronym usage is consistent throughout (no switching between "ISMS" and "Information Security Management System" after first use) |
| Alphabetical Order | Terms shall be listed alphabetically |
Apply the following language quality checks with minimal rewriting:
| Issue Type | Action |
|---|---|
| Spelling Errors | Correct without changing surrounding text |
| Grammar Errors | Correct the specific error only |
| Awkward Phrasing | Rewrite only if meaning is unclear; otherwise leave as-is |
| Passive Voice | Convert to active voice only when it improves clarity or enables "shall" construction |
| Ambiguous Pronouns | Replace unclear "it/they/this" with specific nouns |
| Run-on Sentences | Split only if comprehension is impaired |
| Dash Standardization | Replace en dashes (–) and double hyphens (--) with em dashes (—) when used as punctuation. Do NOT change: regular hyphens (-) in Markdown lists, hyphenated words (e.g., "risk-based"), or number ranges (e.g., "10-15"). |
Do NOT change:
All procedures shall follow this standard structure for front matter sections:
Purpose Section:
# Purpose
This procedure addresses [brief description]. Specifically, it covers the following ISO 27001:2022 controls:
| Control | Title | Key Areas Addressed |
|---------|-------|---------------------|
| **5.X** | Control Title | Brief description of key areas |
By providing a comprehensive framework through these controls, this procedure aims to [objectives].
Scope Section:
# Scope
This procedure applies to [applicability statement in prose form, not bullets]. It encompasses [coverage description].
[Optional: exclusions or additional applicability notes in prose]
References Section:
# References
The following documents were referred to in the creation of this procedure:
| Number | Title |
|--------|-------|
| ISO/IEC 27001:2022 | [Title] |
Terms and Definitions Section:
The Terms and Definitions section shall begin with the exact sentence: "The terms and definitions used in this document are as set forth in the references below, as applicable:"
# Terms and Definitions
The terms and definitions used in this document are as set forth in the references below, as applicable:
| Term | Definition |
|------|------------|
| ABC | Definition |
See also ISO/IEC 27002:2022 section 3 for additional terms and definitions.
Transform descriptive language to formal procedural tone:
| Original Pattern | Transformed Pattern |
|---|---|
| "should be" | "shall be" |
| "will" (future intent) | "shall" |
| "needs to" / "must" | "shall" |
| "is responsible for" | "shall be responsible for" |
| "are expected to" | "shall" |
| Passive descriptions | Active "shall" statements with clear actor |
Format: "[Actor] shall [action] [object] [conditions/frequency if applicable]."
Examples:
| Guideline | Requirement |
|---|---|
| Heading Depth | Maximum 3 levels: # Main, ## Section, ### Subsection (use sparingly) |
| Front Matter Headings | Purpose, Scope, References, and Terms and Definitions shall use # level headings |
| Main Content Headings | Major procedure sections (e.g., "Asset Inventory Management", "Access Control") shall use # level headings, with subsections at ## |
| Section Length | Sections with fewer than 3 sentences should be consolidated with related content |
| Redundant Headings | Remove sub-headings that merely repeat the parent heading concept |
| Logical Flow | Sections shall follow: Purpose → Requirements → Implementation → Verification |
Convert to tables when content has:
Table Introduction Requirement: Every table shall be preceded by an introductory sentence in the format: "The [organization/role] shall [action] as specified in the following table:"
Table Format Standards:
For Roles and Responsibilities:
| Role | Responsibilities | Authority/Decisions | Reporting Requirements |
|---|
For Processes/Procedures:
| Phase/Step | Requirements | Responsible Party | Timeline/Frequency | Outputs |
|---|
For Controls/Requirements:
| Control | Description | Implementation Requirements | Verification Method |
|---|
For Compliance/Audit Activities:
| Activity | Frequency | Participants | Inputs | Outputs/Deliverables |
|---|
| Pattern to Identify | Consolidation Action |
|---|---|
| Multiple sections covering same role | Merge into single comprehensive role table |
| "Before/During/After" split sections | Combine into single process table with phase column |
| Scattered references to same control | Consolidate under single control heading |
| Repeated compliance requirements | Extract to single compliance section with cross-references |
If the procedure covers specific Annex A controls, verify:
| Validation | Requirement |
|---|---|
| Control Reference Accuracy | Control numbers shall match ISO 27001:2022 Annex A numbering |
| Control Coverage | All controls listed in Purpose/Scope shall have corresponding procedural content |
| Control Intent | Procedural requirements shall address the control objective, not just the control title |
For each control covered by the procedure, validate against ISO/IEC 27002:2022 implementation guidance:
| Validation | Requirement |
|---|---|
| Guidance Coverage | Verify the procedure addresses all "should" statements from ISO 27002 guidance for each control, or documents justified exclusions |
| Purpose Alignment | Verify procedural requirements fulfill the stated Purpose of the control in ISO 27002 |
| Attribute Consideration | Verify the procedure addresses relevant control attributes (Preventive/Detective/Corrective, Confidentiality/Integrity/Availability) |
| Other Information | Review ISO 27002 "Other information" section for each control to ensure no critical considerations are missed |
For each control, document:
| Control ID | ISO 27002 Guidance Elements | Procedure Coverage | Gaps/Exclusions |
|---|---|---|---|
| A.5.1 | Element 1, Element 2, Element 3 | Covered / Partial / Missing | Justification if excluded |
Flag for review if:
For each major procedural requirement, verify:
After all transformations, verify:
markdownlint validation using the settings defined in .markdownlint.ymlThe following markdownlint rules shall be enforced. Do NOT produce content that violates these rules:
| Rule | Requirement |
|---|---|
| MD032 | Always include a blank line before and after lists. |
| MD036 | Never use bold/emphasis (**text**) as a standalone paragraph to simulate a heading. Use proper heading syntax (#, ##, ###, ####) instead. |
| MD047 | Files shall end with a single newline character. |
| MD060 | Table columns shall be properly aligned—all pipes in each row shall align with the header row. Use an editor's table formatting feature to ensure alignment. |
Pre-submission check: Before presenting the transformed document, verify it would pass markdownlint validation.
Provide review results as a structured response (not a new file) with the following sections in this exact order:
Brief overview (2-4 sentences) of document state. End with counts: "Found: X critical, Y recommendations, Z observations."
For each control listed in the procedure's Purpose section, provide a coverage assessment using this compact format:
| Ctrl | Coverage | Gaps |
|-------|------------|------|
| 5.X | ✅ Full | None |
| 5.Y | ⚠️ Partial | Brief note on what's missing |
| 5.Z | ❌ Missing | Element not addressed |
Keep the "Gaps" column concise (under 150 characters). If more detail is needed, add it in the Change Log.
If PDF files exist in the folder, perform a detailed section-by-section comparison against the procedure document:
| ID | PDF / Section | Content (≤150 chars) | Status | Action |
|---|---|---|---|---|
| P01 | file — Sec X | Specific detail from PDF | No | Incorporate |
| P02 | file — Sec Y | Another detail | Partial | Incorporate |
| P03 | file — Sec Z | Detail already in procedure | Yes | Not needed |
Column constraints: Keep "Content" under 150 characters. Truncate with "..." if needed; full detail goes in Change Log.
What to look for in each PDF:
Do NOT dismiss PDF content as "Not needed" simply because:
Only mark "Not needed" when:
Before adding ANY item to the Change Log, you MUST:
Do NOT add findings based on:
Every finding must be traceable to actual text in the document. If you cannot quote the problematic text, the finding is not valid.
This is the primary deliverable. ALL findings shall be in this single table—do NOT create separate Critical/Recommendations/Observations sections.
| ID | Severity | Location | Actual Text (≤80 chars) | Issue (≤100 chars) | Recommendation (≤100 chars) |
|---|---|---|---|---|---|
| 001 | Crit | Line X | "exact text from document" | Problem description | Specific fix with exact text changes |
| 002 | Rec | Line X | "exact text from document" | Problem description | Specific fix with exact text changes |
| 003 | Obs | Line X | "exact text from document" | Problem description | Specific fix with exact text changes |
Column constraints:
Severity Levels:
Change Log Requirements:
Important: Do NOT create new files or edit the original document. Present findings for human review and approval.
A document passes review and requires no further changes when ALL of the following are true:
| Criterion | Pass Condition |
|---|---|
| ISO 27002 Coverage | All controls show ✅ Full coverage in section 5.2 |
| Legacy PDF Content | All "Incorporate" items from section 5.3 have been addressed, or no incorporation needed |
| Critical Issues | Zero items with "Critical" severity in Change Log |
| Procedural Language | All requirements use "shall" with clear actor |
| References | All standards current, all citations valid |
| Terms | All acronyms defined and used consistently |
| Markdown | Passes markdownlint validation |
When a document passes:
Output only:
## Review Result: PASS
Document meets all compliance criteria. No changes required.
### ISO 27002 Control Coverage
[Include the 5.2 table showing all ✅ Full]
Boundary rules to prevent infinite revisions:
Re-review behavior:
When reviewing a document that was previously reviewed and had fixes applied:
When the user requests fixes to be applied, apply each fix directly to the document file so the user can review the actual diff in their IDE (e.g., RubyMine, VS Code). Do NOT present fixes as large text blocks showing "before" and "after" paragraphs—this makes it impossible to see what actually changed.
Fix Presentation Format:
When explaining a fix before or after applying it, use minimal diff format showing only the changed portion:
**Fix N: Location — Brief Description**
Insert after "...context words...":
+ Added text here
Or for replacements:
- Old text
+ New text
Workflow: