ホーム > fein's bookshelf > Management系

このページの注意点🔻

ネットに公開しているものなのでご覧いただいても構いませんが、次の事項にご留意ください。

• 便宜上、個人サイトのカテゴリーに収まっていますが、サイト制作とは関係ありません。

• パソコンについて書いてありますが、ここをご覧いただいても勉強にはなりません。

• 学生の頃から作ってきた私のデジタルノートをGoogleサイトへ移しているだけなので、情報が古い、ないしは誤っている可能性があります。

• ただの個人的な思い出ページであって情報提供を目的とはしておりませんので、整理もしていません。

関連ノート：Network系 

インターネット上での権利侵害に関連する法律で、特定電気通信役務提供者の損害賠償責任を一定の条件で制限している。
プロバイダ（特定電気通信役務提供者）は、情報の送信を防止する措置を講じなかった場合でも、権利侵害による損害賠償責任が一定の範囲で免責される。
つまり、プロバイダはすべての権利侵害に対して責任を負わないわけではないが、一定の条件を満たす場合には免責される。
権利侵害情報が匿名で発信された場合、被害者はプロバイダに対し、発信者の特定に資する情報（発信者情報）の開示を請求できる。
この仕組みによって、被害者は発信者を特定し、損害賠償請求などの手続きを行うことができる。
このようにプロバイダ責任制限法は、インターネット上での権利侵害に対する対応を明確にし、被害者とプロバイダのバランスを取るための法律となっている。

ソフトウェアの著作権者（ライセンサー）が、他者（ライセンシー）に対してそのソフトウェアの使用を許可する契約。
この契約により、ライセンシーはソフトウェアを合法的に使用する権利を得る。

・使用許諾：
ソフトウェアの使用範囲や期間を定める。

・対価：
使用許諾料の支払い方法や金額を規定する。

・再許諾：
ライセンシーが第三者に使用を許可できるかどうかを定める。

・禁止事項：
ソフトウェアの不正使用や目的外使用を防ぐための規定。

この契約は、ソフトウェアの著作権を保護し、ライセンサーとライセンシーの権利と義務を明確にするために重要となっている。

• 複製権：印刷等によって著作物を複製

• 公衆送信権：公衆からの要求に応じた情報送信

• 貸与権もしくは頒布権：著作物のコピーを貸し出す

著作者人格権は著作権とは別の、著作者が有する権利。公表権・氏名表示権・名誉声望保持権・同一性保持権（自らの意思に反して著作物を変更，切除されない）がある。

●著作権とWebサイト
Webサイトの文章や画像などのコンテンツを無断で転載して公開するなどした場合、転載元の著作権を侵害したことになる。
ただし、WebサイトのURLを列挙して解説したリンク集はサイト選び等に作成した人の考え方が表現されているとみなされるため、著作物となる。

情報システムの脆弱性に対するオープンで包括的な評価手法。
脆弱性の深刻度を定量的に比較し、共通の基準で評価できるように設計されている。
セキュリティ専門家、ベンダー、管理者、ユーザなどが共通の言葉で脆弱性について議論できるようにするための有用なツールである。

CVSSは以下の3つの基準で脆弱性を評価する。

１．基本評価基準 (Base Metrics)：
脆弱性そのものの特性を評価する。
機密性、完全性、可用性の影響をネットワークから攻撃可能かどうかといった基準で評価し、CVSS基本値 (Base Score)を算出する。
この基準は脆弱性の固有の深刻度を表すために使用される。

２．現状評価基準 (Temporal Metrics)：
脆弱性の現在の深刻度を評価する。
攻撃コードの出現有無や対策情報の利用可能性などを考慮して、CVSS現状値 (Temporal Score)を算出する。
この基準は脆弱性の現在の状況を表すために使用される。

３．環境評価基準 (Environmental Metrics)：
ユーザの利用環境を含め、最終的な脆弱性の深刻度を評価する。
脆弱性の対処状況を考慮して、CVSS環境値 (Environmental Score)を算出する。

この基準はユーザが脆弱性への対応を決めるために使用される。

独立行政法人情報処理推進機構 (IPA)が設立した組織で、標的型サイバー攻撃 (APT)に対する被害拡大防止のための支援活動を行っている。

企業や公的機関からの相談を受け付け、被害の把握や防止策の提案を行っている。

J-CRATは、ウイルス感染や不正アクセス、情報漏洩などの被害を受けた組織や個人を対象に、専用窓口を通じて相談を受け付け、必要な支援活動を展開している。

日本の政府機関が運営する暗号技術の評価・監視・運用を目的としたプロジェクト。次のような役割を果たしている。

＜暗号技術の評価とリスト化＞
安全性と実装性に優れる暗号技術を客観的に評価し、推奨リストを作成。
政府機関が利用すべき暗号技術を明確に示している。

＜電子政府推奨暗号リストの公表＞
電子政府における調達のための推奨暗号リストを公表。
情報システムのセキュリティを確保するために適切な暗号技術が選定されている。

＜暗号技術の安全性監視と調査＞
リストに掲載された暗号技術の安全性を監視し、必要に応じて調査・検討を行う。

このプロジェクトは、デジタル庁、総務省、経済産業省、NICT、IPAが共同で運営しており、暗号技術検討会、暗号技術評価委員会、暗号技術活用委員会で構成されている。

企業や組織のコンピュータシステムやネットワークにおけるセキュリティインシデント（情報漏洩、不正アクセス、マルウェア感染など）に対応するチーム。

インシデントの発生を検知し、迅速かつ適切な対応を行うことで、被害の拡大を防ぐ。

情報セキュリティに関するインシデントに対処するための組織、つまりCSIRT（Computer Security Incident Response Team）を構築したい組織向けの参考資料。
JPCERT/CC（日本の代表的なCSIRT）が作成したこの資料は、CSIRTの役割、活動、運用、評価などについて詳しく説明している。
CSIRTとは、組織内の情報セキュリティ問題を専門に扱うチームである。
IT利用の拡大に伴い、情報セキュリティ対策がますます重要となっている。
高度に複雑化したITシステムの利用が一般的になったことで、情報セキュリティの問題はもはやシステム管理者だけの問題ではなく、経営層も積極的に関与しなければならない問題となっている。
CSIRTマテリアルは、組織内CSIRTの理解や構築の実践、実作業、参考資料などを提供している。

・CSIRTの概念と活動内容：
CSIRTがどのような役割を果たすのか、どのような活動を行うのかについて詳細に説明されている。

・CSIRTの枠組み：
CSIRTの構築において考慮すべきポイントや基本的な枠組みについて解説されている。

・マニュアルと情報管理：
CSIRTの運用に必要なマニュアルや情報管理についての指針が提供されている。

・電話応対とPGP：
インシデント対応時の電話応対や暗号化技術（PGP）についてのアドバイスが含まれている。

「SOC」と「CSIRT」は、どちらも組織内のセキュリティ対策を担当するチーム。
しかし役割が異なる。

●SOC (Security Operation Center)
SOCは、組織内のファイアウォールやネットワーク機器、業務アプリケーションのログを取得し、攻撃の兆候を早期段階で見抜くことを目的とした組織。
攻撃が多様化し、高度なセキュリティ知識や経験が求められる昨今では、攻撃を見極めることは容易ではなく、24時間365日、絶え間なく攻撃を監視する必要がある。
また、SOCはネットワークや攻撃の状況を可視化してレポーティングし、必要なセキュリティ対策について提言することも含まれる。

●CSIRT (Computer Security Incident Response Team)
CSIRTは、セキュリティインシデント発生後の対応を目的とした組織。
インシデント発生時にその原因を速やかに解析し、影響の範囲を明確にすることで被害の最小化を目指す。
CSIRT同士が連携してセキュリティ動向について共有し、所属する組織のセキュリティ対策について提言することも重要となっている。

すなわち、SOCは攻撃の「検知」を目的に、CSIRTはインシデントの「対応」を担当する組織と言える。

セキュリティを脅かすインシデント（事故や何かしらのミスに繋がりかねない出来事）が発生した際に即座に対応する高度なセキュリティ専門家である。

その役割は、インシデントの分析と対処方法の検討、関係部署との調整を行うことである。

具体的には、悪意のあるサイバー攻撃によるセキュリティ上の問題に対処し、適切な対策を立てるために高度な専門知識と豊富な経験が求められる。

インシデントハンドラーは、ネットワークスペシャリストや情報セキュリティスペシャリストといった資格を持つ人々であり、その役割は今後ますます重要になると考えられる。

情報処理推進機構（IPA）が主導するサイバー情報共有イニシアティブ。

重要なインフラで利用される機器の製造業者などが参加する情報共有体制となってりう。

具体的には、重工業や重電産業などが含まれている。

・IPAが情報ハブとして、サイバー攻撃に関する情報を集約・分析・共有している。

・2011年に発足し、現在は279組織が参加しており、各年度に数千件の情報提供と共有が行われている。

このイニシアティブは、サイバー攻撃に対する情報共有を促進し、より安全なデジタル社会を築るために活動している。

日本のコンピュータセキュリティに関連する組織で、Japan Computer Emergency Response Team / Coordination Center の略称。

特定の政府機関や企業から独立した、中立で、インターネットのコンピューターインシデントに対応する組織として活動している。日本における情報セキュリティ対策活動の向上に取り組んでいる民間の非営利団体である。

JPCERT/CCは以下のような役割を果たしている。

・インシデント対応の支援：

インターネットを介して発生する侵入やサービス妨害などのコンピュータセキュリティインシデントについて、報告を受け付け、対応をサポートしている。

・情報の収集と発信：

コンピュータセキュリティ関連の情報を収集し、注意喚起や関連情報の発信を行っている。

ISMSは「Information Security Management System」の略で、情報セキュリティマネジメントシステムを指す。

１．情報セキュリティの目的：
ISMSは、情報の機密性、完全性、可用性を維持することを目指す。必要な時に正しい情報を正しい人が利用できるよう、情報そのものやその情報を扱うシステムの安全を守る仕組み。

２．リスクアセスメントと管理：
ISMSは、組織が自らのリスクアセスメントを行い、必要なセキュリティレベルを決定し、プランを立て、資源を適切に配分してシステムを運用するための仕組み。これにより、情報セキュリティを確保し、利害関係者から信頼を得ることができる。

３．規格と認証：
ISMSの要求事項を定めた規格として、JIS Q 27001（ISO/IEC 27001）が存在する。この規格は、組織がISMSを確立し、実施し、維持し、継続的に改善するための指針を提供している。ISMS認証を受けることで、組織の情報セキュリティ能力が内外から評価される。

つまり、ISMSは情報セキュリティを管理するための枠組みであり、組織が情報を適切に保護し、リスクを適切に管理するための仕組みである。

─ JIS Q 27000:2019より引用 ─

JIS Q 27001:2023（JIS Q 27001[ISO/IEC 27001]）は、ISMSの要求事項を定めた規格となっている。
組織がISMSを確立・実施・維持していき、また継続的に改善するための指針を提供する。
ISMSは、セキュリティ体制の整備や信頼性向上に寄与するものである。

「ISO/IEC 27000ファミリー規格」は、情報セキュリティマネジメントシステム（ISMS）に関する国際規格のグループ。これは、情報を保護するための体系的な仕組みを構築するための要件と手引を提供している。

このファミリー規格は以下のようなものから成り立っている。

・ISO/IEC 27001：

ISMSの要件を規定した規格。組織が情報セキュリティを適切に管理するための基本的な要件が含まれている。

・ISO/IEC 27002：

情報セキュリティのベストプラクティスを提供するガイドライン。具体的なセキュリティコントロールや対策について詳しく説明している。

・ISO/IEC 27005：

情報セキュリティリスク管理に関する規格で、リスクアセスメントやリスクトリートメントの手法を提供している。

さらに、ISO/IEC 27010からISO/IEC 27040番台および27100から27110番台にかけて、さまざまな側面に関する規格やガイドラインが含まれている。

情報技術におけるサービスマネジメントシステムの要求事項を規定した規格。

・適用範囲：

この規格は、サービスのライフサイクルの管理を支援するためのサービスマネジメントシステムに関する要件を定めている。つまり、組織が顧客と合意されたサービス要求を満たし、サービス品質を継続的に改善するための仕組みを整備するためのガイドラインとなる。

・リーダーシップとコミットメント：

組織のリーダーシップや方針、役割、責任、権限についても規定されている。組織全体でサービスマネジメントにコミットすることが求められている。

・計画：

リスクと機会へのアプローチ、サービスマネジメントの目的、計画策定についても詳細に記載されている。

・サービスマネジメントシステムの支援：

資源、力量、認識の側面に焦点を当てている。つまり、組織が必要なリソースを適切に配置し、サービスマネジメントをサポートできる体制を整えることが重要である。

JIS Q 20000-1は、ISO/IEC 20000-1:2018に対応した日本の規格として位置づけられており、サービスマネジメントに焦点を当てる組織にとって重要な指針となっている。

情報セキュリティマネジメントシステム（ISMS）に関する規格。

この規格は、組織が情報セキュリティを適切に管理し、リスクを評価し対応するための基盤を提供している。

１．概要と目的：
・JIS Q 27000は、情報セキュリティにおけるベストプラクティスやガイドラインをまとめたもので、国際標準のISO/IEC 27000シリーズと同等の内容を提供している。
・ISMSファミリ規格の一部であり、組織がISMSを確立し、実施し、維持し、継続的に改善するための要求事項を規定している。

２．用語と定義：
・JIS Q 27000は、ISMSファミリ規格で共通して用いている用語と定義について規定している。
・あらゆる形態や規模の組織に適用できる。

３．情報セキュリティの特性：
・機密性、完全性、可用性などの情報セキュリティの特性を定義している。

「JIS Q 27000」は、情報セキュリティマネジメントシステム（ISMS）に関する規格であり、リスクアセスメントについても詳細に記載されている。

１．リスク特定（Risk Identification）：
組織に存在するリスクを発見し、認識し、記述するプロセス。これには、情報資産に対する脅威や脆弱性の特定が含まれ、「リスク源，事象，それらの原因及び起こり得る結果の特定が含まれる」と記されている。

２．リスク分析（Risk Analysis）：
リスクの特質を理解し、リスクレベルを決定するプロセス。リスクの影響度や発生可能性を評価し、リスクの大きさを明確にする。

３．リスク評価（Risk Evaluation）：
リスクが許容可能かどうかを判断するプロセス。リスク分析の結果を基に、リスク基準と比較して評価を行う。

JIS Q 27000において、リスク対応は主に以下の4つの方法で行われる。
これらのアプローチは、組織のリスク管理戦略に応じて選択される。

＜リスク低減 (Risk Mitigation)＞
リスクを軽減するための対策を実施する。具体的な対応策としては、セキュリティ対策の強化、脆弱性の修正、セキュリティポリシーの遵守などがある。

＜リスク転嫁もしくは共有 (Risk Transfer)＞
リスクを他の組織や第三者に転嫁する方法。
例えば、保険を利用してリスクを転嫁することがある。

＜リスク回避 (Risk Avoidance)＞
リスクを避けるために、特定の活動やプロジェクトを中止するか、避ける方法。
リスクが高すぎる場合、プロジェクトを中止することがある。

＜リスク受容 (Risk Acceptance)＞
リスクを認識し、そのまま受け入れる方法。
特定のリスクに対して対応策を講じないことを選択する場合に用いる。
ただし、リスクを受容する際には意図的な判断と文書化が必要となる。

「JIS Q 27000」における否認防止（Non-repudiation）は、主張された事象や処理の発生、およびそれを引き起こしたエンティティを証明する能力を指す。

次のような方法を適切に活用することで、情報セキュリティの一環として否認防止を実現できる。

・デジタル署名：
電子的な文書やメッセージに対して、送信者の身元を確認し、内容が改ざんされていないことを証明する。

・タイムスタンプ：
データが特定の時点で存在していたことを証明するための技術。

・ログの取得と保存：
操作やイベントの記録を確実に行い、その完全性を保つことで、後から否認されないようにする。

情報技術におけるセキュリティ技術の規格で、クラウドサービスに特化した情報セキュリティ管理策の実践の規範を提供している。

この規格は、ISO/IEC 27002に基づいてクラウドサービスの情報セキュリティを適切に管理するための指針を示している。

・クラウド分野固有の概念：

クラウドサービスにおける供給者とカスタマ（利用者）の関係や、情報セキュリティリスクの管理について規定されている。

・情報セキュリティのための方針群：

経営陣の方向性や組織における情報セキュリティの方針についても取り上げている。

・人的資源のセキュリティ：

雇用前、雇用期間中、雇用の終了及び変更における情報セキュリティの観点を考慮している。

・資産の管理：

資産に対する責任や情報分類についても詳細に記載されている。

JIS Q 27017は、クラウドサービスに関わる組織やプロバイダにとって重要なガイドラインとなっており、情報セキュリティのリスク低減と信頼向上に役立つ。

情報セキュリティマネジメントシステム（ISMS）に関する国際規格。具体的には、組織の情報資産を適切に保護し、セキュリティを維持するための要求事項を定めている。

１．概要と目的：

・JIS Q 27001は、組織が自社の情報資産を洗い出し、機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）をバランスよく維持し、改善していくための仕組みを構築することを目的としている。

・国際標準の「ISO/IEC 27001」と対応する国内規格であり、2006年に初版が発行された。

２．ISMSの要件：

・組織がISMSを確立し、実施し、維持し、継続的に改善するための要求事項を規定している。

・また、組織のニーズに応じて調整した情報セキュリティのリスクアセスメントとリスク対応についても定めている。

JIS Q 27001は、情報セキュリティに興味のある組織にとって重要な指針であり、ISMSの運用や改善に役立つ。

個人情報保護を目的として策定された日本産業規格の一つ。

この規格は、さまざまな組織が個人情報を適切に管理するためのマネジメントシステムの要求事項を定めている。

１．個人情報保護の目的：

・JIS Q 15001は、個人情報保護法を踏まえて、組織が作るべきルールや運用方法について記載している。

・個人情報を安全で適切に管理するための標準となることを意図している。

２．適用範囲：

・あらゆる種類・規模の組織が利用でき、認証を取得することができる。

・個人情報を取り扱う組織は、JIS Q 15001を活用して社内体制を整備し、効果的かつ効率的な個人情報管理を行うことができる。

３．期待できるメリット：

・個人情報保護におけるリスクの低減

・個人情報を適切に管理・利用する組織体制の確立

・取引先からの信頼向上

・第三者監査による改善点の発見

・ISO/IEC 27001との組み合わせによる効率的な認証取得とセキュリティ管理体制の確立

JIS Q 15001は、個人情報の管理を強化し、堅実な個人情報保護への取り組みを対外的にアピールする手段としても活用されている。

「リスクについて組織を指揮統制するための調整された活動」とは、リスクを組織的に管理し、損失を回避または低減するプロセスを指す。
以下の4つのプロセスから成立する。

1. リスク特定：リスクを発見し、認識・記述するプロセス

2. リスク分析：リスクの特質を理解し、リスクレベルを決定するプロセス

3. リスク対応：リスクに対する適切な対応策を設計・実施するプロセス

4. モニタリング及びレビュー：リスク管理の効果を評価し、必要に応じて改善策を講じるプロセス

※リスクの特定 → 分析 → 評価 → 対応とする資料もある。

ITシステムの調達プロセスでは、RFIから始まり、RFPを通じて具体的な提案を求め、最終的にRFQで見積りを収集する流れがある。

＜RFP＞
RFPは、情報システムの導入や業務委託を行う際に、発注先候補の事業者に具体的な提案を依頼する文書。
システムの目的、概要、要件、制約条件などが記述されている。
企業や官公庁がITシステムを導入したい場合、RFPを作成して開発業者に「提案してください」と伝えることになる。

＜RFI＞
RFIは、企業や官庁が業務の発注や委託を計画する際に、発注先候補の業者に情報提供を依頼する文書。
ITの分野では情報システムの開発や購入、IT関連業務の委託などを行う前に発行される。
RFIはベンダーから一般的な情報（製品・サービス内容、導入・販売実績など）を収集するために使われる。

＜RFQ＞
RFQは「Request For Quotation」の略で、見積依頼書を指す。
RFPやRFIに似た言葉で、ベンダーに見積りの依頼をする際に使用される。
RFQはRFPやRFIの段階で、具体的な要件が明確になった後に作成される。

JIS Q 20000-1は、サービスマネジメントシステム（SMS）においてPDCA（Plan-Do-Check-Act）サイクルの適用を要求している。
この方法論は、サービスの品質を継続的に改善するためのフレームワークとなっている。

＜PDCAサイクルの各段階＞

PLAN（計画）
サービスマネジメントシステムの確立、文書化、合意
・サービスの目標や方針を設定し、達成するための計画を立てる。
・必要なリソースやプロセスを文書化し、合意する。

DO（実行）
サービスマネジメントシステムの導入、運用
・計画に基づいてサービスを設計、移行、提供する。
・サービスの提供に必要なプロセスを実行する。

CHECK（評価）
サービスマネジメントシステムやサービスに対するレビュー
・サービスのパフォーマンスやプロセスを監視し、測定する。
・設定した目標や方針に対する達成度を評価し、結果を報告する。

ACT（改善）
サービスマネジメントシステムの見直し
・点検の結果に基づいて改善策を実施する。
・サービスの品質を向上させるための継続的な改善を行う。

このPDCAサイクルを繰り返すことで、サービスの品質を維持し、向上させることが可能である。

使用量が増えるにつれて単価が下がる課金方式。使用量に応じて累計の金額の増加が緩やかになる。
例えば、最初の1時間は1分あたり100円、次の1時間は1分あたり80円、その次の1時間は1分あたり50円といった具合である。
この方式は、特に通信サービスやクラウドサービスなどでよく見られる。
例えば、データ通信量が増えると、1GBあたりの料金が安くなるといった形で適用される。
ユーザーは大量に利用するほどコストを抑えることができ、サービス提供者も安定した収益を確保できる。

プロジェクト管理においてタスクのスケジュールや進捗状況を視覚的に表現するためのツール。
縦軸にタスクや担当者、横軸に時間を取って、各タスクの開始日、終了日、期間、進行状況をバーで示す。
プロジェクト全体の進行状況や各タスクの依存関係を一目で把握できるため、効率的なスケジュール管理が可能になる。

アローダイアグラムは、プロジェクトの作業をグラフィカルに表現する。
作業の始点と終点を「ノード」（丸印）で表し、ノードを矢印でつなぐことで作業期間を見積っていく。
矢印は作業の流れを示し、ダミー線は直接関連しない並行作業を示す。
クリティカルパスは、プロジェクトのスケジュール全体に影響を及ぼす作業経路を指す。
クリティカルパス上の作業が遅れると、全体のスケジュールに影響が出る。

アローダイアグラムを用いてクリティカルパスを見つけることができる。
クリティカルパスは、最も時間のかかる経路のことだが、ダミー作業は経路に含まれないことに注意を要する。

情報処理推進機構（IPA）が発行しているソフトウェア取引に関するガイドライン。
ソフトウェアの構想・設計から開発、導入、運用、保守、破棄に至るまでの各工程について、標準的なモデルを示している。
発注者と受注者の間で用語や作業工程の理解を統一し、トラブルを防げる。

システム開発の各工程に関連する6つのテクニカルプロセスの次に、プロジェクトマネジメントと品質保証のプロセスがある。

１．要件定義プロセス：
システムに対する要件を定義し、利害関係者のニーズを明確にする。
システムの目的、機能、性能、制約などを文書化する。

２．設計プロセス：
システムのアーキテクチャや構造を設計する。
ハードウェア、ソフトウェア、ネットワークなどの要素を統合する。

３．実装プロセス：
設計されたシステムを実際に構築する。
プログラムのコーディング、テスト、デバッグを行う。

４．テストプロセス：
システムの品質と正確性を確認するためにテストを実施する。
単体テスト、結合テスト、システムテストなどが含まれる。

５．運用プロセス：
システムの運用・保守を計画する。
インストール、トラブルシューティング、パフォーマンス監視などを行う。

６．退役プロセス：
システムの廃棄や置き換えを計画する。
データの移行、リソースの解放などを実施する。

７．プロジェクトマネジメントプロセス：
プロジェクトの計画、スケジュール、リスク管理、コスト管理などを担当する。
プロジェクト全体の進捗と成功を管理する。

８．品質保証プロセス：
システムの品質を確保するための活動を実施する。
品質基準の遵守、テストの実施、品質改善などが含まれる。

サービスを提供する事業者が契約者に対し、どの程度のサービス品質を保証するかを提示したもの。
通信サービスやホスティングサービス、クラウドサービスなどでよく用いられる。

・提供する IT サービスの品質項目と水準の定義：
利用開始時に双方で合意した文書や契約で、可用性や性能などの品質について規定する。

・補償規定：
サービス品質を実現できなかった場合に、料金の一定割合で返金などの補償を定めることがある。

・定量的な指標：
上限や下限、平均などを数値で表し、測定方法も定義する。例えば、通信速度や障害による平均故障間隔などが含まれる。

利用者は、事前にサービス品質がどの程度保証されるのかを知ることができ、事業者は高品質をアピールしたり、理由を説明することが可能となっている。

＜WBSの作り方＞
・成果物を明確にする。
・成果物に必要な作業を洗い出す。
・作業を構造化する。

プロジェクトの作業を分解して構造化する手法。スケジュール作成の基盤となる。
WBSは、プロジェクトの作業を階層的に要素分解したもので、作業分解図とも呼ばれる。
プロジェクト全体の作業を大きな粒度から小さなタスクに分割し、それらを整理していく。
最終的な成果物（構築するシステム）を作るまでの作業を明確にすることができる。
これを作ることで作業の漏れや重複を防ぎ、作業の優先順位を明確にし、分担しやすくなる。

プロジェクトを実施する際に通過する一連のフェーズから成り立っているのがプロジェクトライフサイクル。
プロジェクトの初期段階は不確実な要素が多く、リスクが高まる。
ステークホルダーの要求も多く影響を受けやすいが、徐々に減少する。
その影響を考慮してプロジェクトライフサイクルを計画することが必要となっている。
プロジェクトの中盤に作業実施フェーズでリソースが多くなり、この中盤をピークに作業人数や工数も減少する。
プロジェクトの終盤ではフェーズの方向変更やエラーの修正が難しい。
初期段階で適切なプロセスを設定することが重要である。

システム監査基準については日本システム監査人協会（SAAJ）が策定したガイドラインがある。
システム監査・管理に関する基準や実践方法を提供しており、2023年8月に公表された「システム監査基準ガイドライン」や「システム管理基準ガイドライン」が含まれている。
政府CIOポータルにもシステム監査基準に関する情報が掲載されている。
こちらで詳細な改訂案や概要を確認することもできる。
基本原則として、システム監査人は被監査部門から独立した立場であるべき。