2016年1月 のアーカイブ

IT資産管理プロセス定義書/ワークフロー:テンプレート

2016年1月27日 水曜日

国際IT資産管理者協会 メンバーフォーラムにアクセスすると、IT資産のライフサイクルを通じた管理プロセスの定義書テンプレートや、ワークフローテンプレートがダウンロード可能です。

その他にも、IT資産管理のベストプラクティスとして世界標準となっている IBPL (ITAM Best Practice Library)などがパブリックフォーラムにて提供されています。

一般従業員向けのIT資産管理教育資料や、IT資産管理者向けのプログラム資料、社内プロジェクトに使える資料などが沢山提供されています。

是非、IAITAM メンバーフォーラムへご登録ください。

メールアドレス会員でも様々な資料が提供されています。

登録は簡単、メールアドレス登録してログインするだけです!

国際IT資産管理者協会 メンバーフォーラム

IAITAM Japan Member’s Forum

http://jp.member.iaitam.jp/

Oracle 製品 Named User Plus などでの注意点

2016年1月27日 水曜日

NUP などのライセンスでは、登録するユーザー数だけではなく、実装されているサーバーのプロセッサ数により最小ライセンスの消費カウントが異なるので注意が必要。

http://www.oracle.com/…/…/e-pl101005-101005a-n-176288-ja.pdf

Oracle Webサイトより引用:
当該製品の最少ユーザー契約数は、当該製品がインストールされるハードウェアのプロセッサ数により異なります。実際のユーザ
ー数が該当するハードウェアの最少ユーザー数を下回る場合は、ハードウェアの最少ユーザー数にくり上げたユーザー数を契約す
る必要があります。詳細については、価格表定義のページの「最少ユーザー数」を参照ください

最少ユーザー数
Oracle 製品を導入するハードウェアに対して最少ユーザー数(Named User Plus)の制限が適用される製品があります。実際のユーザー数が該当するハードウェアの最少ユーザー数を下回る場合は、ハードウェアの最少ユーザー数にくり上げたユーザー数を契約する必要があります。
ライセンス購入後、プロセッサ(CPU)を追加または変更した結果、該当するハードウェアの最少ユーザー数を満たしていない場合は、そのハードウェアに適用される最少ユーザー数に対して、不足分ライセンスを追加購入する必要があります。最少ユーザー数の制限が適用される Oracle 製品は次の通りです。

例えば、10ユーザーしか使用しないからといって10NUP を購入しても4プロセッサのハードウェアに実装すると、1プロセッサあたりの最小ユーザー数が25なので、25x4= 100 ユーザーが最小ユーザー数となってしまう。
つまり、使ってもいない 90ユーザーのライセンス違反となってしまう。

例えば、IBM のサブキャパシティで使用しているつもりでも、サブキャパシティにおけるライセンスの割り当て管理ができていないと、フルキャパシティで勘定され、ハードウェアの最大キャパをベースとしたライセンスの購入が求められます。

このようなことに成らないためには、利用規約ライブラリなどとの自動化された突合・整合化が不可欠となります

資産管理の自動化の成功を左右するのは、CI(構成アイテム)の定義と関係性の管理

2016年1月27日 水曜日

資産管理を効率的、効果的に実施するためには規程・ポリシー/プロセス/手順の策定と、中長期的なロードマップを持った IT資産管理プログラムの運営が必須となる。

プロセスを効率化するには、どのような自動化テクノロジーを使用するかの選択が重要となるが、テクノロジーを導入しただけでは失敗するケースも少なくない。

多くの場合、資産管理の自動化の成功には欠かせない CI(構成アイテム)の定義と、CI の関係性の定義が明確でないことに起因する。

残念ながら CI の関係性は全ての組織で同じというわけではない、契約やソフトウェアライセンスの買い方などにより CI の関係性が異なることから、ツールを導入すればテンプレートでやってくれるというわけではないところが失敗を導く要因となっている。

対策としては、具体的には、ハードウェア、ソフトウェア毎に関係する CI を洗い出し、その関係性をトポロジーマップにして効率的な管理が評価対象のツールで可能かを評価することが大切だ。

CI は、PC ハードウェアに関係するリース契約、保守契約などから、ソフトウェア契約、ライセンス、使用条件などあるが、ソフトウェアの購入形態により、その関係性は異なる。

同じソフトウェアでも異なるライセンス形態の契約を複数保有している場合などは、親 CI となる 「ソフトウェア名称」 に、「ソフトウェア契約」 の子 CI が複数存在し、それぞれの子 CI には付与されたライセンス数の孫 CI となる「ライセンス(使用権)」が存在する。

このライセンス CI は、その条件により割り当てられるデバイス(またはユーザー)紐付られる。

具体的には、MS Office 2010 のボリュームライセンスを各部門で保有し、パッケージやOEM版なども、ある部門では保有している場合などは前述のCI の関係性を管理し、それぞれの契約に紐づき割り当てられたデバイスが特定できなければならない。

これらは、ソフトウェア契約の内容や保有するライセンスの形態により管理するために必要なCI が異なるため、まずは現在の状態を把握し、求められる管理対象となる CI の粒度を定義し、CI 間の関係性を可視化することが必要となる。

サーバー アプリケーションの契約で、コア単位のキャパシティ ライセンスという形態であれば、サーバー ハードウェアの CI は、サーバーの親 CI に、CPU という子 CI、コアという 孫 CI が紐づき、これら孫 CI に割り当てられた「ライセンス CI」 を追跡し、管理する必要がある。

CI を定義し、CI の関係性を定義した上でツール(CMDB やITAM リポジトリ)のテーブル設計と比較し、もとめているレベルの管理が可能かどうかを評価することが重要だ。

IT資産管理システム化の用語:ベースライン

2016年1月27日 水曜日

ベースライン: Baseline

ソフトウェアライセンスの最適化をも視野に入れたIT資産管理システムを構築する際に、システムを運用開始するために必要となるデータを入力し、ベースラインを構築します。
この際のベースラインには以下のデータが必要になります。

①インベントリ/ディスカバリデータ

インベントリデータはインベントリ収集ツールで収集します。
この時に注意すべき点は、必要なデータがIT資産管理業務システム(IT資産管理リポジトリ)と紐付され、自動的に突合・整合化できるようなデータであることです。
インベントリで取得可能な物理識別子(シリアル番号)を論理識別子(資産管理番号)と紐付て自動化します。

サーバー環境の場合は、ILMT や、Oracleサーバーへ直接アクセスや、SAP BASIS へのアクセスにより必要な情報を収集します。これらの情報はいずれも、② の Terms & Condition において設定されるメトリクスと照らし合わせ、コンプライアンスの適合性検証を実施することが求められます。

②契約(購買/保守契約など)、利用規約(Terms&Conditions)発注書情報など保有する資産の正台帳を構成する情報。

③データセンター/サーバー環境のシステム構成情報
アプリケーションサーバーやDB のライセンス割り当て情報

④デバイスライセンス/ユーザーライセンスの割り当て情報

ある特定のソフトウェアメーカーの監査対応だと②に関してはメーカーが持っていて、ユーザーは①を準備することがありますが、実際の運用管理では様々なメーカーに対応し、クライアント環境からデータセンター環境まで製品毎に異なる利用規約を遵守して運用することが求められますので、②を棚卸することが大切です。
また、割り当て情報があって、初めて「変更管理」が可能となりますので、割り当て情報も管理することが大切です。

SAP のライセンス契約、契約交渉は可能か?

2016年1月27日 水曜日

多くのソフトウェアのメーカーにとって今日の市場はすでに成熟しきっている(もちろん、コンプライアンス意識が低いという問題を抱える東欧、アジア、アフリカ諸国は除く先進国の話ではあるが)と考えられている。
そのことから、「既存のユーザーからできるだけ売上をあげる」のは、ソフトウェア・メーカーの常識となっている。
さらに、複雑化するIT環境においては、ライセンスのTerms & Conditions 、つまりライセンス契約の利用規約を常に正確に把握し、コンプライアンスに遵守するというユーザーの義務を遂行することは、必要ではあることは理解していても、非常に困難であることも知られている。

そこで、多くのソフトウェア・メーカーの営業姿勢は、「包括契約の方が、安全ですよ。なんでも利用できるし、安心できて、お得です。」と、非常に高価な契約を勧める。
欧米でもこんな状況で、実際は既に利用していないライセンスを数多く保有していたり、利用価値のない製品のライセンス料を支払っている企業は少なくない。
ここ数年、これらの複雑なソフトウェア・ライセンスの管理や最適化のソリューションがSLO(Software License Optimization)として注目され、複雑なライセンスの利用規約にもとづくメトリクスの管理が可能となり、実際の使用状況が明確に把握できることになったことから、ユーザーは、これらの情報やIT戦略、ソフトウェアの今後の利用、運用戦略情報などを用いて、ソフトウェア・メーカーとの「ライセンス契約の最適化」に動いている。

ソフトウェア・メーカーとしても、実情に合わない製品を無理に押し付けるよりも、今後の「サービス化」の流れが強まる中、ユーザーとの良好なパートナーシップを求む機運も高まり、適切で正確な情報を基にしたユーザーの交渉を受け入れざるを得ない状況になっている。

つまり、強気な SAP のライセンス契約であっても、他のソフトウェア・メーカーの契約同様、「契約は交渉可能」なのである。
これはできません、あれもできません、は交渉の結果として結ぶ「契約」ごとにはあり得ない。

「契約は交渉の結果」であり、すべての契約は交渉が可能である。

欧米では、アメンドや、必要であれば、製品利用やIT戦略のロードマップを基に、既存の契約を終了し、単年度の最適化された契約へ移行するという企業も増加している。

まずは、現状を明確に把握し、戦略、ロードマップに基づいた「あるべき姿」と現状のギャップを識別し、その情報を基に、戦略的な交渉により、契約の最適化が実現可能であるということを欧米の事例から理解することができる。

ちなみに、欧米のリサーチ会社やメディアでは、この議論が数年前からかなり話題になり、いろいろなヒントや、ホワイトペーパーなども発行されている。

IBMのホット、ウォーム、コールド・スタンバイ・サーバーのライセンス管理

2016年1月27日 水曜日

IBM では一般に、温度を使った用語(ホット、ウォーム、コールド)でスタンバイ・サーバーのモデルを定義しています。 『IBM Passport Advantage Distributed Software Licensing Guide(IBM Passport Advantage 分散ソフトウェア・ライセンス・ガイド)』では次のように説明しています。

「コールドおよびウォーム環境では通常、スタンバイ機への実装にエンタイトルメントを別途取得する必要はなく、追加の料金も発生しません。 ホット・スタンバイ環境では、スタンバイのマシンに応じたライセンス・エンタイトルメントを割り当てる必要があります。 スタンバイ・モードで実行されるすべてのプログラムは、たとえ別の企業の場所で実行する場合でも、お客様の制御下になければなりません。 プログラム独自の条件がある場合は、そのプログラムのライセンス情報文書に記載されます。」 

Blog image

「稼働する」という表現には、以下のようなアクティビティが含まれます。 

  • プログラミング 
  • 開発
  • プログラムの保守
  • テスト/稼働試験
  • トランザクションのミラーリング 
  • ファイルの更新
  • プログラム、データ、その他のリソースとの同期(別のマシン、プログラム、データベース、その他のリソースとのアクティブなリンクなど)
  • プログラム、データベース、その他リソース間でのアクティブなホット・スイッチや他の同期スイッチの実行を可能にする、すべてのアクティビティと構成 

注意:IBM のガイドでは、プログラムを高可用性(HA)環境で実行するシナリオではウォーム・スタンバイ・サーバーにライセンス・エンタイトルメントが必要と明確に記載されていますが、必要とされるのはホット・スタンバイと同じフル・ライセンスではなく、部分的なライセンスです。 高可用性シナリオでは「さまざまなテクニック(二重化、ファイルまたはトランザクションのミラーリング、ハートビートの管理、別のマシン/プログラム/データベース/その他のリソースとのアクティブなリンクなど)が使用されるため、プログラムはウォーム環境とホット環境の両方で動作すると考えられます」。 

IBM DB2 高可用性の事例

IBM DB2 スタンバイ・サーバーのライセンス要件は、IBM テクニカルノート:Licensing distributed DB2 10.5 servers in a high availability (HA) environment(高可用性(HA)環境に分散配備された DB2 10.5 サーバーのライセンス管理)に記載されているように、いくつかの要素によって決まります。

  • 所有する DB2 のエディション — 高可用性(HA)の場合、少なくとも DB2 Express ライセンスが必要です。Express-C は HA 環境には使用できません。
  • ライセンス・モデル/メトリック— Limited Use Virtual Server(LUVS)または Fixed Term Server(FTL)ライセンス・オプションの場合、ウォーム・スタンバイ・サーバーに追加の LUVS または FTL ライセンスの購入が必要です。 Authorized User Single Install(AUSI)モデルの場合、DB2 のエディションによってウォーム状態のスタンバイ・サーバーに対して 5 または 25 の AUSI ライセンスを割り当てます。 Terabyte(TB)ライセンスの場合、ウォーム・バックアップ・サーバーは、サーバーのデータベースごとに 1 TB ライセンスが必要です。 またProcessor Value Unit(PVU)ライセンス・モデルの場合、サーバーのプロセッサ構成に関わらず 100 PVU のウォーム・スタンバイ・サーバーのライセンスが供与されます。

高可用性(HA)環境での IBM DB2 のライセンスを取得する場合、コールド・スタンバイ・サーバーのライセンスは必要ありません。 

Blog image 2

(出典:Licensing distributed DB2 10.5 servers in a high availability (HA) environment(高可用性(HA)環境に分散配備された DB2 10.5 サーバーのライセンス管理)

Gartner のツール決定フレームワークを使って適切なソフトウェア資産管理ツールを選ぶ

2016年1月27日 水曜日

Gartner アナリストの Hank Marquis 氏は、最近「Use Gartner’s Tool Decision Framework for SAM to Create Your Roadmap」(Gartner の SAMのためのツール決定フレームワークを使ってロードマップを作成する)というタイトルのレポートを発行しました。このフレームワークでは、IT 資産マネージャーと IT 調達マネージャーが、「6 つの重要な活動」に基づいてさまざまなソフトウェア資産管理(SAM)ツールを比較できるようになっています。Marquis 氏はこの作業で、「同一条件での比較」を実現しようとしています。これらの 6 つの活動は下図に示されており、以下の活動を指します。

  1. 検出:ネットワークに接続している物理デバイスおよび仮想デバイスを識別する
  2. インベントリ収集:データを収集かつ分析し、ハードウェアおよびソフトウェア資産を識別する
  3. 名寄せ:重複または矛盾する情報を取り除き、標準の命名規則を使用する
  4. 突合/整合化:有効なライセンス状態を確立する
  5. 最適化:ライセンス・エンタイトルメントと使用状況のデータを活用してソフトウェア支出を削減する
  6. 共有:一元的な資産管理リポジトリやレポートを介して情報を共有する

Blog image today

ホット、ウォーム、コールド・スタンバイなど、バックアップ・サーバーのライセンス管理

2016年1月27日 水曜日

データセンターのサーバー・ソフトウェアのライセンスの管理は、言うまでもなく非常に困難な課題です。 課題の 1 つは、バックアップ・サーバーに関連したライセンス利用規約と運用環境の管理です。 まず、ホット、ウォーム、コールドというバックアップ・サーバーの「温度」について理解しておく必要があります。 ライセンス要件は、通常、対象となるバックアップの種類に応じて異なります。 また、ライセンス利用規約の内容もメーカーや製品によってそれぞれ異なります。

では、ホット、ウォーム、およびコールド・バックアップ(または「スタンバイ」)サーバーという用語の意味を定義してみましょう。 また、アクティブ・フェイルオーバーやパッシブ・フェイルオーバーとは何かについても確認します。

  • ホット・バックアップ・サーバー(「アクティブ・フェイルオーバー」と呼ばれる場合もある):運用稼働中の本番機サーバーから定期的に更新情報を受信し、運用サーバーがダウンするフェイルオーバー・イベントが発生した場合に、ただちに処理を引き継ぐために常時稼働状態で待機している(ホット・スタンバイ)サーバーです。 プライマリ(本番機)システムとセカンダリ(ホット・バックアップ)システムは同時に稼動することができ、セカンダリ・サーバーへのデータのミラーリングはリアルタイムで行われるので、両方のシステムにはまったく同じデータが存在することになります。 多くの場合、本番機サーバーのライセンスに追加して、ホット・バックアップ・サーバーのライセンスが必要になります。
  • ウォーム・バックアップ・サーバー(「パッシブ・フェイルオーバー」と呼ばれる場合もある):起動はしているが、アイドル状態で「実際の処理」は何もしていないか、バックアップの対象サーバーからの更新情報を受信するために定期的に起動されるサーバーです。 ウォーム・サーバーは、「レプリケーション」や「ミラーリング」によく使用されます。ウォーム(ミラー)サーバーのデータとプライマリ(本番機)サーバーのデータは、完全にはシンクロされていない場合があります。 ウォーム・バックアップ・サーバーのライセンスが必要かどうかは、ベンダー、アプリケーション、対象のライセンス契約によって異なります。
  • コールド・バックアップ・サーバー:障害が発生して、ディザスタ・リカバリ(DR)モードに切り替える必要があるまで、起動されないサーバーです。 通常、コールド・バックアップ・サーバーには、ライセンスを割り当てる必要はありません。

ソフトウェア契約レビュー・チェックリスト

2016年1月27日 水曜日

チェックリストのポイント:
①組織
ライセンシーの定義、終了・移行期間、ジョイントベンチャー、関係組織・内部組織間所有移転、廃棄・ランセンス分割
②ライセンス付与
業務目的、関係組織へのサブライセンシング、ライセンス条件、外部利用
③契約期間
保守契約開始日、受領期間、保証期間
④ユーザーベース・ライセンス
地理的制限、実利用、一人・一ライセンス、ユーザー・ライセンスの再割り当て、権利の定義、利用の定義、システム・ユーザー、人ベースの価格
⑤デバイス・ベース・ライセンス
デバイス種別、仮想デスクトップ、IoT
⑥サーバー・ベース・ライセンス
仮想化サーバー、ホスティング/パブリック・クラウド、ライセンスの再割り当て、バックアップ/DR、開発および試験、マルチコア・プロセッサ、コア:プロセッサ・ファクター、ハードウェア・マイグレーション、プラットフォームの変更、メモリ量
⑦その他のメトリックス
ビジネス・メトリックス、インデックス、対象外組織、トランザクション・メトリックス、例外ピーク
⑧製品リスト
パッケージ変更、後継製品、トレード・イン権利、追加製品、未使用ライセンスの保守契約、ライセンス数の削減
⑨コンプライアンス検証
不当なさぐり、予期せぬ違反、訂正、妥当な告知、SAMプロセス、監査コストの法的責任
⑩関係管理
守秘義務、補償、保険、インセンティブ、サポート・サービス・レベル、完全な契約、一方的な変更、許可のない変更、保守費の増額

ポリシー(社内規程)にはどのような内容が含まれるべきか?

2016年1月27日 水曜日

IT資産管理プログラムの策定には、ガイドラインとなるポリシー(規程)が必要だ。
ポリシー(規程)に対して全社的な合意がなされ、経営者層の理解と承認、支援が行われれば、IT資産管理者の仕事もよりどころができて、よりスムーズに前進できる。

ポリシーが、できるだけ全容をとらえ、複雑すぎず、明確に目的や、責任の所在、役割などをおさえることで、それらを手順におとすことができる。

以下に規程で網羅すべき内容の例をあげる:

 IT 資産管理の範囲と権限
このポリシーは、IT 資産管理者の権限を明らかにし、IT 資産業務部の重要性を明示する。

 エンドユーザーによるデスクトップ、ラップトップ、PDA を含むコンピューターデバイスの
使用についての ポリシー

このポリシーは、コンピューターデバイスを使う個人が、できること、また許可されていないことを示す。エンドユーザーの行動に最終的に責任を負う組織を保護することを目的とし、エンドユーザーのポリシー違反の際の処罰の概要を説明する。

 契約とコンプライアンス権限
契約とコンプライアンス権限に関するポリシーは、契約承認とコンプライアンス関連文書の承認に関する要件と階層的な権限を、明確かつ整合的に定義する。このポリシーは、対象範囲内の文書を種別毎に、簡潔に取り扱わなければならない。ベストプラクティスは、すべての文書化された権限執行と承認を記録する集中型プロセスを維持することである。

 コンピューターハードウェアの調達
このポリシーは、組織がハードウェア調達プロセスを統制できるよう、組織全体の調達プロセスを標準化する。

 ソフトウェアの調達とインストール
このポリシーは、組織がソフトウェアの調達とインストールのプロセスを統制できるよう、組織全体の調達プロセスを標準化する。

 ソフトウェア 倫理規定
ソフトウェア倫理規定は、組織的なソフトウェア購入のユーザーに求められることの要点を明確に説明する。

 違法コピー防止と著作権
違法コピー防止と著作権のポリシーは、著作権保護された物品についての法規制についてユーザーを教育し、違反に対する罰則を概説する。

 サポートされているハードウェア とソフトウェアの 基準、認められた代替物と例外管理
このポリシーは、組織内で基準が用いられること、認められた代替物などの例外の場合の基準の取り扱いを決定する。

 メンテナンス基準
このポリシーは、メンテナンスに含まれるものは何か、どのようにメンテナンスが行われるか、問題が生じた際には誰に連絡すべきか、という組織のメンテナンス基準を概説し、メンテナンス問題発生の対処方法をエンドユーザーに通知する。

 ベンダーコミュニケーションポリシー
ベンダーコミュニケーションポリシーは、ベンダーとのやりとりにおける役割と責務を定義する。具体的には、組織でベンダーとやりとりを許される者がだれで、何をベンダーと協議する権限が与えられているのか、説明する。

 インターネットや他の電子コミュニケーション設備の使用
このポリシーは、組織内でのエンドユーザーによるインターネット使用を決定する。また、ユーザーがアクセスできるサイト、チャットルーム、ショッピングカートや、認められるその他の個人的な使用を規定する。E メールも、このポリシーで規定される。

 外部監査の要求への対応
このポリシーは、外部監査について「何を」「いつ」「誰が」「どのように」対応するのかを概説する。
このポリシーは、監査対応の資格を有し訓練を受けた者(監査対応チーム)に対する対応の統制を制限するため、監査の際にきわめて重要である。

 違法ソフトウェアの排除
このポリシーは、基準を満たさないソフトウェア製品や合法的に購入したことが証明できないソフトウェア製品を排除するという組織の権限について、ユーザーを教育する。

 内部監査
内部監査ポリシーは、内部監査の目的、プロセス、担当者の権限について従業員を教育する。

 損失防止
このポリシーは、組織内のあらゆる損失に関するプロセスを概説する。このポリシーは、また、ハードウェアとソフトウェアが「いかにして」「どこで」「いつ」「誰によって」使用され、組織外に持ち出されるかを、規定する。

 資産廃棄
このポリシーは、「どのように」「いつ」「誰によって」資産が廃棄されるのかを概説する。このポリ
シーは、さらに、廃棄プロセスの際の情報セキュリティを規定する。また、文書要件と組織全体での文書の流れについても概説する。

 在宅勤務ポリシー
このポリシーは、組織のソフトウェアIT 資産とハードウェア IT 資産を使っての在宅勤務を従業員に認める、あるいは要求する、「在宅勤務規定」をカバーする。このポリシーは、ロードできるソフトウェアと認められるハードウェアの変更を明確に規定し、そのような変更を要求、承認、報告する権限を明確に設定すべきである。

 データ管理、バックアップと リカバリー
このポリシーは、エンドユーザーによるデータ管理、バックアップとリカバリーの要件を概説する。このポリシーは、「どのように」「どのくらいの頻度で」「どこに」データをバックアップするのかを規
定し、データのリカバリーが必要な際の措置についてエンドユーザーに説明すべきである。

 リムーバブルストレージデバイスの使用に関するポリシー
このポリシーは、組織内外のリムーバブルストレージデバイスの利用を規定する。このポリシーは、 エンドユーザー向けの情報セキュリティと損失防止情報を含むべきである。

 ポリシーの通知と受諾
これは、エンドユーザーへの新しいポリシーの通知、エンドユーザーによる新しいポリシーの受諾、既存ポリシーのレビューを概説する。

 ベンダー管理 – 交渉ポリシー
このポリシーは、「誰が」「どこで」「いつ」「何を」「どのように」交渉プロセスを執行するのかな
ど、組織の交渉基準を概説する。

 試用ソフトウェア、プロモーションソフトウェアおよび寄贈ソフトウェアの使用
このポリシーは、「無料」ソフトウェアの組織内への導入方法と「無料」ソフトウェアの排除基準を規定する。また、エンドユーザーがアクセスして組織の機器にロードできる修正ソフトウェアについても、規定する。

 貸与機器ポリシー
このポリシーは、「いつ」「どこで」「どのように」「いかなる状況において」貸与機器の使用が認め
られるのか、規定する。

 文書管理保存ポリシー
このポリシーは、保存基準、文書の保存方法と保存場所、全てのIT 資産文書の取り扱いのフロー図など、IT 資産文書の保存を規定し、文書の検索を概説する。

 ワイヤレスデバイス ポリシー
このポリシーは、組織の内外で「誰が」「いつ」「どこで」ワイヤレスデバイスを使用すべきかについて、またそのようなデバイスのセキュリティを概説する。

 情報のプライバシー
このポリシーは、組織の機器のプライバシー保護を概説する。組織は、このポリシーを活用して、所有機器への完全なアクセスを担保し、プライバシーを設定しない。このポリシーは、インターネット使用のプライバシー、遠隔からのプライバシー、プライバシー監査権も規定する場合がある。