ISO 27001 ISMS Workspace: From Scoping to Certification Readiness in 21 Steps
A practical guide for GRC consultants and in-house security teams on using Rakenne's ISO 27001 ISMS workspace template to build a complete, internally consistent ISMS documentation set — with tool-assisted validation at every step.
Building an ISO 27001-compliant ISMS is documentation-heavy. A first-time certification for a mid-sized company typically takes 6–12 months of consulting effort, with over 60% of the time spent on document production, risk analysis, gap assessment, and cross-referencing requirements against controls. The bottleneck is rarely writing text — it is translating messy real operations into auditable, internally consistent, clause-aligned documentation.
Rakenne’s ISO 27001 ISMS workspace template provides 21 specialized skills and over 60 validation tools that guide an LLM agent through the entire PDCA cycle. Each skill enforces a structured workflow, loads ISO-specific references, and uses deterministic tools to check the agent’s output — catching the kinds of errors that plain LLM drafting misses: missing mandatory clauses, inconsistent risk scores, orphaned controls, incomplete CAPA records, and cross-document inconsistencies where one artifact contradicts another.
This guide walks through all 21 skills in sequence, shows real dialog excerpts and tool outputs from a live session, and explains what makes tool-assisted ISMS documentation materially better than generic AI drafting.
Why plain LLMs fall short for ISO 27001
A plain LLM like ChatGPT can draft policies, procedures, and risk statements. Where it struggles is compliance-grade validation:
| Concern | Plain LLM | Rakenne with ISO 27001 skills |
|---|---|---|
| Clause completeness | Can miss mandatory requirements | Scans the workspace for mandatory artifacts and flags gaps |
| Risk–control traceability | Weak without structured state | Enforces links between risk register, SoA, and treatment plan |
| Cross-document consistency | Contradictions across documents go unnoticed | 11 cross-document traceability checks detect inconsistencies across all ISMS artifacts — from scope to policies to CAPA log |
| Repeatable process | Output varies with prompt phrasing | Each skill defines a fixed workflow; same checks run every time |
| Self-correction | Model may claim coverage without delivering it | Validation tools return PASS/FAIL; the agent revises until checks pass |
The difference is structural: skills give the agent a spec (workflow + references + structure) and tools (deterministic checks) to verify its own output. This is what turns a draft into an auditable artifact.
The 21-step ISMS journey
The workspace template installs 21 skills that map to the ISO 27001 PDCA cycle:
| Phase | Step | Skill | What gets validated |
|---|---|---|---|
| Plan | 1 | Organization Profile | Tech stack classification, profile completeness |
| Plan | 2 | ISMS Scope | Scope boundary integrity, exclusion justifications, downstream impact analysis |
| Plan | 3 | Asset Inventory | Asset labeling consistency, owner accountability |
| Plan | 4 | Risk Assessment | Methodology compliance, risk entry completeness, duplicate detection, risk-to-control mapping, residual risk thresholds, asset-risk coverage |
| Plan | 5 | Statement of Applicability | Control inclusion suggestions, justification audit, SoA-to-risk consistency, policy evidence validation, implementation status tracking |
| Plan | 6 | Gap Assessment | Mandatory artifact detection, clause requirement coverage, maturity rating, remediation prioritization, ISMS traceability dashboard |
| Do | 7 | Policy Generator | Template selection, document metadata, mandatory topic coverage, treatment-to-policy traceability (now 16 document types) |
| Do | 8 | Physical Security Perimeter | Tailgating prevention controls |
| Do | 9 | Supplier Security Policy | Tier-based clause generation, right-to-audit enforcement |
| Do | 10 | Legal Requirements Register | Legal/regulatory obligation tracking, control mapping, coverage gap analysis |
| Do | 11 | Confidentiality/NDA Agreements | NDA clause validation, personnel category coverage, agreement tracking |
| Do | 12 | HR & Personnel Security | Employment clause completeness, exit procedure coverage |
| Do | 13 | Privacy & PII Protection Program | ROPA completeness, legal basis validation, breach notification timelines |
| Do | 14 | Operating Procedures (SOPs) | SOP completeness validation, control-to-SOP coverage analysis |
| Do | 15 | Secure Architecture Principles | Architecture category coverage, implementation guidance validation |
| Do | 16 | Awareness & Training Plan | Training audience coverage, module completeness, effectiveness metrics |
| Check | 17 | Monitoring & Evaluation | IS objectives register, KPI generation, CAPA completeness, corrective action tracking, audit NC-to-CAPA reconciliation |
| Do | 18 | Business Continuity Plan | BIA-driven RTO/RPO validation, DR procedure coverage, exercise record completeness |
| Check | 19 | Internal Audit Report | Auditor impartiality, finding completeness, severity classification |
| Act | 20 | Management Review | Mandatory input coverage, input pack compilation, action item completeness |
| Act | 21 | Executive Readiness Report | Board-ready compliance summary, readiness scoring, gap prioritization |
Each skill reads workspace files produced by earlier steps — the organization profile feeds into scoping, scoping feeds into risk assessment, risk assessment feeds into the SoA, and so on. The entire chain is traceable.
Step 1: Organization Profile — the foundation everything else reads
Every ISO 27001 engagement starts with understanding the organization. The Organization Profile skill captures structured facts — entity name, size, locations, tech stack, regulatory obligations, key personnel — into a reusable profile file.
You: CloudSync Solutions is a B2B SaaS company based in São Paulo, 45 employees. We run on GCP, use GitHub, Google Workspace, Okta for IAM, Stripe for payments, and SendGrid for email. Maria Santos is CISO, João Silva is CTO. We handle customer project data and are subject to LGPD.
Agent: I’ve drafted the organization profile. Let me run the tech stack classifier and the profile completeness checker.
The tech stack classifier categorized 8 entries: GCP as IaaS, GitHub as SaaS (DevOps), Google Workspace as SaaS (Productivity), Okta as SaaS (Security/IAM). One flag — AWS CloudFront is listed without region specification.
Profile completeness: PASS (92%). Minor gap: revenue band is estimated — consider confirming with finance.
I’ve also updated the project dashboard to mark the Organization Profile as complete.
Step 2: ISMS Scope — drawing defensible boundaries
The ISMS Scope skill defines which parts of the organization, processes, locations, and systems are in scope for certification — and, critically, justifies any exclusions. It reads the organization profile and produces a scope statement that auditors can trace back to Clause 4.3.
You: Define the ISMS scope for CloudSync Solutions. Our SaaS platform and supporting infrastructure should be in scope. Marketing and HR systems are out of scope.
Agent: I’ve drafted the scope statement based on your organization profile. Let me run the scope boundary and exclusion checks.
Scope boundary integrity: PASS. The scope covers the SaaS platform, GCP infrastructure, customer data processing, and all supporting IT services. Boundaries are clearly defined by organizational unit, location (São Paulo HQ + GCP regions), and technology.
Exclusion justification check: WARNING. Two exclusions need stronger justification. “Marketing systems” is accepted — no customer data processed. But “HR systems” needs clarification: HR holds employee PII subject to LGPD, and Clause 4.3 requires justifying why HR data handling doesn’t affect ISMS objectives. I’ve flagged this for your review and suggested adding a sentence explaining that HR data is governed under a separate LGPD compliance program.
The scope statement becomes the anchor for every subsequent step — risk assessment only covers in-scope assets, the SoA only addresses in-scope controls, and the gap assessment checks coverage against the defined boundaries.
When the scope changes later in the engagement (a new office opens, a cloud provider is added), the scope change impact analyzer scans all downstream documents — asset inventory, risk register, SoA, and policies — and flags inconsistencies. For example, if you exclude “Tokyo office” from scope but the asset inventory still lists a “Tokyo Office File Server”, the tool catches it immediately.
Step 3: Asset Inventory — what you protect must be named
Before assessing risks, the ISMS needs a complete inventory of information assets. The Asset Inventory skill catalogs assets by type (information, software, hardware, services, people), assigns owners, and validates labeling consistency.
You: Build the asset inventory based on our organization profile and scope.
Agent: I’ve identified 18 information assets within the ISMS scope and classified them by type. Let me validate labeling and ownership.
Asset labeling consistency: PASS. All 18 assets follow the naming convention (type prefix + sequential ID). Classification levels (Confidential, Internal, Public) are assigned consistently — customer project data and API keys are Confidential, internal documentation is Internal.
Owner accountability check: WARNING. Two assets have team-level owners (“Engineering Team”) instead of named individuals. ISO 27001 Clause A.5.9 requires identifiable owners. I’ve flagged AST-011 (CI/CD Pipeline) and AST-014 (Monitoring Dashboard) for reassignment to specific individuals.
The asset inventory feeds directly into the risk assessment — every risk must reference a specific asset, and orphaned assets (assets with no associated risks) are flagged for review.
Step 4: Risk Assessment — where validation earns its keep
Risk assessment (Clause 6.1.2) is where tool-assisted validation makes the biggest difference. A plain LLM can list risks, but it cannot reliably check that every risk has a proper threat–vulnerability–consequence chain, that scores follow the defined methodology, or that treatment decisions map to actual Annex A controls.
The Risk Assessment skill activates six checks in sequence:
- Methodology compliance — validates that likelihood/impact scales, a scoring matrix, and acceptance criteria are all defined per Clause 6.1.2
- Risk entry completeness — checks each risk has asset, threat, vulnerability, consequence, scores, owner, and treatment decision
- Duplicate detection — identifies overlapping or near-duplicate risks
- Asset-risk coverage — cross-checks the asset inventory against the risk register to verify that Confidential and Restricted assets have corresponding risk entries
- Risk-to-control mapping — ensures every treated risk links to specific Annex A controls
- Residual risk threshold — verifies post-treatment scores fall below the acceptance criteria
You: Based on the organization profile and scope, assess our information security risks.
Agent: I’ve identified 7 risks and built the risk register with likelihood × impact scoring. Let me run the validation suite.
The methodology checker confirmed all 11 Clause 6.1.2 requirements are met — scales, matrix, and acceptance threshold of 12 are properly defined.
Each of the 7 risk entries passed completeness validation: asset, threat, vulnerability, consequence, L×I scores, owner, and treatment decision are all present.
The duplicate detector found no overlapping risks — all 7 address distinct threat scenarios.
The asset-risk coverage validator cross-checked the asset inventory: 5 of 6 Confidential assets have corresponding risk entries. However, AST-008 (API Keys vault) is classified Confidential but has no risk entry — I’ve added R-08 covering unauthorized key extraction with a score of 4×5=20 (Treat, controls A.5.17, A.8.24).
The risk-to-control mapper verified that all 8 treated risks link to specific Annex A controls. And the residual risk checker confirmed all post-treatment scores fall below the acceptance threshold of 12.
Here’s a sample from the risk register the agent produced:
| ID | Asset | Threat | L | I | Score | Treatment | Controls |
|---|---|---|---|---|---|---|---|
| R-01 | Customer Project Data | Unauthorized access | 3 | 5 | 15 | Treat | A.5.15, A.5.18 |
| R-02 | Cloud Infrastructure | Misconfiguration | 4 | 4 | 16 | Treat | A.8.20, A.8.21 |
| R-06 | SaaS Platform | API vulnerabilities | 4 | 5 | 20 | Treat | A.8.25, A.8.26 |
Without these tools, the agent could produce a plausible-looking risk register with misaligned scores, orphaned treatments, or controls that don’t actually address the identified threat. The tools enforce the same logical checks a senior consultant would apply — automatically and consistently.
Step 5: Statement of Applicability — the bridge between risks and controls
The Statement of Applicability (SoA) is one of the most audited documents in ISO 27001. It lists all 93 Annex A controls and states which are applicable, which are excluded, and why. The SoA skill cross-references the risk register to suggest control inclusions, checks that every justification is traceable, and tracks implementation status for each control through its lifecycle.
You: Generate the Statement of Applicability based on our risk assessment. Include implementation status tracking.
Agent: I’ve mapped all 93 Annex A controls against the risk register and organization profile. Let me run the SoA validation suite.
Control inclusion suggestions: 78 controls marked as applicable, 15 excluded. The tool flagged 2 controls you might want to reconsider: A.7.4 (Physical security monitoring) — marked as excluded, but your GCP infrastructure includes a physical office with server room access. And A.5.23 (Information security for cloud services) — this should be applicable given your GCP dependency.
Justification audit: PASS. All 15 exclusions have documented justifications referencing specific scope boundaries or organizational context. The audit also flagged 12 controls with evidence but implementation status still “Not Started” — consider updating as you implement.
SoA-to-risk consistency: PASS. Every treated risk in the risk register maps to at least one applicable SoA control, and no applicable control lacks a corresponding risk or business requirement.
Implementation status summary: Not Started: 34, Planned: 28, Implemented: 14, Verified: 2. The consistency checker now tracks this so you can see at a glance how far along your implementation is.
Policy evidence check: The consistency checker also scanned your policy directory. 3 included controls reference evidence files that don’t exist yet — A.5.24 cites “Incident-Management-Procedure.md” but that file hasn’t been generated. I’ve noted this as a reminder for the Policy Generator step.
The SoA includes an optional Implementation status column with four lifecycle values: Not Started, Planned, Implemented, and Verified. This gives auditors a clear view of implementation progress — not just which controls are applicable, but where each one stands. The column is optional; existing SoAs without it continue to work. When populated, all three validation tools report on it: the justification audit flags controls with evidence but stale status, the consistency checker summarizes the distribution, and the evidence index includes the status in its output table.
The SoA becomes a living document — as risks change, the tool can re-check whether control applicability decisions still hold, and the implementation status tracks your progress toward full compliance.
Step 6: Gap Assessment — finding what’s missing
After the first five steps produce foundational artifacts, the Gap Assessment skill reviews the entire workspace to identify what’s still needed for certification.
You: Assess the current state of our ISMS against ISO 27001 requirements.
Agent: I’ve scanned the workspace for mandatory artifacts and rated each clause area for maturity. Here’s what I found.
The mandatory artifact scan produced a traceable checklist — the ISMS scope statement and risk register are present, but the Information Security Policy, Statement of Applicability, and Internal Audit results are still missing.
For clause maturity, I rated Clause 6 (Planning) at level 3 (“Defined”) based on the existing risk methodology and register, while Clause 9 (Performance Evaluation) is at level 0 (“Nonexistent”) since no monitoring, audit, or management review has been performed yet.
Based on audit risk, here’s the remediation priority:
- Immediate — Information Security Policy (Clause 5.2), scope exclusion justifications
- Short-term — Statement of Applicability, Risk Treatment Plan, Security Objectives
- Medium-term — Operational procedures (access control, incident management, supplier security)
- Audit readiness — Internal audit, management review, CAPA process
This is where the PDCA cycle becomes tangible: the gap assessment tells you exactly which subsequent skills to run and in what order.
Step 7: Policy Generator — tailored policies with document control
The Policy Generator skill creates ISO-compliant policies tailored to the organization’s context. It reads the organization profile, risk register, and scope statement to produce policies that reference actual systems, roles, and regulatory requirements — not generic placeholders.
You: Generate the Information Security Policy for CloudSync Solutions.
Agent: I’ve drafted POL-001 based on your organization profile and risk context. Let me validate the document metadata and mandatory topic coverage.
Document metadata check: PASS. Document ID POL-001 has version, owner (Maria Santos), approval (João Silva), effective date, next review date, and classification (Internal) — all present.
Mandatory topic checker: PASS. All required sections are covered — management commitment (5.1), purpose (5.2), roles and responsibilities (5.3), risk management (6.1), compliance requirements, and review schedule.
After generating all 16 policies, I ran the treatment-to-policy traceability check. It cross-referenced 8 “Treat” decisions in the risk treatment plan against the generated policies. 7 of 8 have complete chains — the policy implementing each control exists. One gap: R-06 (API vulnerabilities, controls A.8.25-A.8.26) maps to a Secure Development Procedure, but that hasn’t been generated yet since software development procedures are optional for your scope. I recommend adding it given your SaaS platform is the primary asset.
The skill now produces up to 16 document types, including the core Information Security Policy, Risk Management Policy, Access Control Policy, and newer additions for classification and handling, cryptographic controls, secure development lifecycle, vulnerability management, remote working, and backup and recovery. Each policy is tailored to the organization’s context and cross-referenced against other workspace artifacts.
The generated policy includes:
- Clause-aligned section headers (5.1 Management Commitment, 5.2 Purpose, 5.3 Roles and Responsibilities)
- Organization-specific objectives (“Achieve ISO 27001 certification by Q4 2026”, “LGPD compliance”)
- Named role assignments (“Maria Santos — CISO”, “João Silva — CTO”)
- Cross-references to companion documents (POL-002 Risk Management Policy, asset inventory, SoA)
A plain LLM could draft a generic policy. The skill ensures the policy is internally consistent with every other artifact in the workspace.
Step 8: Physical Security Perimeter — controls beyond the digital
Even cloud-native organizations have physical security concerns — offices, meeting rooms, and network closets. The Physical Security Perimeter skill generates controls tailored to the organization’s physical footprint, with a focus on access control, visitor management, and tailgating prevention.
You: Define physical security controls for our São Paulo office.
Agent: Based on the organization profile, your office has a single location with a server room and open-plan workspace. I’ve drafted the physical security perimeter document with controls for three zones: building entry, office floor, and server room. Let me validate.
Tailgating prevention check: PASS. Controls include badge-only entry at building reception, a visitor sign-in log with escort requirement, and a mantrap entry for the server room with dual-authentication (badge + PIN).
I’ve also cross-referenced these controls with the SoA — A.7.1 (Physical security perimeters), A.7.2 (Physical entry), and A.7.4 (Physical security monitoring) are all addressed.
I’ve also validated off-site security controls (A.7.9) — device encryption, VPN requirements, and MDM enrollment are all addressed for your remote workforce.
Step 9: Supplier Security Policy — managing third-party risk
SaaS companies depend heavily on third-party services. The Supplier Security Policy skill generates tiered security requirements based on each supplier’s data access level and criticality, ensuring right-to-audit clauses and data processing agreements are in place.
You: Create the supplier security policy based on our tech stack and risk assessment.
Agent: I’ve classified your 8 suppliers into three tiers based on data access and criticality. Let me validate the policy.
Tier classification:
- Tier 1 (Critical): GCP (IaaS — hosts all customer data), Okta (IAM — controls authentication)
- Tier 2 (Important): GitHub (source code), Stripe (payment processing), Google Workspace (internal comms)
- Tier 3 (Standard): SendGrid (email delivery), CloudFront (CDN), monitoring tools
Tier-based clause generation: PASS. Tier 1 suppliers require annual SOC 2 Type II reports, right-to-audit clauses, incident notification within 24 hours, and data residency guarantees. Tier 2 suppliers require SOC 2 or ISO 27001 evidence and 48-hour incident notification. Tier 3 suppliers require basic security questionnaires.
Right-to-audit enforcement: PASS. All Tier 1 and Tier 2 supplier clauses include contractual right-to-audit provisions per A.5.19 and A.5.21.
Step 10: Legal Requirements Register — tracking obligations
The Legal Requirements Register skill identifies and catalogs legal, statutory, regulatory, and contractual obligations relevant to the ISMS per Annex A control A.5.31. It reads the organization profile and scope to surface applicable requirements, maps each obligation to specific controls, and checks for coverage gaps.
You: Build the legal requirements register for CloudSync Solutions.
Agent: Based on the organization profile, I’ve identified 12 legal and contractual obligations. Let me validate the register.
The regulatory coverage analyzer found obligations across three categories: statutory (LGPD data protection, Marco Civil da Internet), regulatory (BACEN cybersecurity requirements from financial-sector clients), and contractual (DPA clauses in enterprise contracts, SLA commitments). All 12 entries have mapped Annex A controls.
Legal requirement completeness check: PASS. Each obligation has a source reference, applicability justification, responsible owner, review frequency, and mapped controls. One advisory: the LGPD entry references “consent-based processing” but the organization profile indicates legitimate interest as the primary legal basis — consider aligning these.
Step 11: Confidentiality/NDA Agreements — protecting information through contracts
The Confidentiality/NDA Agreements skill creates NDA templates and a tracking register per Annex A control A.6.6. It generates agreement templates tailored to different personnel categories — employees, contractors, and third-party partners — and validates that required clauses are present.
You: Create NDA templates and a tracking register for CloudSync Solutions.
Agent: I’ve drafted NDA templates for three personnel categories: employees, contractors, and third-party partners. Each template is tailored to CloudSync’s context — referencing the LGPD obligations, Confidential asset classifications from the asset inventory, and specific data handling scenarios from the SaaS platform. Let me validate.
NDA clause validator: PASS. All three templates include the 9 mandatory clauses — definition of confidential information, obligations of receiving party, permitted disclosures, term and survival period, return/destruction of information, breach remedies, governing law, jurisdiction, and severability.
NDA register completeness check: WARNING. The tracking register covers 42 of 45 personnel. Three recent contractor onboardings (started in February 2026) do not yet have signed NDAs on record. I’ve flagged these for immediate follow-up with HR.
Step 12: HR & Personnel Security — protecting the employment lifecycle
The HR & Personnel Security skill creates the documentation framework for security controls across the full employment lifecycle — from pre-employment screening through to termination and beyond. It covers ISO 27001 controls A.6.1 (Screening), A.6.2 (Terms and conditions of employment), A.6.4 (Disciplinary process), A.6.5 (Post-termination responsibilities), and A.5.4 (Management responsibilities).
You: Create HR security documentation for CloudSync Solutions. We need screening procedures for new engineering hires, employment contract security clauses, and a complete exit procedure for when employees leave — including access revocation across all our systems.
Agent: I’ve drafted 4 HR security documents based on the organization profile. Let me run the validation tools.
HR clause completeness checker: PASS. The employment security clauses template includes all 5 required elements — NDA/confidentiality reference, acceptable use policy, IP assignment clause, disciplinary consequences for security violations, and post-termination obligations. It also references LGPD data protection obligations and asset return requirements.
Exit procedure coverage validator: PASS. The termination/exit security procedure covers access revocation for all 4 systems identified in the organization profile — Okta (SSO), GCP (infrastructure), GitHub (source code), and Google Workspace (email/docs). The procedure includes asset return checklist, knowledge transfer plan, NDA reminder, and exit interview. One advisory: consider adding a post-departure monitoring period for privileged account holders.
Step 13: Privacy & PII Protection Program — building a comprehensive privacy framework
The Privacy & PII Protection Program skill creates the complete privacy documentation set aligned with ISO 27001 A.5.34 and major privacy regulations. It produces five core documents tailored to the organization’s jurisdiction and data processing activities.
You: Build the privacy program for CloudSync Solutions. We’re subject to LGPD and have EU enterprise clients under GDPR. Create the full set — privacy policy, ROPA, DPIA template, data subject rights procedure, and breach notification procedure.
Agent: I’ve drafted 5 privacy program documents based on the organization profile and legal requirements register. Let me validate.
ROPA completeness checker: PASS. All 5 processing activities (customer data storage, user authentication, payment processing, email communications, analytics) have complete entries — purpose, legal basis, data categories, recipients, retention period, and international transfer status documented for each.
Legal basis validator: PASS with 1 advisory. 4 of 5 processing activities use legitimate interest or contractual necessity as legal basis. The analytics processing uses consent — the tool flagged this for DPIA consideration since consent-based processing of personal data may require a Data Protection Impact Assessment under both GDPR Article 35 and LGPD Article 38.
Breach notification timeline enforcer: PASS. The breach notification procedure includes both LGPD’s “reasonable time” requirement with ANPD notification and GDPR’s 72-hour supervisory authority notification for EU data subjects. Severity classification matrix, containment steps, and post-breach review are all documented.
Step 14: Operating Procedures (SOPs) — documenting how controls work in practice
The Operating Procedures skill creates step-by-step standard operating procedures per Annex A control A.5.37. SOPs translate high-level policies into actionable instructions that operators follow day-to-day. The skill identifies which controls require SOPs, creates an index, and validates each procedure for completeness.
You: Create operating procedures for the controls that need them.
Agent: I ran the SOP coverage analyzer against the Statement of Applicability. Of the 78 applicable controls, 24 require documented operating procedures. 10 are already covered by existing policies. I’ll create the remaining 14 SOPs. Let me start with the highest-priority ones.
I’ve drafted SOP-001 (Access Provisioning and Deprovisioning), SOP-002 (Incident Response Execution), and SOP-003 (Backup and Restoration). Running validation on each…
SOP completeness checker: SOP-001 PASS — includes purpose, scope, roles, step-by-step procedure, escalation criteria, and related controls (A.5.15, A.5.18). SOP-002 PASS — covers all incident severity levels with decision trees. SOP-003 WARNING — restoration steps reference “GCP Console procedure” without specifying exact navigation paths. I’ve expanded the steps with specific GCP commands and console paths. Re-check: PASS.
The SOP index now tracks all 24 required procedures with completion status and last-reviewed dates.
Step 15: Secure Architecture Principles — engineering security in
The Secure Architecture Principles skill documents the organization’s secure engineering principles per Annex A control A.8.27. It produces a principles catalog tailored to the organization’s technology stack, covering all 10 architecture categories defined in the ISO 27001 framework.
You: Document our secure architecture principles based on CloudSync’s tech stack.
Agent: I’ve drafted a secure architecture principles catalog tailored to CloudSync’s GCP-based SaaS platform. The catalog covers 10 categories: network segmentation, authentication and access control, data protection at rest and in transit, secure API design, logging and monitoring, secrets management, container security, infrastructure as code, resilience, and supply chain integrity. Let me validate.
Architecture principles coverage check: PASS. All 10 categories have documented principles with implementation guidance specific to your stack — for example, network segmentation references GCP VPC design with private service access, and secrets management references the existing Okta + GCP Secret Manager integration from the organization profile.
Each principle is cross-referenced to applicable Annex A controls and the relevant policies generated in Step 7.
Step 16: Awareness & Training Plan — building a security culture
The Awareness & Training Plan skill defines training requirements, audience segments, module content, and effectiveness measurement criteria. It ensures all personnel categories — from executives to developers to third-party contractors — have appropriate security awareness coverage, with training modules mapped to specific ISMS controls and organizational risks.
Step 17: Monitoring & Evaluation — measuring what matters
The Monitoring & Evaluation skill generates an IS Objectives Register (Clause 6.2), KPIs aligned to ISMS objectives, tracks corrective actions from audit findings, and ensures the CAPA (Corrective and Preventive Action) process is complete.
You: Set up the monitoring and evaluation framework for our ISMS.
Agent: I’ve built the IS Objectives Register per Clause 6.2 with 6 measurable security objectives, each linked to specific ISMS policies and risk treatment decisions. Let me validate.
Objectives completeness checker: PASS. All 6 objectives have defined metrics, targets, measurement methods, timeframes, and responsible owners. Example: “Reduce mean time to patch critical vulnerabilities to under 72 hours by Q3 2026” — metric: MTTP, target: <72h, source: GitHub security alerts, owner: João Silva.
I’ve also generated 8 KPIs aligned to the ISMS objectives. Let me validate the CAPA tracking.
KPI generation: PASS. Each KPI has a defined metric, target, measurement frequency, data source, and responsible owner. Examples: “Percentage of access reviews completed on schedule” (target: 100%, quarterly, source: Okta audit logs, owner: Maria Santos).
CAPA completeness: WARNING. Two of the three audit findings (Finding 01 and Finding 02) have complete CAPA records — root cause, corrective action, owner, due date, and effectiveness criteria. Finding 03 (backup verification) has root cause and corrective action defined but is missing effectiveness verification criteria. I’ve flagged it for completion.
Audit NC-CAPA reconciliation: The reconciler cross-checked the internal audit report against the CAPA log. All 3 audit NCs (NC-001 through NC-003) have matching CAPA entries. It also checked the monitoring report’s failed controls — the access review metric (72% completion vs. 100% target) was correctly linked to CAPA-001. No orphaned findings.
Corrective action tracking: PASS. All CAPAs have assigned owners and due dates within 90 days of the finding date.
Step 18: Business Continuity Plan — preparing for the worst
The Business Continuity Plan skill creates operationally detailed BCP and disaster recovery documents per Annex A controls A.5.29 and A.5.30. It starts with a Business Impact Analysis (BIA), derives RTO/RPO targets, and produces recovery procedures and exercise records.
You: Create the business continuity plan for CloudSync Solutions.
Agent: I’ve performed a Business Impact Analysis based on the asset inventory and organization profile. The BIA identified 5 critical business processes: SaaS platform availability, customer data processing, payment processing (Stripe), authentication services (Okta), and internal communications (Google Workspace). Let me build the BCP and validate.
I’ve drafted the BCP with recovery procedures for each critical process, plus a separate Disaster Recovery Plan for the GCP infrastructure. Running validation…
BCP RTO/RPO validator: PASS. All 5 critical processes have defined RTO and RPO targets consistent with contractual SLAs. SaaS platform: RTO 4 hours, RPO 1 hour. Payment processing: RTO 2 hours, RPO 0 (real-time replication via Stripe). One advisory: the DR plan references multi-region failover but the organization profile only lists a single GCP region — consider documenting the planned secondary region.
Exercise record checker: WARNING. The exercise log template is complete but no exercises have been conducted yet. I’ve created a schedule for the first tabletop exercise (Q2 2026) and a full DR test (Q3 2026), both with defined success criteria and participant lists.
Step 19: Internal Audit — impartiality and finding validation
The Internal Audit Report skill produces an audit plan, checklist, findings, and severity classifications. What makes it different from plain drafting:
You: Create the internal audit report for our ISMS.
Agent: I’ve drafted the audit plan for March 20–24, 2026 with Carlos Mendes from the Quality Team as lead auditor. Let me run the impartiality check.
Impartiality validation: PASS. Carlos Mendes has no ISMS operational, management, or design responsibilities — independence confirmed.
I’ve completed the audit checklist against all clauses and Annex A controls. Three findings identified:
Finding 01 (Access Review Evidence, A.5.15): Minor Non-conformity. The Access Control Policy requires quarterly reviews, but no Q1 2026 records exist. Root cause: transition to Okta was completed but review workflows weren’t yet scheduled.
Finding 02 (Incident Management Procedure, A.5.24): Minor Non-conformity. PROC-003 is in draft and missing SaaS-specific incident response steps.
Finding 03 (Backup Verification, A.8.13): Major Non-conformity. GCP backups exist but no restoration test logs found. The assumption that managed services handle integrity without manual verification is insufficient.
The audit checklist references actual workspace artifacts:
| Ref | Requirement | Evidence | Status |
|---|---|---|---|
| 4.3 | ISMS scope documented? | isms-scope-statement.md | Pass |
| 6.1 | Risk register exists? | risk-register.md | Pass |
| A.5.15 | Access reviews performed? | No Q1 records found | Fail |
| A.8.13 | Backups verified? | GCP backups exist, no test logs | Fail |
Step 20: Management Review — closing the PDCA loop
The Management Review skill compiles the management review input pack per Clause 9.3, pulling from every artifact produced in earlier steps. The mandatory input checker validates that all 10 required inputs are covered:
- Status of actions from previous reviews
- Changes in external/internal issues
- Nonconformities and corrective actions
- Monitoring and measurement results
- Audit results
- Fulfilment of objectives
- Feedback from interested parties
- Results of risk assessment
- Opportunities for improvement
- Resource needs
You: Compile the management review input pack.
Agent: I’ve compiled the input pack with traceable references to all workspace artifacts. The mandatory input checker confirmed all 10 required Clause 9.3 inputs are covered.
I also validated that every action item in the review has an assigned owner, due date, and acceptance criteria — all checks passed.
Step 21: Executive Readiness Report — the board-level view
The Executive Readiness Report skill generates a board-ready compliance summary that distills the entire ISMS into a concise readiness scorecard. It aggregates data from all upstream artifacts — gap assessment findings, risk treatment coverage, clause maturity ratings, audit results, and CAPA status — into a single document suitable for executive review and certification decision-making. The report includes an overall readiness score, prioritized gap list, and recommended next actions.
Cross-document traceability: the auditor’s perspective
ISO 27001 auditors don’t evaluate documents in isolation — they trace chains. “Show me the risk that led to this control. Show me the policy that implements it. Show me the evidence it’s working.” If one link in the chain breaks, the auditor writes a non-conformity.
Rakenne’s cross-document traceability tools enforce 11 of these links automatically. Each tool runs inside the skill that produces the downstream document, checking it against upstream artifacts. All cross-document parameters are optional — the tools auto-discover documents in the workspace and only check links where both endpoints exist.
Here’s what happens when you run the ISMS traceability dashboard after completing all 21 skills:
You: Run the traceability dashboard to check overall ISMS consistency.
Agent: I’ve scanned the workspace and checked all 11 traceability links. Here are the results.
Implementation Progress:
- Plan phase (Clause 4-6): 6/6 documents complete
- Do phase (Clause 7-8): 16 policies, SOPs, legal register, NDAs, BCP, and architecture principles found
- Check phase (Clause 9): 2/2 documents complete
- Act phase (Clause 10): 3/3 documents complete
Traceability Links: 9 of 11 links are fully consistent. 2 warnings found:
- SoA → Policies: 3 included controls cite evidence files that were modified after the SoA was last updated — the SoA may need a refresh to reflect current policy content.
- Risk Treatment → Policies: R-06 (API vulnerabilities) has treatment “Treat” with controls A.8.25-A.8.26, but the implementing Secure Development Procedure doesn’t exist yet.
Audit readiness: 91% — address 2 warnings before Stage 1.
The traceability dashboard is phase-aware. If you’re midway through implementation — say, Plan phase done but Check and Act not started — the dashboard doesn’t penalize you for missing audit reports. Instead, it reports:
“Plan phase: 6/6 complete, traceability 100%. Do phase: 18/22 documents, 2 warnings. Check phase: not yet started. Act phase: not yet started.”
This gives consultants a clear picture of where the engagement stands and what to work on next — without the demoralizing “25/30 documents missing” that other tools show.
How consistency is spotted and self-corrected
The power of cross-document validation is in the feedback loop. Here is a concrete example of how the agent detects and corrects an inconsistency across three documents:
Agent: I’ve completed the risk register with 8 entries. Running the validation suite…
The asset-risk coverage validator found a gap: AST-008 (API Keys vault, classified Confidential) appears in the asset inventory but has no corresponding risk entry in the register. This is an auditor red flag — a Confidential asset without a risk assessment suggests incomplete analysis.
I’ve added risk R-08: “Unauthorized extraction of API keys from secrets vault” (Likelihood: 4, Impact: 5, Score: 20, Treatment: Treat, Controls: A.5.17, A.8.24).
Now running the SoA consistency checker with the updated risk register…
The checker confirmed that A.5.17 (Authentication information) and A.8.24 (Use of cryptography) are both marked as applicable in the SoA — consistent with the new risk entry. However, it flagged that A.8.24’s implementation evidence field says “[TBD]” — a placeholder that needs to be replaced with an actual policy reference.
I’ve updated A.8.24’s evidence to reference “Cryptographic-Controls-Section” in the Information Security Policy. Re-running the check… PASS.
In this example, one tool (asset-risk coverage) found a missing risk, which triggered the agent to add it. A second tool (SoA consistency) then verified the control mapping was correct but caught a placeholder in the evidence field. The agent fixed it and confirmed the chain is clean. Three documents — asset inventory, risk register, and SoA — are now consistent, verified by deterministic checks rather than manual review.
This kind of cascading self-correction is what makes tool-assisted ISMS documentation fundamentally different from template-based drafting. The tools don’t just check — they create the conditions for the agent to fix problems before a human reviewer ever sees them.
The dashboard: tracking progress across all 21 skills
As each skill completes, the agent updates the project dashboard. The dashboard provides a single view of ISMS progress:
Dashboard after completing all 21 ISMS skills — documents produced, risks identified and treated, clause maturity assessed.
Key metrics tracked:
- ISMS Completion — percentage of skills completed (Plan → Do → Check → Act)
- Documents Produced — total output artifacts (policies, procedures, registers, reports)
- Risk Distribution — breakdown by severity (Critical / High / Medium / Low)
- Risk Treatment Coverage — percentage of identified risks with treatment plans
- Clause Maturity — per-clause rating on a 0–5 scale
- Gap Findings — open vs. closed findings from the gap assessment
- CAPAs — corrective action status from internal audit findings
- Stage 1/2 Readiness — estimated readiness for certification audits
The dashboard gives consultants and management a real-time view of where the engagement stands and what still needs attention.
Effort comparison: consultant time with and without tool assistance
Based on typical ISO 27001 consulting effort breakdowns for first-time certification of a small-to-mid-sized organization:
| Activity | % of effort | Tool-assisted acceleration |
|---|---|---|
| Scoping, context, applicability | 8% | Organization Profile + ISMS Scope skills reduce interviews and rework |
| Gap assessment | 12% | Mandatory artifact detection and clause requirement analysis replace manual checklist work |
| Risk assessment + SoA + treatment | 24% | Five risk validation checks plus SoA consistency enforcement apply methodology automatically |
| Policy and procedure set | 16% | Context-aware generation with document metadata and mandatory topic validation |
| Internal audit + CAPA | 4% | Impartiality checking and finding severity classification structure the process |
| Management review | 3% | Mandatory input validation ensures all 10 Clause 9.3 inputs are covered |
The heaviest documentation activities (risk assessment, policy generation, gap assessment) are exactly where the validation tools add the most value — not by replacing consultant judgment, but by catching the mechanical errors and omissions that consume review cycles.
Getting started
- Create a new project in Rakenne and select the ISO 27001 ISMS workspace template
- All 21 skills and validation tools are automatically installed
- Start with the Organization Profile — provide your client’s details and let the agent build the structured profile
- Follow the PDCA sequence through all 21 steps, or jump to specific skills based on your gap assessment results
- Use the dashboard to track progress and identify what’s still needed
Each skill is independent but reads artifacts from earlier steps. You can run them in any order, but the recommended sequence ensures each skill has the context it needs from prior outputs.
Summary
The ISO 27001 ISMS workspace template turns ISMS documentation from an ad-hoc drafting exercise into a structured, validated process. The 21 skills cover the full PDCA cycle, and the 60+ validation tools enforce the same checks a senior GRC consultant would apply — consistently, automatically, and traceably.
What sets this apart from any other approach — templates, generic AI, or even dedicated GRC platforms — is the cross-document traceability web. Eleven automated checks verify that risks trace to controls, controls trace to policies, policies trace to evidence, audit findings trace to CAPAs, and scope boundaries are consistent across every downstream document. When a link breaks, the agent detects it, explains why, and fixes it — before a human reviewer or auditor ever sees the gap.
The result is not a set of generic templates. It is a set of internally consistent, organization-specific, clause-aligned artifacts that reference each other, link risks to controls to procedures to evidence, and flag gaps before an auditor does.
Try it yourself
Open a workspace with the skills described in this article and start drafting in minutes.
Get Started Free — No Sign-Up