iso-27001-internal-audit

ISO 27001 内部監査

ISO 27001:2022 に基づく、体系的な内部監査を実施します。このスキルでは、認定監査員と同じワークフローに沿って、スコープの設定、管理策の評価、証拠の収集、監査所見の作成を進めます。

セキュリティモデル

• スクリプトは実行されません — このスキルは Markdown の手順ガイダンスのみで構成されています
• シークレットは不要です — 公開されている参照データを使用します
• 知的財産権を侵害しません — すべての管理策の説明は、パブリックドメインの NIST SP 800-53 を参照したオリジナルの記述です。ISO 27001:2022 の管理策は、セクション ID（例：「A.5.15」）のみを参照し、著作権で保護されたタイトルや説明は使用しません
• 証拠はローカルに保管されます — 証拠収集コマンドの出力先はローカルファイルシステムです

使用する場面

次の場合に、このスキルを有効にしてください。

1. サーベイランス審査または認証審査の準備 — 外部審査の 4〜6 週間前に実施します
2. 四半期ごとの内部監査 — ISO 27001 では少なくとも年 1 回の内部監査が必要です。四半期ごとの実施がベストプラクティスです
3. インシデント後のレビュー — 管理策に不備があったか、どのような是正措置が必要かを評価します
4. 新しいフレームワークの導入 — 既存の管理策を ISO 27001 の要件に対応付けます
5. 新しいコンプライアンスツールの導入 — 自動チェックが適切な管理策を対象としていることを検証します

次の場合は使用しないでください。

• ISO 27001 の適用宣言書（SoA）を一から作成する場合 — まず証拠を収集するために iso-27001-evidence-collection を使用してください
• SOC 2 のみを対象とする監査 — 代わりに soc2-readiness を使用してください
• 特定の契約条項を確認または解釈する場合 — 法的契約に関するスキルを使用してください

基本概念

管理策ドメイン（ISO 27001:2022 附属書 A）

ISO 27001:2022 には、4 つのドメインにわたる附属書 A の管理策が 93 件あり、これに加えて ISMS の箇条 4〜10（細分箇条 30 件）があります。このスキルでは、クラウドネイティブなスタートアップにとって各ドメインで最も重要な、優先度の高い附属書 A の管理策 48 件（全 93 件中）を対象とします。残りの管理策は優先度が低いか、クラウドネイティブな組織では通常該当しません。

ドメイン	管理策	焦点
A.5 組織	37	ポリシー、役割、インシデント管理、サプライヤーとの関係
A.6 人的要因	8	審査、トレーニング、雇用終了、機密保持
A.7 物理的管理策	14	施設のセキュリティ、機器、メディア — クラウドスタートアップではほとんどが該当しません
A.8 技術的管理策	34	アクセス制御、暗号化、ログ記録、SDLC、ネットワークセキュリティ
箇条 4〜10	30	ISMS マネジメントシステム（状況、リーダーシップ、計画、支援、運用、パフォーマンス、改善）

判断ツリー：スタートアップのスコープ設定

Is the organization cloud-native (no owned data centers)?
├── YES → Mark A.7.1-A.7.9, A.7.11-A.7.13 as "satisfied by cloud provider SOC 2"
│         Focus evidence on: laptops, home offices, mobile devices
├── NO  → Full A.7 assessment required
│
Does the organization develop software?
├── YES → A.8.25-A.8.34 (SDLC controls) are in scope
├── NO  → A.8.25-A.8.34 can be scoped out with justification
│
Does the organization handle PII?
├── YES → A.5.34 (privacy) is critical, cross-reference with GDPR/CCPA
├── NO  → A.5.34 is checkbox tier

管理策の優先度分類

93 件の管理策すべてが、監査で同じように不備と判定されるわけではありません。監査での不備の発生頻度に応じて優先順位を付けます。

優先度	件数	対応
重大	~30	詳細な評価：証拠、インタビュー、観察
該当	~30	標準的な確認：証拠のレビュー、抜き取り確認
チェックボックス	~33	ポリシーの存在、またはクラウドプロバイダーによる対応を確認

管理策ごとの詳しいガイダンスについては、rules/<domain>.md を読み込んでください。

手順ごとのワークフロー

ステップ 1：スコープと状況

1. ISMS のスコープを特定する — 対象となるシステム、プロセス、拠点、担当者は何ですか？
2. 適用宣言書（SoA）を収集する — 附属書 A の 93 件の管理策のうち、どれが適用されますか？
3. 前回の監査所見を確認する — 前回は何が指摘されましたか？ 是正措置は完了していますか？
4. データの鮮度を確認する — 監視ダッシュボードまたは自動テストシステムを使用している場合、データが 7 日未満のものであることを確認します

# If Internal ISO Audit MCP server is available:
list_controls()                                    # Get all controls with tier classifications
get_control_guidance(control_id="Clause 9.2")      # Check specific ISMS clause requirements

# If reading local files:
# Check compliance/status/last_refresh.yaml for staleness

ステップ 2：ISMS 条項評価（条項 4～10）

ほとんどのスタートアップはここでつまずきます。ISMS を、機能するマネジメントシステムではなく、単なる文書として扱っているためです。

1. 条項 5（リーダーシップ） — 署名済みのセキュリティポリシーはありますか？ISMS の責任者は誰ですか？マネジメントレビューの証拠はありますか？
2. 条項 6（計画） — リスクアセスメントはありますか？最新のものですか（12 か月未満）？SoA を参照していますか？
3. 条項 7（支援） — コンピテンシーマトリクスはありますか？トレーニング記録は最新ですか？
4. 条項 8（運用） — リスク対応計画は実行されていますか？
5. 条項 9（パフォーマンス評価） — 指標はありますか？内部監査は実施済みですか？マネジメントレビューの記録はありますか？
6. 条項 10（改善） — 不適合は追跡されていますか？是正処置は実施されていますか？

監査員向けヒント：監査員は、つながりのある一連の流れを確認します。リスクアセスメント → SoA → リスク対応計画 → 実施の証拠 → モニタリング → マネジメントレビュー → 改善。この流れに途切れがあると、不適合になります。

ステップ 3：附属書 A 管理策の評価

ドメインごとに管理策を確認し、Critical ティアを優先します。

1. 各 Critical 管理策について：

   • 確認：文書化されたポリシー／手順はありますか？
   • 確認：実施の証拠はありますか？
   • 確認：モニタリング／レビューの証拠はありますか？
   • 所見を記録：適合／軽微な不適合／重大な不適合／観察事項

2. 各 Relevant 管理策について：

   • 確認：実施の証拠はありますか？
   • 1～2 項目を抜き取り確認します
   • 所見を記録します

3. 各 Checkbox 管理策について：

   • ポリシーが存在すること、またはクラウドプロバイダーの SOC 2 が対象としていることを確認します
   • 適合として記録するか、例外を記載します

# If Internal ISO Audit MCP server is available:
list_controls(domain="organizational")                      # List all controls in a domain with tiers
get_control_guidance(control_id="A.5.15")                   # Full guidance: auditor hints, pitfalls, evidence
search_guidance(query="access review", domain="organizational")  # Find related controls by keyword
get_nist_mapping(control_id="A.5.15")                       # Cross-reference to NIST SP 800-53

ステップ 4：証拠の収集

各所見について、裏付けとなる証拠を収集します。

1. API エクスポート（推奨）— ソースシステムから取得した、タイムスタンプ付きの JSON/CSV
2. スクリーンショット（API を利用できない場合）— システムクロックが見える状態で含める必要があります
3. インタビュー記録 — 誰がいつ何を話したかを要約します
4. 文書レビュー — 文書名、バージョン、レビュー日を記録します

証拠の命名規則：{control_id}_{evidence_type}_{date}.{ext} 例：A.5.15_user-access-list_2026-02-28.json

詳細な収集コマンドについては、rules/ ファイルを読み込むか、iso-27001-evidence-collection スキルを使用してください。

ステップ 5：所見の作成

不適合ごとに：

## Finding: [Short title]

- **Control**: A.x.x
- **NIST Reference**: [NIST control ID]
- **Severity**: Major / Minor / Observation
- **Description**: [What was found]
- **Evidence**: [What evidence supports the finding]
- **Root Cause**: [Why the control failed]
- **Corrective Action**: [Specific remediation steps]
- **Due Date**: [Agreed timeline]
- **Owner**: [Person responsible]

重大度の定義：

• 重大な不適合：管理策が存在しない、またはまったく機能していません。監査不合格のリスクがあります。
• 軽微な不適合：管理策は存在しますが、不備があります。次回のサーベイランス監査までに修正する必要があります。
• 観察事項：改善の可能性があります。必須ではありませんが、推奨されます。

ステップ 6：監査報告書

構成を整えた監査報告書を作成します。

1. エグゼクティブサマリー — ISMS の全体的な成熟度、主な所見、推奨事項
2. 適用範囲 — 監査した対象、除外した対象
3. 方法論 — 評価した管理策、レビューした証拠、インタビューした関係者
4. 所見 — 重大度と是正処置を付してドメインごとに分類
5. 肯定的な観察事項 — うまく機能している点（監査員もこれらを記録します）
6. 結論 — 外部監査への準備状況、推奨スケジュール

クイックリファレンス：最も頻繁に失敗する上位 10 の管理策

#	管理策	よくある失敗	対処法
1	A.5.15	定期的なアクセスレビューが行われていない	四半期ごとのレビューを予定し、ユーザーリストをエクスポートします
2	A.8.8	脆弱性スキャンが行われていない	Dependabot/Snyk を導入し、インフラのスキャンを予定します
3	A.5.24	インシデント対応計画がテストされていない	机上演習を実施し、結果を文書化します
4	A.8.5	すべての環境で MFA が強制されていない	すべての本番環境アカウントと管理者アカウントで MFA を有効にします
5	A.5.30	事業継続性テストが行われていない	DR フェイルオーバーテストを実施し、RTO/RPO の結果を文書化します
6	A.8.15	監査ログが一元管理されていない	ログを SIEM/CloudWatch/Stackdriver に送信します
7	A.8.9	ベースライン構成がない	サーバー／コンテナのベースイメージを文書化します
8	A.6.1	身元調査が完了していない	すべての従業員の審査が完了していることを確認します
9	A.8.32	変更管理プロセスがない	PR レビューを必須にし、デプロイプロセスを文書化します
10	A.5.9	資産インベントリが不完全	クラウドプロバイダーとエンドポイント管理からエクスポートします

DO / DON'T

DO

• ISO 8601 形式のタイムスタンプ付き API エクスポートで証拠を収集します。スクリーンショットより常に優先されます
• 文書をレビューするだけでなく、管理策をテストします。監査人が確認するのは、ポリシーだけではなく実装です
• さまざまな階層の担当者に聞き取りをします。マネージャーとエンジニアで話が異なることがあります
• 監査のバランスと徹底性を示すため、好ましい所見も文書化します
• SoA を実際の管理策に沿った状態に保ちます。SoA と実装の間のギャップは重大な所見になります
• スクリーンショットが必要な場合、macOS では screencapture -x ~/evidence/{filename}.png を使用します

DON'T

• システム時計が表示されていないポータルのスクリーンショットを撮らないでください。日付のない証拠は監査人に却下されます
• 実装を確認せずに「ポリシーがあります」という説明を受け入れないでください。「見せてください」＞「説明してください」です
• 自分の作業を監査しないでください。独立性の要件（Clause 9.2）により、監査人は自分の担当領域を監査できません
• チェックボックス形式の管理策を手間がかからないものとして扱わないでください。N/A の管理策にも SoA での正当化が必要です
• Annex A だけに注目して ISMS 条項を省略しないでください。初回監査での失敗の大半は条項 4～10 にあります

トラブルシューティング

問題	解決策
データが古い（7 日超）	監視ダッシュボードから更新するか、ソースシステムから再エクスポートします
どの管理策が該当するか判断できない	SoA から始めます。SoA がない場合は、上記の判断ツリーを使用します
監査までに対応すべき所見が多すぎる	優先順位を付けます。まずすべての重大な不適合を修正し、次に重大度がクリティカルな軽微な不適合に対応します
証拠のタイムスタンプが監査期間と一致しない	監査期間内（通常 12 か月）に証拠を再収集します
クラウドプロバイダーの管理策が文書化されていない	プロバイダーに SOC 2 Type II レポートを依頼し、その管理策を自社の SoA に対応付けます
内部監査を実施したことがない	今回が初回の内部監査です。報告書にその旨を記録し、定期的に実施する計画を立てます

ルール

管理策ごとの詳細なガイダンスについては、該当するルールファイルを読み込んでください。

ファイル	対象範囲
rules/access-control.md	A.5.15-A.5.18、A.8.2-A.8.5 — ID、認証、認可
rules/incident-response.md	A.5.24-A.5.29、A.6.8 — インシデントのライフサイクル
rules/encryption.md	A.8.24、A.8.10-A.8.12 — 暗号化管理策
rules/change-management.md	A.8.25-A.8.34、A.8.9、A.8.32 — SDLC と構成
rules/logging-monitoring.md	A.8.15-A.8.17 — 監査証跡と監視
rules/business-continuity.md	A.5.30、A.8.13-A.8.14 — バックアップ、DR、BCP
rules/people-controls.md	A.6.1-A.6.8 — 人事セキュリティのライフサイクル
rules/supplier-management.md	A.5.19-A.5.23 — サードパーティリスク
rules/isms-management.md	条項 4～10 — マネジメントシステムの運用

謝辞

監査手順と管理策のガイダンスは、Internal ISO Audit（Hazel Castro、ISO 27001 主任監査人、14 年以上の経験、100 件以上の監査）の協力により作成されました。

実行モードの検出

このスキルは、次の3つのモードで動作し、自動的に検出されます。

1. Internal ISO Audit MCP server が利用可能（最適） — 監査人向けヒント、NIST 相互参照、全文検索を含む、最新の管理策ガイダンスを検索します

   • 検出方法：クライアントに internalisoaudit MCP server が設定されている
   • ツール：get_control_guidance、list_controls、get_nist_mapping、search_guidance
   • サーバー：internalisoaudit.com/api/mcp

2. ローカルのコンプライアンスデータが利用可能（良好） — compliance/ ディレクトリを直接読み取ります

   • 検出方法：compliance/status/last_refresh.yaml が存在する
   • 利点：過去のテストデータ、証拠のステータス、管理策のマッピング

3. 参照情報のみ（基本） — 埋め込みの rules/ ファイルを使用し、最新データはありません

   • 常に利用可能です
   • 利点：手順に関するガイダンス、管理策の説明、証拠のチェックリスト
   • 制限事項：組織固有のステータスデータはありません

コネクター

Internal ISO Audit MCP server のセットアップについては、CONNECTORS.md を参照してください。