iso-27001-evidence-collection について
ISO 27001:2022 と SOC 2 の監査証拠を収集する手順とコマンドを提供するガイダンスです。コンプライアンスや監査準備を担うチーム向けに、管理策ごとに証拠を整理し、完全性や鮮度、命名を確認できます。
主な機能
- 01管理策別の証拠収集ワークフロー
- 02クラウド、GitHub、端末のコマンド例
- 03証拠の鮮度要件と命名規則の説明
- 04完全性、形式、管理策の網羅性の確認
- 05管理策に対応した証拠インデックスの作成
活用シーン
- 01外部監査向け証拠パッケージの準備
- 02古い証拠や期限が近い証拠の更新
- 03是正後の証拠の記録
- 04新たに対象となったシステムの基準証拠の整備
MCP 対応
Internal ISO Audit MCP サーバーに任意で接続し、管理策のガイダンス、証拠要件、関連する管理策を検索できます。接続しない場合は、ローカルのコンプライアンスデータや内蔵チェックリストを利用できます。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ open-agreements/ open-agreements --skill iso-27001-evidence-collectionインストール後、Claude Code で/iso-27001-evidence-collectionを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
CONNECTORS.mdrules/api-exports.mdevidence-types.mdscreenshot-guide.md詳細
ISO 27001 の証拠収集
ISO 27001:2022 および SOC 2 の監査証拠を体系的に収集します。このスキルでは、API ファーストの証拠収集コマンドを提供し、管理策ごとに証拠を整理して、監査人によるレビューの前に完全性を検証します。
セキュリティモデル
- スクリプトは実行しません — このスキルは Markdown のみで構成された手順ガイドです
- シークレットは不要です — 参照用チェックリストを使用します。CLI コマンドは既存のローカル認証情報を使用します
- 証拠はローカルに保管されます — すべての出力はローカルファイルシステムに保存されます
- IP クリーン — NIST SP 800-53(パブリックドメイン)を参照します。ISO 管理策はセクション ID のみを記載します
使用するタイミング
次の場合にこのスキルを有効にします。
- 外部監査に向けた証拠パッケージの準備 — 監査人が来る2~4週間前
- 四半期ごとの証拠更新 — 監査対象期間を超えて古くなった証拠を更新します
- 修復後 — 指摘事項が修正されたことを証明する証拠を収集します
- 新しいシステムのオンボーディング — 新たに対象範囲に加わったシステムのベースライン証拠を整備します
- 証拠のギャップ分析 — 監査前に不足しているものを特定します
次の用途には使用しないでください。
- 内部監査の実施 —
iso-27001-internal-auditを使用してください - SOC 2 のみを対象とした準備状況の評価 —
soc2-readinessを使用してください - 監査指摘事項の解釈 — 内部監査スキルを使用してください
主な概念
証拠の優先順位(最良から最悪)
| 順位 | 種類 | 例 | 優れている理由 |
|---|---|---|---|
| 1 | API エクスポート(JSON/CSV) | gcloud iam service-accounts list --format=json | タイムスタンプ付きで改ざんの痕跡が残り、再現可能 |
| 2 | システム生成レポート | ベンダーの SOC 2 レポート、SIEM エクスポート | 権威ある情報源で、メタデータを含む |
| 3 | 設定エクスポート | Terraform の状態、ポリシー JSON | 意図した状態を示し、バージョン管理されている |
| 4 | システム時計を含むスクリーンショット | screencapture -x ~/evidence/... | 視覚的な証明になるが、検証が難しい |
| 5 | 手動の証明 | 責任者が署名した声明 | 最終手段であり、裏付けが必要 |
証拠の鮮度要件
| 証拠の種類 | 最長期間 | 更新頻度 |
|---|---|---|
| アクセスリスト | 90日 | 四半期ごと |
| 脆弱性スキャン | 30日 | 月次 |
| 設定エクスポート | 90日 | 四半期ごと |
| トレーニング記録 | 12か月 | 年次 |
| ペネトレーションテスト | 12か月 | 年次 |
| ポリシー文書 | 12か月 | 年次レビュー |
| インシデント記録 | 監査対象期間 | 継続的 |
| リスク評価 | 12か月 | 年次および変更時 |
証拠の命名規則
{control_id}_{evidence_type}_{YYYY-MM-DD}.{ext}
例:
A.5.15_user-access-list_2026-02-28.jsonA.8.8_vulnerability-scan_2026-02-28.csvA.8.13_backup-test-results_2026-02-28.pdf
ステップごとのワークフロー
ステップ 1:証拠のギャップを特定する
不足している証拠、または古くなった証拠を特定します。
# If Internal ISO Audit MCP server is available:
search_guidance(query="evidence", domain="organizational") # Find controls needing evidence
list_controls(domain="technological") # List all tech controls to assess gaps
get_control_guidance(control_id="A.5.15") # Get evidence requirements for a specific control
# If reading local compliance data:
# Check compliance/evidence/*.md files for upload_status != "OK"
# Check renewal_next dates for upcoming expirations
ステップ 2:収集の優先順位を決める
次の順に証拠を収集します。
- Critical ティアの管理策に対する証拠の不足 — 監査の阻害要因
- 更新期限を過ぎた古い証拠 — 監査人に却下されます
- Relevant ティアの管理策に対する証拠 — 想定されますが、阻害要因ではありません
- Checkbox ティアの証拠 — ポリシーと証明書
ステップ 3:プラットフォームごとに収集する
コンテキストの切り替えを最小限にするため、プラットフォームごとにまとめて証拠収集コマンドを実行します。
GitHub の証拠
# Org settings: MFA requirement, default permissions
gh api orgs/{org} | jq '{
two_factor_requirement_enabled,
default_repository_permission,
members_can_create_public_repositories
}' > evidence/A.5.17_github-org-mfa_$(date +%Y-%m-%d).json
# Branch protection on production repos
for repo in $(gh repo list {org} --json name -q '.[].name'); do
gh api repos/{org}/$repo/branches/main/protection 2>/dev/null | \
jq '{repo: "'$repo'", protection: .}' >> evidence/A.8.32_branch-protection_$(date +%Y-%m-%d).json
done
# Recent merged PRs (change management evidence)
gh pr list --state merged --limit 50 --json number,title,author,reviewDecision,mergedAt,mergedBy \
> evidence/A.8.32_change-records_$(date +%Y-%m-%d).json
# Dependabot alerts (vulnerability management)
gh api repos/{org}/{repo}/dependabot/alerts?state=open \
> evidence/A.8.8_dependabot-alerts_$(date +%Y-%m-%d).json
# Secret scanning alerts
gh api orgs/{org}/secret-scanning/alerts --paginate \
> evidence/A.8.24_secret-scanning_$(date +%Y-%m-%d).json
# Audit log
gh api orgs/{org}/audit-log?per_page=100 \
> evidence/A.8.15_github-audit-log_$(date +%Y-%m-%d).json
GCP の証拠
# IAM policy (access control)
gcloud projects get-iam-policy {project} --format=json \
> evidence/A.5.15_gcp-iam-policy_$(date +%Y-%m-%d).json
# Service accounts
gcloud iam service-accounts list --format=json \
> evidence/A.5.16_gcp-service-accounts_$(date +%Y-%m-%d).json
# Audit logging config
gcloud projects get-iam-policy {project} --format=json | jq '.auditConfigs' \
> evidence/A.8.15_gcp-audit-config_$(date +%Y-%m-%d).json
# Log sinks (centralization)
gcloud logging sinks list --format=json \
> evidence/A.8.15_gcp-log-sinks_$(date +%Y-%m-%d).json
# Compute instances (asset inventory)
gcloud compute instances list --format=json \
> evidence/A.5.9_gcp-compute-inventory_$(date +%Y-%m-%d).json
# Cloud SQL backup config
gcloud sql backups list --instance={instance} --format=json \
> evidence/A.8.13_gcp-sql-backups_$(date +%Y-%m-%d).json
# Firewall rules
gcloud compute firewall-rules list --format=json \
> evidence/A.8.20_gcp-firewall-rules_$(date +%Y-%m-%d).json
Azure の証拠
# Role assignments (access control)
az role assignment list --all --output json \
> evidence/A.5.15_azure-role-assignments_$(date +%Y-%m-%d).json
# Activity log (audit trail)
az monitor activity-log list --max-events 100 --output json \
> evidence/A.8.15_azure-activity-log_$(date +%Y-%m-%d).json
# Network security groups
az network nsg list --output json \
> evidence/A.8.20_azure-nsgs_$(date +%Y-%m-%d).json
# Backup jobs
az backup job list --resource-group {rg} --vault-name {vault} --output json \
> evidence/A.8.13_azure-backup-jobs_$(date +%Y-%m-%d).json
# Storage encryption
az storage account list --query "[].{name:name, encryption:encryption}" --output json \
> evidence/A.8.24_azure-storage-encryption_$(date +%Y-%m-%d).json
Google Workspace の証拠
# User list with MFA status
gam print users fields primaryEmail,name,isEnrolledIn2Sv,isEnforcedIn2Sv,lastLoginTime,suspended \
> evidence/A.5.17_workspace-users-mfa_$(date +%Y-%m-%d).csv
# Admin roles
gam print admins > evidence/A.8.2_workspace-admins_$(date +%Y-%m-%d).csv
# Mobile devices
gam print mobile > evidence/A.8.1_workspace-mobile-devices_$(date +%Y-%m-%d).csv
macOS エンドポイントの証拠
# FileVault encryption
fdesetup status > evidence/A.8.24_filevault-status_$(date +%Y-%m-%d).txt
# System configuration
system_profiler SPHardwareDataType SPSoftwareDataType \
> evidence/A.8.1_endpoint-config_$(date +%Y-%m-%d).txt
# Screen lock settings
profiles show -type configuration 2>/dev/null | grep -A10 -i "lock\|idle\|screensaver" \
> evidence/A.6.7_screenlock-config_$(date +%Y-%m-%d).txt
ステップ 4:証拠パッケージを検証する
監査人に提出する前に、完全性を確認します。
- 完全性:SoA の該当するすべての管理策について、証拠がありますか?
- 鮮度:すべての証拠が所定の期間内にありますか?
- 形式:API エクスポートはタイムスタンプ付きの JSON/CSV ですか?スクリーンショットにはシステム時計が表示されていますか?
- 命名:ファイルは命名規則に従っていますか?
- 網羅性:Critical ティアの管理策には、少なくとも2種類の証拠がありますか?
# If Internal ISO Audit MCP server is available:
list_controls() # Get all controls to verify evidence coverage
get_control_guidance(control_id="A.8.8") # Check specific control's evidence expectations
search_guidance(query="vulnerability scanning evidence") # Find controls related to specific evidence types
ステップ 5:証拠インデックスを生成する
すべての証拠を管理策に対応付けて一覧にしたインデックスファイルを作成します。
# Evidence Package Index
Generated: {date}
Audit period: {start} to {end}
| Control | Evidence File | Type | Collected | Status |
|---------|--------------|------|-----------|--------|
| A.5.15 | gcp-iam-policy_2026-02-28.json | API export | 2026-02-28 | Current |
| A.5.17 | workspace-users-mfa_2026-02-28.csv | API export | 2026-02-28 | Current |
| ... | ... | ... | ... | ... |
すること/しないこと
すること
- 可能な限り、スクリーンショットより ISO 8601 形式のタイムスタンプ付き API エクスポートを使用します
- SOURCE システム(セカンダリレポートではなく IdP)から証跡を収集します
- メタデータ(収集日、システムバージョン、収集したユーザー)を含めます
- 明確な命名規則を設け、バージョン管理されたディレクトリに証跡を保存します
- 現在の状態だけでなく、監査期間(通常は過去 12 か月)の証跡を収集します
- スクリーンショットには
screencapture -x ~/evidence/{filename}.pngを使用します(影や枠線なしでキャプチャできます)
しないこと
- システム時計(macOS のメニューバー、Windows のタスクバー)が見えない状態でスクリーンショットを撮らないでください
- 本番環境ではなく、サンドボックス/ステージング環境から証跡を収集しないでください
- 収集後に証跡を手動で編集しないでください(監査人がソースと照合する可能性があります)
- 監査の前週まで収集を先延ばしにしないでください
- 古い証跡でも許容されると思い込まず、上記の鮮度要件を確認してください
- 異なる監査期間の証跡を同じファイルに混在させないでください
トラブルシューティング
| 問題 | 解決策 |
|---|---|
| API コマンドで認証が必要 | 既存のローカル認証情報を使用します:gcloud auth login、az login、gh auth login |
| ツールがインストールされていない | インストールします:brew install gh、brew install --cask google-cloud-sdk、brew install azure-cli |
| 権限が不十分 | 該当サービスへの読み取り専用アクセスを申請し、アクセス申請を証跡として記録します |
| 証跡のサイズが大きすぎる | --limit または --max-events フラグを使用します。全件エクスポートではなく、要約統計を収集します |
| ベンダーが SOC 2 レポートを提供しない | ベンダーのトラストセンターから申請します。入手できない場合は、申請したことを記録し、ベンダーのセキュリティページを使用します |
| スクリーンショットに時計が含まれない | macOS では、フルスクリーンでキャプチャするか、メニューバーも含まれる screencapture -x を使用します |
ルール
トピック別の詳細な証跡収集ガイダンスについては、以下を参照してください。
| ファイル | 対象範囲 |
|---|---|
rules/api-exports.md | クラウドプロバイダー(GCP、Azure、AWS、GitHub、Google Workspace)別の CLI コマンド |
rules/screenshot-guide.md | 監査に対応したスクリーンショットを撮るタイミングと方法 |
rules/evidence-types.md | 管理領域ごとの証跡タイプ要件 |
クレジット
証跡収集手順と管理策のガイダンスは、Internal ISO Audit(Hazel Castro、ISO 27001 主任監査人、経験 14 年以上、監査 100 件以上)と共同で作成しました。
ランタイム検出
- Internal ISO Audit MCP サーバーが利用可能(最適)— 管理策ガイダンスのライブ検索、NIST 相互参照、すべての管理策に関する証跡要件の全文検索を利用できます。サーバー:
internalisoaudit.com/api/mcp - ローカルのコンプライアンスデータが利用可能(良好)—
compliance/evidence/*.mdから証跡のステータスを読み取ります - 参照のみ(基本)—
rules/にある埋め込みチェックリストとコマンドリファレンスを使用します
コネクター
Internal ISO Audit MCP サーバーのセットアップについては、CONNECTORS.md を参照してください。