インターネット新時代

週末なので、本のお話です。

村井純先生の「インターネット新時代」を買いました。
まだ読み始めたばかりですが、日本のインターネットの父と呼ばれる村井先生が、インターネットの最近の動向とインターネットの未来を語っています。
インターネットの未来を知るための必携の書となることでしょう。

バッテリーがダメになりそう

先日突然、ThinkPadから以下の警告が発せられました。

「バッテリーは、初期状態の満充電容量の49%を保持している状態です。ここをダブルクリックして、バッテリー交換に関する情報を参照してください。」とのことです。

そこで、ダブルクリックすると、

http://www.lenovo.com/planetwide/select/selector.html

へ飛ばされます。英語のページです。このページの

Japan | 日本

をクリックすると、

http://www.lenovo.com/jp/ja/index.html

に飛びます。バッテリーはどこかわかりません。めげずに、

製品の周辺機器

をクリックします。するとようやく、

バッテリー電源

という選択肢にたどりつきました。で、値段を見ると1万6千円！念のため、同じ型のバッテリーをGoogleで調べると、素性を知らないサイトで7千円台から売ってます。

この値段の差は大きい。しかし、よく知らないところで買うのは心配。それにバッテリーは不良品だと火災の危険もあるなぁ。

悩んだ末、結局、レノボさんで正規品を注文しました。保険料ですね。

戦略策定・リスク評価（事業継続管理の監査）チェックリスト

事業継続管理の監査／戦略策定／
事業継続管理の監査／リスク評価／

情報セキュリティの監査のチェックリス ト作成第3弾です。参考書は引き続き「ここから始めるIT監査」（社団 法人日本内部監査協会編）を使います。

3．事業継続管理の監査

1. 戦略策定
2. リスク評価
3. 導 入
4. 維持管理

そ れで は、1．戦略策定と2．リスク評価のチェックリストを作成していきましょう。

  必要な統制

1. BCPの方針文書
2. 業務リスト
3. リスクシナリオ
4. 脆 弱性リスト

  チェックリスト

1. 戦略策定
   
1. BCPの方針策定
1. BCMに関する組織の基本的な考え方を示したBCPの方針が策定されているか
• BCPの方針文書が存在することを確認
2. BCPの 方針は組織員に充分周知されているか
• BCPの方針文書が掲示 されていることを確認
• BCPの方針文書の内容を組織員が理解していることを確認
2. BCM 構築体制の整備
1. 全組織横断的なBCM構築体制が整備されているか
• BCM構築メンバーが全社から募られていることを確認
• BCM構築が経営者により指示されて いることを確認
2. リスク評価
   
1. ビジネス影響度分析
1. 各業務が停止した場合の影響度を分析（ビジネス影響度分析）
• 業務リストの存在を確認
• 業務リストに業務ごとに停止 した場合の影響が記載されていることを確認
2. 各業務の再開までの目標時間（RTO)が決定されているか
• 業務リストに各業務の再開までの目標時間（RTO)が記載されていることを確 認
2. リスクシナリオの作成
1. 業務を停止させる脅威および優先的に保護すべき経営資 源（人員、場所、情報システム、重要書類等）を洗い出しているか
• リ スクシナリオには優先的に保護すべき経営資源が記載されていることを確認
2. 脅威が発生した際に経営資源に複合的に影響 を与えるシナリオ（リスク・シナリオ）を想定しているか
• リス クシナリオは業務を中断させる脅威が複合的に発生することを想定していることを確認（電気と公共交通機関が同時に停まる等）
3. Availability に関わる脆弱性の洗い出しとそれらへの対応
1. 業務を停止させる恐れのある脆弱性（Availabilityに関わる脆弱性）を洗 い出しているか
• 脆弱性リストには、地震の多発地帯への立地の ように、脅威の発生を促す脆弱性が記載されていることを確認
• 脆弱性リストには、消火設備の不備のように、脅威の発生時に業務の中断を促 す脆弱性が記載されていることを確認
2. 洗い出したすべての脆弱性に対して、対応の必要性が検討されているか
• 脆弱性リストに、各脆弱性への対応状況が記載されていることを確認
4. Recoverability に関わる脆弱性の洗い出しとそれらへの対応
1. 業務が停止した際に、復旧を遅延させたり、被害を拡大させたりする恐れのある脆弱性 （Recoverabilityに関わる脆弱性）を洗い出しているか
• 脆 弱性リストには、緊急連絡網・手順等の未整備のように、脅威発生時に早期復旧を阻む脆弱性が記載されていることを確認
• 脆弱性リストに は、マスコミ対応窓口の分散のように、脅威発生時に業務への影響を拡大する脆弱性が記載されていることを確認
2. 洗い出したすべ ての脆弱性に対して、対応の必要性が検討されているか
• 脆弱性 リストに、各脆弱性への対応状況が記載されていることを確認

BCPの用語は日本語訳が洗練されていないため、わかりにくい印象があります。

アクセス・コントロール（情報セキュリティの監査）チェックリスト

情報セキュリティの監査／アクセス・コントロール／

情報セキュリティの監査のチェックリス ト作成第3弾です。参考書は引き続き「ここから始めるIT監査」（社団 法人日本内部監査協会編）を使います。

2．情報セキュリティ

1. 情 報セキュリティマネジメント態勢
2. 建物・設備等の安全対策
3. ア クセスコントロール

そ れで は、3．アクセス・コントロールのチェックリストを作成していきましょう。

  必要な統制

1. アクセス・コントロール方針
2. アクセス・コントロール
3. アクセス権限管理手続
   
4. ア クセス権限管理台帳
5. アクセスログ
   

  チェックリスト

1. ア クセス・コントロール設計
   
1. アクセス権設定基準、ユーザーID管理、パスワード管理等のアクセス・コントロール方針は明 確にされているか
   
•  アクセス・コントロール方針の存 在を確認
2. ユーザーID等の識別・認証機能、ユーザーIDへの権限設定機能、データ暗号化機能等のアクセス・コントロール機能 が検討され、アクセス・コントロールの方針に則しているか
   
• ア クセス・コントロールの実装状状況を確認
• アクセス･コントロールが方針に則している確認
  
3. システム 導入、パスワード管理、本番環境へのアクセス・更新等の特権的IDは、必要な種類に限定して設定されているか
   
• アクセス・コントロール方針から特権的IDが必要な業務を確認
  
• 特 権的IDの設定状況を確認
  
4. 非権限者によるアクセス防止のため、必要に応じてタイムアウト機能が組み込まれているか
   
• アクセス・コントロール方針からタイムアウト機能の組み込みポリシーを確認
• タ イムアウト機能の組み込み状況を確認
  
2. ユーザーID・パスワードの管理
   
1. ア クセス権限の設定は適切か
   
• 組織図や業務分担表からア クセス権限が職位や業務内容を考慮していることを確認
• アクセス権限がシステムごとに設定されていることを確認
2. ア クセス権限の付与に係る申請・承認・発行・削除等の手続が定められているか
   
• アクセス権限管理手続の存在を確認
  
3. ユーザーIDの登録・変更・削除の管理者が定められ、 ユーザーIDが一元管理されているか
   
• アクセス権限の 管理者を確認
• アクセス権限管理台帳から定期的に設定状況が確認されていることを確認
  
4. 特権的IDの 付与は、責任者の承認により行われているか
• アクセス権限管理 台帳から特権的IDの付与に責任者の承認があることを確認
  
5. 特権的IDの使用については、操作記録を取る等、使用状況 が明確になるように管理されているか
• アクセスログから特権的 IDの使用状況を確認
  
6. 第三者に見破られないようなパスワードを使用することが徹底されているか
• パスワードの設定ルールを確認
• パスワードの設定制限の実装を 確認
  
3. アクセスの監視
1. システムや保有情報の重要度に応じて、ユーザーID、ログ イン・ログオフ日時、操作内容等のアクセスログが記録され、管理方法が定められているか
• アクセスログの管理ルールを確認
• アクセスログの記録項目にシステムファイルへのアクセスの失敗や権限外のコ マンド操作の失敗の記録があることを確認
2. アクセスログは必要に応じて、定期的に分析され、改ざん・削除されないように保管さ れているか
   
• アクセスログの分析記録を確認
• ア クセスログの保管状況を確認
  

先 日のセミナーではアクセスログの管理だけでは不十分であると教わりました。アクセス・コントロールは監査でどのレベルまで確認するべきなのか難しい領域で す。

建物・設備等の安全対策（情報セキュリティの監査）チェックリスト

情報セキュリティの監査／建物・設備等 の安全対策／

情報セキュリティの監査のチェックリスト作成第2弾です。参考書は引き続き「ここから始めるIT監査」（社団 法人日本内部監査協会編）を使います。

2．情報セキュリティ

1. 情 報セキュリティマネジメント態勢
2. 建物・設備等の安全対策
3. アクセスコントロール

そ れで は、2．建物・設備等の安全対策のチェックリストを作成していきましょう。

  必要な統制

1. 安全対策基準の採用
2. 入退室管理
   
3. 入退室監視
4. 機器および記憶媒体保管・持出 し・持込み・廃棄の管理
5. 情報セキュリティマネジメントシステム
6. サーバー設置基準
7. データ保護手続
8. 障 害発生時対応マニュアル
   

  チェックリスト

1. 建物・設備の安全 対策
1. コンピュータセンターの建物、コンピュータ室の設置場所、電源・空調・消火・回線関連等の設備は、一般に公表されている情 報システムに関連する安全対策基準等に基づいて維持・管理されているか
• ど の安全対策基準を採用しているかを確認
  
• 安全対策基準との適合状況を維持・管理していることを確認
  
2. コ ンピュータセンター・コンピュータ室への入退は、入退者の本人確認を行い、入退権限を保有するものであることを確認しているか。また入退の記録がとられて いるか
• 入退時の本人確認方法を確認
• 入退の 記録の存在を確認
  
3. コンピュータ室への入退室権限は、適切に管理されているか
• 入退室権限の管理方法を確認
• 入退室権限の管理実施状況を確認
  
4. コ ンピュータ室への無許可の者の入退室がないことを確認されているか
• 入 退室者の監視状況を確認
• 監視記録から無許可の入退者が存在しないことを確認
  
2. パソコン、 サーバーの管理
1. パソコン等の機器および記憶媒体に係る、保管・持出し・持込み・廃棄等の管理方法は明確にされているか
• パソコン等の機器および記憶媒体に係る、保管・持出し・持込み・廃棄等の管理 方法を確認
2. パソコンや記憶媒体のデータが、漏洩しないような対策が講じられているか
• 情報セキュリティマネジメントシステムを確認
  
3. パ ソコン等の機器に、業務上、不必要なソフトウェアがインストールされないように管理されているか
• インストールソフトウェアの管理状況を確認
• 実査により不要なソフトウェアがインストールさ れていないことを確認
  
4. サーバ等の設置基準、データ保護手続、障害発生時の対応策・手順等が明確にされているか
• サーバー等の設置基準が存在することを確認
• バックアップ等 のデータ保護手続を確認
• 障害発生時の対応マニュアルを確認

昨今のセキュリティの動向を見ると、統制のレベルはもっと高くなければならないのかもし れません。統制のレベルが高くなると利便性が損なわれる可能性があるので難しいところです。

ドキュメント流通セミナー

＠IT情報マネジメントドキュメントセミナーに行ってきました。
基調講演は青山学院大学大学院の八田進二教授による「内部統制の実態に学ぶ～画一的なセキュリティ対策からの脱却～」でした。
内部統制報告制度を総括し、企業ごとに適切なレベルの対応が必要であることを強調されていました。

セッションは各社からの商品説明が中心で、新しい技術の動向を知ることができました。

特別講演はS&Jコンサルティング株式会社の三輪信雄氏による「雲の中のセキュリティ」でした。
クラウドコンピューティングのセキュリティ上の問題点を、セキュリティの専門家の視点からわかりやすく解説していました。IT監査にも参考になる内容でした。

ドキュメントのセキュリティは企業活動に直結するだけに最新動向を知ることは重要だと思いました。

情報セキュリティマネジメント態勢（情報セキュリティの監査）チェックリスト

情報セキュリティの監査／情報セキュリティマネジメント態勢／

今回から情報セキュリティの監査のチェックリスト作成に入ります。以降、参考書は「ここから始めるIT監査」（社団法人日本内部監査協会編）を使います。

1．シ ステムライフサイクル

2．情報セキュリティ

1. 情報セキュリティマネジメント態勢
2. 建物・設備等の安全対策
3. ア クセスコントロール

3．事業継続…

それでは、1．情報セキュリティマネジメント態勢のチェックリストを作成していきましょ う。

  必要な統制

1. 情報セキュリティポリシー
2. 対策基準
3. 実施手順
4. 障害・事故等の記録
5. 自 己点検・自己評価の記録
6. 情報セキュリティ委員会
   

  チェックリスト

1. 情報セキュリティポリシーの策定
1. 情報資産を保護するための基本方針（情報セキュリティポリシー）が策 定されているか
• 情報セキュリティポリシーが存在することを確 認
  
2. 基本方針（情報セキュリティポリシー）には、保護されるべき情報資産、保護する理由、責任の所在等の項目が含まれ ているか
• 情報セキュリティポリシーに情報資産、保護する理 由、責任の所在等の項目が含まれていることを確認
3. 基本方針（情報セキュリティポリシー）に基づき、対策基準（スタンダー ド）、実施手順(プロシージャー）が策定されているか
• 情報セ キュリティポリシーに基づき、何をするべきかを記述した対策基準が策定されていることを確認
• 対策基準で定めた規定を実施する際の手順を 記載した実施手順が策定されていることを確認
  
2. 情報セキュリティポリシーの運用
1. 情 報セキュリティポリシーは、全組織員、外部委託先等に周知徹底されているか
• 研修等で情報セキュリティポリシーが全従業員に周知を実施していることを確認
  
2. 障害・事故等が発生 した場合、手続にしたがい報告され、記録されているか
• 障害・ 事故等の記録から障害・事故等が手続にしたがい報告され、記録されていることを確認
3. 評価・監査
1. 自 己点検・自己評価が定期的に実施されているか
• 自己点検・自己 評価の記録を確認し定期的に実施されていることを確認
  
2. 情報セキュリティ統括責任者等は、内部監査・外部監査の指摘事 項を把握しているか
• 情報セキュリティ統括責任者等が内部監 査・外部監査からの指摘事項を伝達されていることを確認
  
4. 是正
1. 障害・事故等の分 析により再発防止策が講じられているか
• 経営者が認知する情報 セキュリティ委員会が開催されていることを確認
• 情報セキュリティ委員会の議事録から障害・事故等の分析と再発防止策の検討が講じられて いることを確認
  
2. 障害・事故等の分析結果が、対策基準（スタンダード）の見直しに反映されているか
• 対策基準の更新状況から情報セキュリティ委員会の検討事故等が反映されているこ とを確認
  

情報セキュリティマネジメントは常に改善を繰り返すことでより高度なものになっていき ます。ISO27001ほど細かくなくとも、今回のチェック項目に取り組むことで情報セキュリティのレベルは相当上がることが期待されます。

Http?

駅の名刺自動販売機で作成した名刺のURL表記ですが、

Http://　って…何でもかんでも頭文字を大文字にしなくてもいいのに。
実際には、ブラウザがhttp://に変換してくれます。
さらに、http://は省略しても大丈夫だったりします。

カスタマーとクライアント

ふとしたことからこんな本を読む機会がありました。保険とは関係ない業界の私ですが、とても参考になる考え方が書かれていたのでご紹介します。

いろいろと参考になることが書かれていましたが、特に、『「カスタマー」と「クライアント」は似て非なる言葉』というコラムが心に残りました。
カスタマーは「お客様」＝「頭を下げて購入してもらう相手」であり、クライアントは「依頼主」＝「先方っから頭を下げてお願いされる相手」であるとしています。
そして、「プロフェッショナルはカスタマーではなくクライアントを持つ」としています。

最近は、プロフェッショナルもカスタマー志向であるべきだという風潮がありますが、やはり、プロフェッショナルは誇りをもって（もちろん、決して奢ることなく）クライアントの満足度を上げることが大切だと思います。

システム利用（システムライフサイクルの監査）のチェックリスト その3

システムライフサイクルの監査／システム利用／業務管理／

今回もシステムライフサイクルの「システム利用」のチェックリストの作成に挑戦します。このパートのチェックの観点は「金融機関等のシステム監査指針」（FISC）によるものです。

  必要な統制

1. 権限リスト
2. 決済記録
3. 入退出カード、端末キー、ユーザーID等の管理台帳
4. 異例処理記録
5. 社外持ち出し用パソコン等一覧
   

  チェックリスト

（青字はコメント）

    3．業務管理

1. 端末機等の操作に係る担当者ごとの権限が明確にされているか
• 権限リストを確認
  
2. 特に特定業務（責任者の代行業務等）に係る操作権限の付与については、責任者の任命により行われているか
• 権限リストから代行状況を確認
  
3. 端末機等の操作にあたっては、担当者の取引権限の範囲に従って処理されているか
• 決済記録と権限リストを照合し確認
  
4. 入退出カード、端末キー、ユーザーID等の管理責任者が、任命されているか
• 入退出カード、端末キー、ユーザーID等の管理台帳を確認
5. ユーザーIDの管理が適切に行われているか
• ユーザーIDの管理ルールを確認
• ユーザーIDの管理記録と管理ルールを照合し確認
  
6. 入退出カード受入簿を作成し、維持管理しているか
• 入退出カード、端末キー、ユーザーID等の管理台帳に受入状況が継続して記載されていることを確認
7. 入退出カード貸与記録を作成し、貸与を受けた者の受領証跡を残しているか
• 入退出カード、端末キー、ユーザーID等の管理台帳に貸与記録と受領証跡があることを確認
8. 端末機離席時にログオフしているか
• 離席時のログオフ状況を実査して確認
• 人依存であり有効な統制がなければ監査は現実的ではない
  
9. タイムアウト機能がある場合、設定時間等の条件が設定されているか
• タイムアウトの設定内容を実査して確認
  
10. 入退出カードの貸借がないか
• 入退出カード保持者が本人であることを確認
• 人依存であり有効な統制がなければ監査は現実的ではない
  
11. 転出・退職等に際しては、入退出カードは定められた方法で回収されていること
• 転出・退職時の処理フローに回収方法があることを確認
• 定められた回収方法どおり回収されていることを確認
  
12. 日々の取引内容が記録され参照・検証可能であること
• 取引ログの存在と参照可能な状況であることを確認
  
13. 異例処理が管理されているか
• 異例処理記録が存在していることを確認
  
14. 業務終了後は、施錠等により端末機器及び関連機器が使用できないようになっているか
• 業務終了後に施錠等を実査して確認
  
15. 社外持ち出し用パソコン等は、その利用形態に応じたセキュリティ対策が検討されているか
• 社外持ち出し用パソコンのセキュリティー対策を実査して確認
  
16. 社外持ち出し用パソコン等の一覧が作成され、取扱者と識別IDが記載されているか
• 社外持ち出し用パソコン等一覧の存在を確認
• 社外持ち出し用パソコン等一覧から取扱者と識別IDが記載されていることを確認
17. 社外持ち出し用パソコン等の台数は、定期的に照合されているか
• 社外持ち出し用パソコン等一覧から照合の日付けを確認
18. 社外持ち出し用パソコン等のパスワードは、定期的に変更されているか
• パスワードを定期的に変更する旨の通達を行っているか確認
  
• パスワードを強制的に変える仕組みが必要
  
19. 社外持ち出し用パソコン等の取扱者割当は、人事異動等必要に応じて変更されているか
• 人事異動等の処理フローに社外持ち出しパソコン等の取扱者割当を変更する手続があることを確認
• 社外持ち出し用パソコン等一覧が定められた手続どおり変更されていることを確認
  
20. 社外持ち出し用パソコン等の盗難、紛失に際しての緊急連絡方法や連絡先が定められ、周知徹底されているか。
• 盗難・紛失時の対応マニュアルが存在することを確認
• 利用者が対応マニュアルを所持していることを実査して確認
  

金融機関特有の項目は割愛しました。「渉外用パソコン等」は「社外持ち出し用等」に読み替えています。
来週から、情報セキュリティ（情報セキュリティマネジメント態勢、建物・設備等の安全対策、アクセスコントロー）に入ります。

システム利用（システムライフサイクルの監査）のチェックリスト その2

システムライフサイクルの監査／システム利用／ユーザー業務手続とマニュアル／

今回もシステムライフサイクルの「システム利用」のチェックリストの作成に挑戦します。このパートのチェックの観点は「金融機関等のシステム監査指針」（FISC）によるものです。

  必要な統制

1. 規程集・通達・マニュアル一覧

  チェックリスト

    2．ユーザー業務手続とマニュアル

1. ユーザー業務に係る各種手続（規程集や通達等）・マニュアルの管理責任者が定められているか
• 規程集や通達、マニュアルに管理責任者が記載されていることを確認
  
2. ユーザー業務に係る各種手続・マニュアルが備え付けられているか
• 規程集・通達・マニュアル一覧をもとに、規程集や通達、マニュアルが備置されていることを確認
  
3. 各種手続・マニュアルは、内容が最新のものに更新されているか
• 規程集や通達、マニュアルの更新日付けを確認
4. 各種手続・マニュアルは、それぞれの担当者が常に利用できるようになっているか
• 規程集や通達、マニュアルの掲出場所を確認
5. 所管部署が定める手続・マニュアルに対して、支店固有の事由（人員構成、端末構成、配置、その他システム上の理由等）と照らし合わせ、支店での手続・マニュアル作成の必要性が検討されているか
• 支店独自の規程集や通達、マニュアルに策定理由が記述されていることを確認
6. 支店での手続・マニュアルを作成する場合は、必要に応じて所管部署の承認を得ているか
• 所管部署の承認状況を確認
• 所管部署に作成の是非を確認
  

「自店」は「支店」に読み替えました。次回も引き続きシステム利用（システムライフサイクルの監査）のチェックリストを作成します。

システム利用（システムライフサイクルの監査）のチェックリスト その１

システムライフサイクルの監査／システム利用／運営と要員管理／

今回はシステムライフサイクルの「システム利用」のチェックリストの作成に挑戦します。このパートのチェックの観点は「金融機関等のシステム監査指針」（FISC）によるものです。他の項目とバランスをとるため、一部項目を省略しています。

  必要な統制

1. 記憶媒体等の管理台帳
2. PC管理台帳
3. 勤怠記録
   
4. 入退出記録
5. システム教育記録
6. ITスキル記録
   

  チェックリスト

5．システム利用

1. 運営と要員管理
   
1. ユーザー部門において、情報システムの利用に係る責任者が定められ、情報システムの利用促進が図られているか
   
• 組織図・業務分担表にて情報システムの利用に係る責任者を確認
  
• 部署内の会議記録等から情報システムの利用促進活動が行われていることを確認
• 情報システムの利用案内が掲示されていることを確認
  
2. ユーザー部門等において、情報システムに係る操作性の評価、操作権限における問題の把握、等の取り組みが行われているか？
• 保守手順書が規模・期間・システム特性毎に記載されていることを確認
3. 記憶媒体、鍵・カード、ユーザーID等の管理の検査項目が定められ、検査が行われているか
• 記憶媒体、鍵、カードの管理方法とチェック方法を確認
• 各管理台帳でチェックの実施状況を確認
  
4. 事務量に応じた適切なユーザー数や機器台数が把握されているか
• PC管理台帳にてPCの台数および配備先の管理状況を確認
  
5. 長期間、特定のユーザーに同一の業務をさせない等、相互牽制を考慮した管理が行われているか
• 組織図・業務分担表を時系列で確認し、不正の発生しやすい業務について業務ローテーションが実施されていることを確認
  
6. 恒常的に残業の多いユーザーがいないか
• 勤怠記録から恒常的に残業の多いユーザーを確認
  
7. 最終退出者及び退出時刻が把握されているか
• 入退出時刻が記録されていることを確認
  
8. システム関連機器の操作習熟のための教育が実施されているか
• IT教育記録から操作習熟教育の実施状況を確認
  
9. ユーザーのスキルレベルや習得状況が把握されているか
• ITスキル記録を確認
  
10. 本番システムのオペレーション教育は、本番環境を損なわないように教育用システムや端末により行われているか
• 教育用・テスト用のシステムの存在を確認
  

FISCのシステム利用のチェックポイントにはBCP関連等の項目を多く含んでいました。今回の整理では別にBCP関連の項があるので割愛しています。次回は「5.システム利用」その2です。

保守・廃棄（システムライフサイクルの監査）のチェックリスト

システムライフサイクルの監査／保守／
システムライフサイクルの監査／廃棄／
  
今回はシステムライフサイクルの「保守」と「廃棄」のチェックリストの作成に挑戦します。引き続き、チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。

  必要な統制

1. 保守手順書
2. プログラミング検証記録
3. 廃棄計画書
4. 廃棄申請書
   

  チェックリスト

6．保守

1. 保守計画
1. 変更依頼書等に対して、保守の内容および影響範囲の調査、分析が実施されているか
• 保守手順書に変更依頼書等に対する保守内容と影響範囲の調査・分析手順が記載されていることを確認
• 変更依頼書の管理台帳から保守手順どおりに変更依頼書が処理されていることを確認
  
2. 保守手順は保守の規模、期間、システム特性等を考慮して決定されているか
• 保守手順書が規模・期間・システム特性毎に記載されていることを確認
2. 保守の実施
1. システム設計書、プログラム設計書等は、保守計画に基づいて変更されているか
• 保守手順書にシステム設計書、プログラム設計書等に保守計画を反映する手順が記載されていることを確認
• システム設計書・プログラム設計書等に保守計画が反映されていることを確認
  
2. プログラミングの検証は、変更したプログラム設計書に基づいて実施されているか
• プログラミング検証記録から検証の元になったプログラム設計書を確認
  
3. 変更したプログラムは、影響範囲を考慮してテストが実施されているか
• プログラムの検証記録にテストの影響範囲が記載されていることを確認
  
4. 保守担当者と運用担当者とで職務分離がされているか
• 組織図・業務分担表にて保守担当者と運用担当者が分かれていることを確認
  
3. 移行
1. 変更前のプログラムおよびデータのバックアップが取得されているか
• バックアップされた変更前のプログラムおよびデータを確認
  

7．廃棄

1. 廃棄計画
1. 廃棄計画はリスクを考慮して策定されているか
• 廃棄計画書に想定されるリスクと対応が記載されていることを確認
  
2. 廃棄
1. 廃棄は、ユーザー、運用、保守の責任者の承認を得ているか
• 廃棄申請書にてユーザー、運用、保守の責任者の承認を確認
2. 廃棄方法および廃棄時期は、不正防止、機密保護の対策を考慮して決定されているか
• 廃棄申請書に廃棄方法および廃棄時期の決定理由が記載されていることを確認

保守と廃棄にもドキュメントが必要ですね。次回はFISCのみのため飛ばしていた「5.システム利用」について整理します。

運用（システムライフサイクルの監査）のチェックリスト

システムライフサイクルの監査／運用／

今回はシステムライフサイクルの「運用」のチェックリストの作成に挑戦します。引き続き、チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。

  必要な統制

1. 運用オペレーションマニュアル
1. 運用スケジュール
2. 運用手順・運用管理ルール
3. 入出力データの管理手順、管理方法
   
2. オペレーションの記録
3. システムの稼動記録
4. 障害記録
5. プロジェクト報告書
   
6. プロジェクト管理のデータベース
   

  チェックリスト

1. 運用管理
1. 運用オペレーション・マニュアルが作成され、運用スケジュール、運用手順が明確にされているか
• 運用オペレーション・マニュアルの存在を確認
• 運用オペレーションマニュアルに運用スケジュール、運用手順が明記されていることを確認
  
2. 処理の優先順位、実行時期等を考慮して処理スケジュールが作成されているか
• 運用オペレーション・マニュアルの運用スケジュールに優先順位や実行時期に関する情報が記載されていることを確認
  
3. オペレーションは、運用スケジュール、オペレーション指示書にしたがって行われているか
• オペレーション記録を確認し、オペレーションが、運用スケジュール、オペレーション指示書にしたがっていることを確認
  
4. 例外処理のオペレーション、オペレーターの交替、オペレーション記録の保管は、運用管理ルールに基づいて実施されているか
• オペレーション記録を確認し、例外処理のオペレーション、オペレーターの交替が運用管理ルールに基づいていることを確認
• オペレーション記録が運用管理ルールに基づいて保管されていることを確認
  
5. 入出力データの管理手順、管理方法が明確になっているか
• 運用オペレーションマニュアルに入出力データの管理手順、管理方法が記載されていることを確認
  
6. システムの稼動実績を把握し、性能を管理しているか
• システムの稼動記録が存在することを確認
• 稼動記録に性能の管理項目があることを確認
  
7. 障害・災害発生時の業務処理・対応策、復旧手順・復旧作業、連絡・運用体制が明確にされているか
• 運用オペレーションマニュアルに障害・災害発生時の対応が記載されていることを確認
  
8. 定期的に障害発生状況の分析を行い、再発防止策が図られているか
• 障害記録の存在を確認
• 運用管理部署のミーティング記録を確認し、障害発生状況の分析と再発防止策の検討が実施されていることを確認
  
2. プロジェクトの評価
1. 開発されたシステムの提供機能に対する評価が実施されているか
• プロジェクト報告書に開発されたシステムの提供機能に対する評価の記載があることを確認
2. システム投資に対する効果の観点から評価が実施されているか
• プロジェクト報告書にシステム投資に対する効果の評価が記載されていることを確認
  
3. 品質管理、進捗管理、コスト管理等プロジェクトの運営の観点からの評価が実施されているか
• プロジェクト報告書に品質管理、進捗管理、コスト管理等プロジェクトの運営の観点からの評価の記載があることを確認
4. 開発期間、開発工数、開発コスト等の数値データが収集され、計画と実績との差異分析が行われているか
• プロジェクト報告書に計画と差異分析結果の記載があることを確認
  
5. 評価結果からの教訓等がデータベース化され、以後のプロジェクトでの、参考値として容易に利用可能となっているか
• プロジェクト管理のデータベースに教訓等の情報が登録され、参照可能であることを確認

特に運用については、記録等、管理するための仕組みが構築されていないと監査が難しいと感じました。
次回は、「保守」と「廃棄」です。

イー・モバイルの機種変更

イー・モバイルのケータイ電話を持っているのですが、これをPocket WiFiという3G一体型モバイルWiFiルーターに機種変更してみようかなと思い、しばらく前にサポートへ問い合わせてみました。
そして、週末に以下の返事がありました。

> 大変恐縮ではございますが、

> 音声通話対応の弊社携帯電話につきましては
> データ通信端末とは異なる規格のEM-chipを利用しているため、
> 新規お申し込みとなり、現在ご利用の端末からの機種変更、
> ならびにご契約の変更は承っておりません。

 

chipが違うから新規になるという一般消費者には理解することが非常に難しい理由で機種変更できないみたいです。解約の手続きでも何かと話題になるイー・モバイルさんですが、なかなか不思議なキャリアです。。。

SEO対策について

SEO（=Search Engine Optimization）という言葉があります。
Googleなどの検索結果が上位になるように工夫することです。
検索サイトのランキングのアルゴリズムを研究し、対応することで上位にランクされるようになるそうです。

当然ながら、当ブログは特にSEO対策をしていません。ｗ

試しに、Googleで以下キーワードを検索をしてみました。

1. 「IT監査」⇒何とか、2ページ目に出てきました。
2. 「経営学　IT監査」⇒当ブログが2位でした。
3. 「CIA　IT監査」⇒にほんブログ村の当ブログ紹介が1位、当ブログが2位でした。
4. 「監査論　IT監査」⇒にほんブログ村の当ブログ紹介が1位、当ブログが2位でした。

おー、意外にもSEOできていました！

マメな更新が奏功したのでしょうか。お金をかけてSEO対策を講ずるよりも、コンテンツの充実が大切なのかも知れません。

開発その2（システムライフサイクルの監査）

システムライフサイクルの監査／情報戦略／移行／
システムライフサイクルの監査／情報戦略／プロジェクトマネジメント／

今回はシステムライフサイクルの「開発」のチェックリスト作成の後半です。引き続き、チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。今回は、「移行」と「プロジェクトマネジメント」です。

1. 設計
2. プログラミング
3. テスト
4. 移行
   
5. プロジェクト・マネジメント

  必要な統制

1. 移行手順書
2. プロジェクトマネジメント資料
   

  チェックリスト

    4．移行

1. ユーザーを含めた移行の体制・役割、移行スケジュールは明確にされているか
• 移行手順書に移行の体制・役割、移行スケジュールが記載されていることを確認
2. 移行の妥当性確認方法、移行完了の判定基準は明確にされているか
• 移行手順書に移行の妥当性確認方法、移行完了の判定基準が記載されていることを確認
3. サービス・イン判定基準、判定プロセスは妥当か
• 移行手順書にサービス・イン判定基準、判定プロセスが記載されていることを確認
• サービス・イン判定基準、判定プロセスの根拠を確認
4. 移行のコンティンジェンシープランは策定されているか
• 移行手順書にコンティンジェンシープランが記載されていることを確認
  
5. 開発されたシステムを正しく利用できるように、ユーザー研修が実施されているか
• ユーザー研修の実施記録を確認
  

    5．プロジェクト・マネジメント

1. 進捗遅延等の問題発生に対する対策が講じられているか
• プロジェクトチームのミーティング記録から対策検討の実施を確認
  
2. 必要に応じてユーザーが品質の確認に参加しているか
• プロジェクトチームのミーティング記録からユーザーが品質の確認に参加していることを確認
• 参加していない場合はその理由を確認
  
3. プロジェクト推進過程で新たなリスクが予想される場合、リスク予防策もしくは不測事態計画が追加されているか
• プロジェクトチームのミーティング記録からリスク予防策・不測事態計画が検討されていることを確認
• プロジェクトマネジメント資料に追加施策が反映されていることを確認
  
4. フェーズごとの実績から、システム完成時のコストを予測しているか
• プロジェクトマネジメント資料にコスト予測が記載されていることを確認
  
5. 予算に対して実績が大きく超過するような場合、原因分析の上、対策が講じられているか
• プロジェクトチームのミーティング記録から予算超過の原因分析や対策検討が実施されていることを確認
  
6. 要員数だけではなく、投入する人材のスキルを勘案した要員計画が策定されているか
• プロジェクトマネジメント資料にリソースのスキルに関する記述があることを確認
  
7. プロジェクト・チームのメンバーの役割と責任権限が明確にされているか
• プロジェクトマネジメント資料からプロジェクトの体制を確認
  
8. 変更実施が、直接的な関わりをもつかもしくはその影響を受けるすべての関係者に知らされているか
• プロジェクトチームのミーティング記録から変更に関する伝達が行われていることを確認
  
9. プロジェクト・チーム内で、問題指摘、問題共有がされているか
• プロジェクトチームのミーティング記録から問題の指摘・共有が行われていることを確認
  
10. 必要かつ正確な情報が、タイムリーに開示されているか
• プロジェクトチームのミーティング記録からミーティングが適時に開催され、情報伝達がなされていることを確認

開発の監査を行うにはSEの人たちが作成・使用しているドキュメントに何があるかを知る必要があると思いました。次回から「運用」の監査に入ります。

開発その１（システムライフサイクルの監査）

システムライフサイクルの監査／開発／設計／
システムライフサイクルの監査／開発／プログラミング／
システムライフサイクルの監査／開発／テスト／

今回はシステムライフサイクルの「開発」のチェックリスト作成に挑戦します。チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。開発の構成は、

1. 設計
2. プログラミング
3. テスト
4. 移行
   
5. プロジェクト・マネジメント

となっています。今回は１．設計と２．プログラミング、３．テストについてチェックリストの作成に挑戦します。

  必要な統制

1. 要求仕様書
2. プログラム仕様書
   
3. プログラミングルール
   
4. テスト仕様書
5. 障害記録

  チェックリスト

1. 設計
1. 入出力仕様、業務処理仕様、セキュリティ仕様、障害・災害対策の検討は、ユーザー要件に基づいて行われているか
• 仕様検討の会議の記録から、入出力仕様、業務処理仕様、セキュリティ仕様、障害・災害対策の検討にユーザー部門の参加があることを確認
2. ピーク時のデータ量を想定した処理時間や応答時間が考慮されているか
• 要求仕様書に、データ量の想定や達成すべき処理時間・応答時間が記載されていることを確認
  
3. 関連するシステムの間のインターフェース、サブシステム間の整合性に関して検討が行われているか
• 要求仕様書に、関連するシステムに関する事項が掲載されていることを確認
  
4. 障害・災害発生時の代替機能、復旧時間、復旧手順・復旧作業等の、障害・災害対策の検討がされているか
• 要求仕様書に、障害・災害発生時の対策と対応基準について記載されていることを確認
  
5. システム設計の成果物が明確になっており、内容について、関係部門によるレビューが行われているか
• プログラム仕様書に、予定成果が記載されていることを確認
• ヒアリング等で関係部門が予定成果について認識していることを確認
  
2. プログラミング
1. プログラミングは定められた標準にしたがって行われているか
• プログラミングルールが存在していることを確認
• 開発部門のミーティング記録からプログラミングルールの確認が行われていることを確認
  
2. プログラム仕様書に基づき、プログラミング内容のレビューが行われているか
• 開発部門のミーティング記録からプログラミング内容のレビュー実施を確認
  
3. プログラム・テストの予想結果は事前に明らかにされているか
• テスト仕様書にプログラムテストの予想結果が記載されていることを確認
  
4. プログラム・テスト・ケースは網羅的に作成されているか
• プログラム・テスト・ケースの選定基準を確認
  
3. テスト
1. ユーザーを含めたテスト体制・役割・テスト・スケジュール、テスト実施項目は明確にされているか
• テスト仕様書に、ユーザーテストの仕様が記載されていることを確認
  
2. テスト結果の検証方法が明確にされているか
• テスト仕様書に、テスト結果の検証方法が記載されていることを確認
  
3. テストの実施には、ユーザーが参加し、ユーザーによるテスト結果の検証が行われているか
• 開発部門のミーティング記録からユーザーの参加と結果検証の実施を確認
  
4. テストで発生した障害は、速やかに原因が分析されているか、また、記録されているか
• 開発部門で管理する障害の記録を確認
  

開発の監査について、監査人にプログラミングそのものの知識を求めるべきではないと思いますが、ソフトウェアの開発工程に関する知識は必要だと思います。

企画（システムライフサイクルの監査）のチェックリスト

システムライフサイクルの監査／企画／

今回はシステムライフサイクルの「企画」のチェックリストの作成に挑戦します。チェックの観点は「ここから始めるIT監査」（社団法人日本内部監査協会編）によるものです。

  必要な統制

1. （案件ごとの）システム企画書
1. 目的
2. 範囲
3. スケジュール
4. 費用対効果
   
2. プロジェクト管理資料
1. スコープ・期待される成果
2. 体制
3. 開発規模・工数
4. コスト
5. スケジュール
   

  チェックリスト

 　（青字はコメント）

1. 企画
1. システムの目的は経営戦略に適合したものか
• システム企画書とIT計画書に記載されている目的が整合しているか確認
  
2. システム化の範囲は明確にされているか
• システム企画書にシステム化の範囲が記載されていることを確認
  
3. 開発対象システムの実現可能性が検討されているか
• システム企画書に具体的なスケジュールが記載されているか確認
4. 費用対効果の算出根拠が明らかにされているか
• システム企画書に案件ごとの費用対効果算出根拠が記載されているか確認
  
2. プロジェクト計画
1. ユーザーの満足度基準が明確にされているか
• プロジェクトのスコープにユーザーの満足度の基準が記載されていることを確認
• ユーザーの求めているものを明確にすることと解釈
  
2. プロジェクトの体制、開発規模・工数、コスト、スケジュールは明確にされているか
• プロジェクト管理資料に体制、開発規模・工数、コスト、スケジュールが記載されていることを確認
  
3. 開発工数・スケジュールで、問題対応、リスク対応等、プロジェクト・マネジメントに係る対応が見積もられているか
• プロジェクトのスケジュールに問題対応、リスク対応等、プロジェクト・マネジメントに係る工数が見積もられていることを確認
4. 進捗管理、変更管理、品質管理、問題管理についての管理方法が明確にされているか
• プロジェクト管理資料に進捗管理、変更管理、品質管理、問題管理の管理方法とアウトプットイメージがあることを確認
5. 必要なスキル、要員数等資源の調達量および時期が明確にされているか
• プロジェクトのスケジュールに要員数等資源の調達量と時期が記載されていることを確認
  
6. プロジェクトの成果が及ぼす影響が明確にされているか
• プロジェクト管理資料にプロジェクトの成果物についての記載を確認
  
7. 各フェーズの開始・完了を確認するための条件が明確にされているか
• プロジェクト管理資料に各フェーズの達成目標と条件の記載を確認
  
8. プロジェクト計画の内容はユーザー部門と合意されているか
• プロジェクトの説明会の実施記録を確認

特に、プロジェクト計画を監査するにはプロジェクトマネジメントの知識が必要であると感じました。次回は「開発」です。

賀詞交歓会に行ってきました

本日、社団法人日本内部監査協会の賀詞交歓会へ行ってきました。
会場は、昨年と同様、地下鉄日比谷線の神谷町からほど近いホテルオークラ東京別館のアスコットホールです。
開宴10分前に到着したのでクロークと受付はかなりの混雑でした。
定刻よりやや遅れて開宴。伏屋会長の挨拶の後、乾杯～歓談という流れで進みます。
昼食時間帯なこともあり、きちんと食事をする立食パーティです。（笑）
昼の会合なのでノンアルコール飲料をもう少し充実させてくれるとありがたいと思います。

参加者をざっと見た感じでは法人会員の方が多いように感じました。
個人のCIAの皆さんの参加が増えればさらに輪が広がるかもしれません。
個人的には、昨年途中から研究会に参加したため、顔見知りの人が増え、お世話になっている方に新年のあいさつができました。年初にこのような機会があることは良いことだと思います。

来年はもっと知り合いが増えるように今年の活動をがんばりたいと思います。

ThinkPad改良！

昨日に引き続き、ThinkPadのお話です。

ハードディスクの残容量が少なくなったので秋葉原の若松通商に行きました。
若松通商ではHDDデータ移行サービスをやってくれます。
早速、ThinkPadを持ち込み、HDDの換装とメモリの増加、そして、調子の悪かったDVDドライブの交換をお願いしました。
残念ながらSSDは品切れだったので今回はHDDです。
移行には特に料金はかかりません。しかも1時間程度で移行完了です。

お昼前に持ち込んで、昼食後に引取りました。
しめて、20,940円（消費税込み）。

この結果、
ハードディスク：60GB→320GB（しかもスピードアップ！）
メモリ：1.5GB→3GB
DVDドライブ：CD-RW, DVD ROM→DVD MULTI RECORDER, CD-RW
に機能アップしました。

不足する機能をたった2万円分補強するだけで、まだまだこのThinkPadは使えそうです。

ハードディスク残容量の危機

今日は三連休中日バージョンです。

購入してからもうすぐ4年になる愛用のThinkPadのハードディスクの残量がわずかになってきました。
「そろそろWindows７を使いたいなぁ」とか 「DVDドライブの具合も少し悪いしなぁ」とか思っていたところに追い打ちをかけるようにハードディスクの残量不足が近づいてきました。

今までの私ならこの機会に新しいPCを買おうとするのですが、今回は地球に優しく（？）ハードディスクのアップグレードに挑戦しようと思います。
というわけで、明日は秋葉原へ行ってきます。 （つづく）

Wiiをネットにつなぐリスクとコントロール

週末なので内部監査を少し離れてネットのリスクの話です。

ニンテンドーのWiiをネットにつないでみました。
一般的な無線LANの接続要領で簡単につながります。
無線LANのセキュリティは今時の安全な接続が可能です。

ネットにつなぐと、Wiiで使えるゲームソフトのダウンロード ができるようになります。
それだけではなく、メールもWebサイトの閲覧もできるようになります。
USBのキーボードも使えるのでPCと同じ感じです。

当然ながら、検索もできます。ちゃんとGoogleで検索できます。
したがって、こんなページも見られます。

爆弾だけではなくアダルトサイトも閲覧できます。

こどもが使うゲーム機でここまでできてしまうのは明らかに危険です。

とりあえず、Webブラウザはペアレンタルコントロール下においてパスワードロックをかけました。（パスワードはたったの4桁です。）

Wii側からもフィルタリングソフト（有料）の案内もありますが、もう少しメーカー側でのガードが必要だと思いました。

情報資産管理～コンプライアンスの方針のチェックリスト

システムライフサイクルの監査／情報戦略／情報資産管理の方針／
システムライフサイクルの監査／情報戦略／事業継続計画／
システムライフサイクルの監査／情報戦略／コンプライアンス／ 

今回は「情報戦略」の「情報資産管理の方針」と「事業継続計画」と「コンプライアンス」のチェックリスト作成に挑戦です。今回で「情報戦略」の項は一旦終了です。

  必要な統制

1. ISMS（情報セキュリティマネジメントシステム）
2. BCP（事業継続計画）／BCM（事業継続マネジメント）
   

  チェックリスト

（青字はコメント）

1. 情報資産管理の方針
1. 情報資産の管理方針及び体制を明確にすること。
• ISMS基本方針を確認
• ISMSマニュアルを確認
  
2. 情報資産のリスク分析を行い、その対応策を考慮すること。
• ISMSの情報資産リスク評価シートを確認
• 考慮とは?
  
3. 情報資産の効率的で有効な活用を考慮すること。
• ISMSの資産ランクと管理策を確認
• 考慮とは？
  
4. 情報資産の共有化による生産性向上を考慮すること。
• ISMSの資産ランクと管理策を確認
• 考慮とは？
  
2. 事業継続計画
1. 情報システムに関連した事業継続の方針を策定すること。
• BCPの方針に情報システムに関する記載があることを確認
  
2. 事業継続計画は、利害関係者を含んだ組織的体制で立案し、組織体の長が承認すること。
• BCPの立案～承認のプロセスを確認
  
3. 事業継続計画は、従業員の教育訓練の方針を明確にすること。
• BCPに従業員の教育訓練の方針が記載されていることを確認
  
4. 事業継続計画は、関係各部に周知徹底すること。
• 関係各部がBCPを閲覧できる状態にあることを確認
• 関係各部員がBCPの内容を理解しているか確認
  
5. 事業継続計画は、必要に応じて見直すこと。
• BCPの見直し状況を確認
  
3. コンプライアンス
1. 法令及び規範の管理体制を確立するとともに、管理責任者を定めること。
• 職務分掌規程にコンプライアンス担当部署と責任者が明記されていることを確認
  
2. 遵守すべき法令及び規範を識別し、関係者に教育及び周知徹底すること。
• 弁護士等の外部専門家からの指導状況を確認
• 社内での法務関連の情報共有の実施状況を確認
  
3. 情報倫理規程を定め、関係者に教育及び周知徹底すること。
• 情報倫理規程とその教育と周知の状況を確認
  
4. 個人情報の取扱い、知的財産権の保護、外部へのデータ提供等に関する方針を定めること。
• ISMSの該当箇所を確認
  
5. 法令、規範及び情報倫理規程の遵守状況を評価し、改善のために必要な方策を講じること
• 顧問弁護士等の外部専門家に法令の順守状況を確認
• 情報倫理規定遵守のモニタリング状況を確認
• 規範が守られていることを確認することは可能か?

今回の項目は一般的なマネジメントシステムがあると対応しやすいと思われる内容が多くありました。マネジメントシステムの構築はIT監査を円滑に進める上でも有効だと思います。

情報化投資のチェックリスト

システムライフサイクルの監査／情報戦略／情報化投資／
 
今回は「情報戦略」の「情報化投資」のチェックリスト作成に挑戦です。
そして、今回もチェックリスト作成前に以下のものが必要だと気付きました。

  必要な統制

1. IT計画書に「情報化投資計画」の項を設定する。

  チェックリスト

　（青字はコメント）

1. 情報化投資計画は、経営戦略との整合性を考慮して策定すること。
• IT計画書の情報化投資計画と経営戦略の整合性を確認
• 全体最適化計画の情報化投資の方針との整合性を確認
  
2. 情報化投資計画の決定に際して、影響、効果、期間、実現性等の観点から複数の選択肢を検討すること。
• 情報化投資計画に選択肢を比較検討した経緯の記載があることを確認
• 個人的にはこの項は公共性のある投資についてのみ必要だと考える
  
3. 情報化投資に関する予算を適切に執行すること。
• 経理部門からの情報化投資に対する予実管理の状況報告を確認
  
4. 情報化投資に関する投資効果の算出方法を明確にすること。
• IT計画書の情報化投資計画に投資効果の算出方法が記載されていることを確認
• 全体最適化計画の投資効果の測定方法との整合性を確認
  
5. 情報システムの全体的な業績及び個別のプロジェクトの業績を財務的な観点から評価し、問題点に対して対策を講じること。
• IT計画書の情報化投資計画が情報システムの問題点を整理した上で投資項目が決定されていることが記述されていることを確認
• 情報システムの業績を財務的な観点から評価するとは何かがわかりにくい
  
6. 投資した費用が適正に使用されたことを確認すること。
• 予定されたシステムの検収・納品の証憑を確認
• 完了の確認と解釈

今回はシステム管理基準の記述に難解な箇所がありました。私なりの解釈をすることでチェックリストを作成しています。

組織体制チェックリスト

システムライフサイクルの監査／情報戦略／組織体制／ 

今回は「情報戦略」の「組織体制」のチェックリスト作成に挑戦します。

  必要な統制

1. 前々回に想定したIT戦略会議に情報システム化委員会を設置する
2. IT計画書に「技術採用指針」の項を設定する
3. 情報システム部門の組織図と担当業務・権限一覧
   

  チェックリスト

1. 情報システム化委員会
1. 全体最適化計画に基づき、委員会の使命を明確にし、適切な権限及び責任を与えること。
• IT戦略会議のチャーターに委員会の使命、権限、責任が記載されていることを確認
2. 委員会は、組織体における情報システムに関する活動全般について、モニタリングを実施し、必要に応じて是正措置を講じること。
• 情報システム化委員会の議事録に情報システム化のモニタリング報告と是正勧告が記載されていることを確認
  
3. 委員会は、情報技術の動向に対応するため、技術採用指針を明確にすること。
• IT計画書に技術採用指針が記載されていることを確認
  
4. 委員会は、活動内容を組織体の長に報告すること。
• 委員会の報告が社長へ提出されていることを確認
  
5. 委員会は、意思決定を支援するための情報を組織体の長に提供すること。
• 委員会の社長への報告提言が盛り込まれていることを確認
  
2. 情報システム部門
1. 情報システム部門の使命を明確にし、適切な権限及び責任を与えること。
• 職務分掌規程に情報システム部門の権限と責任の記載があることを確認
  
2. 情報システム部門は、組織体規模及び特性に応じて、職務の分離、専門化、権限付与、外部委託等を考慮した体制にすること。
• 情報システム部門の組織図を確認
• 情報システム部門構成員の担当業務を確認
  
3. 人的資源管理の方針
1. 情報技術に関する人的資源の現状及び必要とされる人材を明確にすること。
• IT計画書の要員計画には現状の要員と必要とされる人材が記載されていることを確認
  
2. 人的資源の調達及び育成の方針を明確にすること。
• IT計画書の要員計画に人的資源の調達及び育成方針が記載されていることを確認

チェックリストを作成すると必要な体制や計画書の記載するべき事項が具体的になってきました。

全体最適化チェックリストその2

システムライフサイクルの監査／情報戦略／全体最適化計画の策定／

今回は前回に引き続き「全体最適化」のチェックリストを検討します。

検討を進める中で、前回想定したIT計画書には「全体最適化計画」の項が必要だと気付きました。
以降、IT計画書に全体最適化計画が記載されていることを前提にチェックリストを考えます。

  必要な統制

1. 組織図
2. 事業計画書
   
3. 決裁規程
4. IT計画書（以下の項目を網羅する）
1. ITガバナンス図
2. IT計画と経営戦略との関係
3. 情報システム化の目的
4. 情報システム化の影響
5. 全体最適化計画
1. 情報化投資の方針
2. 要員計画
3. 設備投資計画
4. 経費計画
5. 効果測定の方法
6. リスク算定の方法
7. 外部資源の活用について
8. 改訂履歴
   
5. IT戦略会議チャーター（以下の項目を網羅する）
1. 会議体の位置づけ
2. 会議の目的
3. 会議開催要領

  チェックリスト

1. 全体最適化の方針・目標
1. ＩＴガバナンスの方針を明確にすること。
2. 情報化投資及び情報化構想の決定における原則を定めること。
3. 情報システム全体の最適化目標を経営戦略に基づいて設定すること。
4. 組織体全体の情報システムのあるべき姿を明確にすること。
5. システム化によって生ずる組織及び業務の変更の方針を明確にすること。
6. 情報セキュリティ基本方針を明確にすること。
2. 全体最適化計画の承認
1. 全体最適化計画の立案体制は、組織体の長の承認を得ること。
2. 全体最適化計画は、組織体の長の承認を得ること。
3. 全体最適化計画は、利害関係者の合意を得ること。
3. 全体最適化計画の策定
1. 全体最適化計画は、方針及び目標に基づいていること。
• IT計画書の全体最適化計画とITガバナンス図の整合性を確認
• IT計画書の全体最適化計画と経営戦略の整合性を確認
  
2. 全体最適化計画は、コンプライアンスを考慮すること。
• （必要に応じて）全体最適化計画が法務部門のレビューを受けていることを確認
  
3. 全体最適化計画は、情報化投資の方針及び確保すべき経営資源を明確にすること。
• IT計画書の全体最適化計画に情報化投資の方針、要員、設備投資、経費等の経営資源の計画が記載されていることを確認
  
4. 全体最適化計画は、投資効果及びリスク算定の方法を明確にすること。
• IT計画書の全体最適化計画に投資効果の測定方法とリスクの算定方法が記載されていることを確認
  
5. 全体最適化計画は、システム構築及び運用のための標準化及び品質方針を含めたルールを明確にすること。
• IT計画書の全体最適化計画にシステム構築及び運用のための標準化及び品質方針を含めたルールが記載されていることを確認
6. 全体最適化計画は、個別の開発計画の優先順位及び順位付けのルールを明確にすること。
• IT計画書の全体最適化計画に個別の開発計画の優先順位及び順位付けのルールが記載されていることを確認
7. 全体最適化計画は、外部資源の活用を考慮すること。
• IT計画書の全体最適化計画に外部資源の活用計画が記載されていることを確認
4. 全体最適化計画の運用
1. 全体最適化計画は、関係者に周知徹底すること。
• 全体最適化計画が関係者に伝達または関係者がアクセス可能な場所に掲示されていることを確認
• 関係者が全体最適化計画の存在または内容を知っているか確認
  
2. 全体最適化計画は、定期的及び経営環境等の変化に対応して見直すこと。
• 事業計画の変更と全体最適化計画の改訂状況の整合性を確認
• IT戦略会議の議事録で改訂検討状況を確認
  

監査のチェックリストを作ろうとすると、整備すべき資料の構造も決まってきますね。

全体最適化チェックリストその１

システムライフサイクルの監査／情報戦略／全体最適化の方針・目標／
システムライフサイクルの監査／情報戦略／全体最適化計画の承認／

仕事始めとして、システムライフサイクルの監査の要点項目の「情報戦略」の（「の」が多くなってしまった…）「全体最適化の方針・目標」と「全体最適化計画の承認」について詳細化に挑戦してみます。

  必要な統制

1. IT計画書
1. ITガバナンス図
2. IT計画と経営戦略との関係
3. 情報システム化の目的
4. 情報システム化の影響
2. IT戦略会議
1. 会議体の位置づけ
2. 会議の目的
3. 会議開催要領

  チェックリスト

1. 全体最適化の方針・目標
1. ＩＴガバナンスの方針を明確にすること。
• ITガバナンス図を確認
2. 情報化投資及び情報化構想の決定における原則を定めること。
• 情報化構想の決定を行うIT戦略会議の存在と定義を確認
• 決裁規程に情報化投資について規定を確認
3. 情報システム全体の最適化目標を経営戦略に基づいて設定すること。
• IT計画書に情報システム全体の最適化目標と経営戦略の関係が記載されていることを確認
  
4. 組織体全体の情報システムのあるべき姿を明確にすること。
• IT計画書に組織全体の情報システム化方針が記載されていることを確認
  
5. システム化によって生ずる組織及び業務の変更の方針を明確にすること。
• IT計画書に情報システム化の影響について方針が記載されていることを確認
  
6. 情報セキュリティ基本方針を明確にすること。
• 情報セキュリティ基本方針の存在を確認
2. 全体最適化計画の承認
1. 全体最適化計画の立案体制は、組織体の長の承認を得ること。
• IT戦略会議の位置づけを確認
  
2. 全体最適化計画は、組織体の長の承認を得ること。
• 全体最適化計画を社長が承認していることを確認
  
3. 全体最適化計画は、利害関係者の合意を得ること。
• （必要に応じて）全体最適化計画が取締役会等で承認されていることを確認
  

監査のチェックリストを作成していくと、被監査部門に準備しておいて欲しいものが明確になってきます。監査部門と被監査部門の労力が最少になるように必要な調整を進めなければならないと思いました。

心に残る経営者の言葉

冬休み最終日なので少しIT監査を離れて…

月刊監査研究2010年1月号に「原点回帰の経営戦略」という王将フードサービス代表取締役社長軒営業本部長大東隆行氏の第43回内部監査推進全国大会記念講演の内容が紹介されていました。
大東氏は餃子の王将で知られる王将フードサービスの社長兼営業本部長で先代の創業社長から引継ぎ王将を見事に立て直した経営者です。

私も第43回内部監査推進全国大会に参加したものの、仕事の都合により本記念講演を聴くことができなかったため、今回の記事を待ち遠しく思っていました。今回は本講演内容で私が感銘を受けた言葉を紹介します。

1. 先代社長は強引でカリスマ性以上の仕事の鬼みたいな人だったが、ものすごく心に温かみ、想いがあった。それにカリスマ性に重みがあった。軽いカリスマ性では、絶対、人はついてこない。
2. お客さんが入って、「あっ、変わったな」という変化を感じるような改造の仕方をしなければ、数字の変化はでない。
3. 上の者が燃えなくして、何で下が燃えるのか。上の者が伝えなくて、何で下の者に伝わるのかと。（中略）言葉というのは自分の魂、言霊なんだ。
4. 仕事力があっても人間力が乏しければ、絶対、人がついてこない。上の者はファンがいる、柔軟性がある、この人についていったら何かいいことがあるという魅力を持たないといけない。
5. 最初から最良なんか絶対あり得ない。実践して、悪いところを直しながら、それによって最良を目指していく。
6. 本部から管理監督していれば、だんだんぶら下がるものが多くなっていき、本部としてはだんだん重荷になってきて、目が届かなくなっていく。
7. 利益を追って利益を残すのではなく、いい人材を揃えて育て残していったら、勝手に利益を生んでくれる。
   
8. 意見を発表するときに、資料を見て発表しているのなら、それは自分のものにまだなっていない。
9. 会議でも何でも言いやすい者ばかり怒っていても、絶対そこに緊張感は生まれない。
   
10. 会議には1個だけでいいから数字というものを絶対に入れないといけない。そうすることによって目標というものができる。

いかがでしょうか？とても心に響く言葉がたくさんあると思います。一見、内部監査と無関係な気がしますが、内部監査人として、経営者の考えを理解することは非常に重要なことだと思います。

本年もよろしくお願いいたします。

２０１０年になりました。明けましておめでとうございます。

旧年同様、当ブログでは内部監査について私の試行錯誤を記録していきます。
引き続き、我流ではありますが、内部監査関連の知識の整理を通じて読者の皆様にもちょっと役立つブログでありたいと考えています。
今年は特にIT監査について重点的に整理していきたいと思います。

それでは、本年も当ブログをよろしくお願いいたします。