新しいシステムの開発を外部に発注することになり、上司や開発会社から「セキュリティ要件も仕様書に入れておいて」と言われたものの、何から手をつけてよいか分からず手が止まっていませんか。ITガバナンス、ISMS、ISO27001、Pマークといった言葉は耳にするものの、それぞれが何のための仕組みで、自分が何を確認すべきかが結びつかない、という方は多いはずです。
セキュリティの個別対策を解説した記事はたくさんあります。しかし、暗号化や脆弱性診断といった用語を断片的に読んでも、「自社が何をどこまでやるべきか」という全体像はなかなか見えてきません。守るべき対象も、責任の所在も、判断軸もはっきりしないまま、開発会社に丸投げしてしまうと、あとから情報漏えいやトラブルが起きたときに困るのは発注者自身です。
この問題を解決する鍵は、セキュリティを「階層」で捉えることです。セキュリティは「組織としての統制の仕組み（ガバナンス）」「情報を管理する仕組み（ISMSやポリシー）」「個別の技術要件」という3つの層からできています。この階層が頭の中にあれば、断片的に見えていた用語がひとつの地図の上に並び、自社が決めること・開発会社に任せること・認証で確認できることを切り分けられるようになります。
本記事では、IT発注を担当する非エンジニアの方に向けて、ITガバナンスと情報セキュリティの全体像をやさしく解説します。ITガバナンスとは何かという出発点から、情報セキュリティの3要素、ISMS・ISO27001・Pマークの違い、発注者が把握すべき認証の見方、そしてセキュリティ要件を整理する基本フレームまでを順に説明します。読み終えたとき、漠然とした不安は「次に何をすればよいか」という具体的な見通しに変わっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ITガバナンスとは何か ― なぜ発注者が理解する必要があるのか
「ITガバナンス」という言葉を聞くと、経営陣や情報システム部門が考えることで、発注を担当する自分には関係が薄いと感じるかもしれません。しかし実際には、システムを外部に発注するという行為そのものが、ITガバナンスの一部です。まずは、この言葉をやさしく言い換えるところから始めましょう。
ITガバナンスをやさしく言い換える
ITガバナンスとは、ひとことで言えば「ITを安全かつ有効に使うために、誰が・何を・どう統制するかを定めた組織の仕組み」のことです。少し堅い表現になりますが、噛み砕けば「ITを場当たり的に使うのではなく、組織として方針とルールを決め、IT活用のあるべき姿に向けて管理していこう」という考え方だと捉えてください。重要なのは、これが一部の担当者の判断ではなく、組織として方針とルールを決めて運用する取り組みだという点です。
このうち、特に情報セキュリティに関わる統制を取り出したものを「情報セキュリティガバナンス」と呼びます。ITガバナンスが「ITをうまく使うための統制全般」だとすれば、情報セキュリティガバナンスは「情報をきちんと守るための統制」に焦点を当てたもの、という関係です。本記事では、発注者が直面しやすい情報セキュリティの観点を中心に話を進めます。
ここで押さえておきたいのは、ガバナンスは「技術」ではなく「仕組み・体制」の話だということです。暗号化やファイアウォールといった具体的な技術は、あくまでガバナンスという大きな枠組みの中で選ばれ、運用される手段にすぎません。発注者が最初に理解すべきなのは、個々の技術ではなく、この「枠組みがある」という事実です。
外部発注はITガバナンスの一部 ― 「丸投げ」では責任は移らない
システム開発を外部の会社に依頼すると、技術的なことはすべて開発会社が引き受けてくれるように感じます。しかし、ITガバナンスの観点では「外部委託先をどう選び、どう管理するか」も統制の対象です。つまり、発注という行為自体がガバナンスの一部であり、発注者はその当事者なのです。
ここで重要なのが、「セキュリティはお任せします」という丸投げが通用しない理由です。開発を委託しても、扱う情報の主体（顧客情報を集め、利用する立場）は発注者である自社のままです。後ほど詳しく触れますが、情報漏えいなどのトラブルが起きたとき、委託先を選び監督する責任は発注者に残ります。作業を委託することはできても、責任そのものを委託先に移すことはできません。
だからこそ、発注者がセキュリティの全体像を理解しておく必要があります。すべての技術を自分で判断する必要はありませんが、「何を決め、何を任せ、何を確認するか」を切り分けられる程度の理解は、発注者自身を守るために欠かせません。この記事の以降のセクションは、その理解を組み立てるための土台です。
情報セキュリティの3要素（CIA）― 守るべき対象を3つの視点で捉える
「セキュリティ要件」という言葉が漠然と感じられる大きな理由は、「そもそも何を守るのか」が見えていないことにあります。情報セキュリティの世界では、守るべき性質を3つの視点で整理します。これを情報セキュリティの3要素、または頭文字を取って「CIA」と呼びます。
機密性・完全性・可用性をやさしく理解する
CIAとは、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の3つを指します。難しそうに見えますが、業務に置き換えればすぐにイメージできます。
- 機密性: 見られてはいけない人に情報を見せないこと。たとえば顧客の個人情報を、権限のない社員や外部の第三者が閲覧できない状態を保つことです。
- 完全性: 情報が正しいまま保たれ、勝手に書き換わらないこと。たとえば請求金額や在庫数のデータが、改ざんや操作ミスで誤った値にならない状態を指します。
- 可用性: 必要なときに情報やシステムを使えること。たとえば営業時間中に業務システムが止まらず、担当者がいつでもデータにアクセスできる状態です。
セキュリティと聞くと「情報を見せない」という機密性ばかりが思い浮かびますが、データが正しいこと（完全性）、使いたいときに使えること（可用性）も同じくらい重要です。3つそろって初めて「情報が守られている」と言えます。
3要素はトレードオフ ― 自社が何を優先するかを決める
CIAの3要素は、いつも仲良く両立するわけではありません。たとえば機密性を極端に高めて、アクセスのたびに何重もの認証を求めれば、使い勝手が悪くなり可用性が下がります。逆に、誰でもすぐ使えるよう可用性を優先すれば、機密性が犠牲になりがちです。3要素はトレードオフの関係にあり、どこにバランスを置くかは、扱う情報やシステムの性質によって変わります。
発注者にとって大切なのは、「自社が発注するこのシステムでは、どの要素を特に重視するか」を言語化することです。たとえば、顧客の機微な個人情報を扱うなら機密性が最優先になります。一方、社内の問い合わせ受付システムなら、多少のアクセス制限の緩さよりも、止まらず使えること（可用性）が重視されるかもしれません。
この「どの要素を重視するか」という判断は、開発会社が代わりに決められるものではありません。業務をいちばん理解している発注者にしか決められない部分です。CIAという3つの軸を持つことが、漠然としたセキュリティ要件を具体化していく最初の一歩になります。
ISMS・ISO27001・Pマークとは ― 違いを発注者目線で整理する
セキュリティの話題で必ず登場するのが、ISMS・ISO27001・Pマークという3つの言葉です。似たような場面で使われるため混同しがちですが、それぞれ役割が異なります。ここで違いをはっきりさせておくと、開発会社や委託先の体制を評価する際の判断材料になります。
ISMSとISO27001 ― 「仕組み」と「規格・認証」の関係
まずISMS（Information Security Management System、情報セキュリティマネジメントシステム）とは、組織が情報セキュリティを継続的に管理するための「仕組み」そのものを指します。技術的な対策だけでなく、ルールづくり、教育、運用、見直しといった一連の活動を組織として回していく枠組みのことです。
一方ISO27001は、そのISMSをどう構築・運用すべきかを定めた国際規格の名称であり、第三者機関がその規格に適合していると認めた場合に与えられる認証の名称でもあります。つまり、ISMSが「仕組み」、ISO27001が「その仕組みの良し悪しを測る国際的なものさし（規格）と、それに合格した証明（認証）」という関係です。
実務の現場では、ISMSとISO27001はほぼ同じ意味で使われることが多く、「ISMS認証を取得している」と言えば、通常はISO27001の認証を取得しているという意味になります（参考: 認証パートナー「ISMSとISO27001の違いは？」）。用語が2つあって混乱しやすい部分ですが、「中身は同じものを別の角度から呼んでいる」と理解しておけば十分です。
Pマークとの違い ― 個人情報に特化した国内認証
Pマーク（プライバシーマーク）は、ISMS・ISO27001とは別の認証制度です。最大の違いは「何を守る対象としているか」にあります。ISO27001が、個人情報・財務情報・技術情報・人事情報など幅広い情報資産全般を対象とするのに対し、Pマークは個人情報の取り扱いに特化しています。
もうひとつの違いは、規格の性質と認証範囲です。ISO27001は国際規格であり、認証は部署や事業所など特定の範囲を区切って取得できます。一方、Pマークは日本国内の制度（一般財団法人日本情報経済社会推進協会、JIPDECが運営）であり、原則として会社全体を対象に取得します（参考: 認証パートナー「ISMSとISO27001の違いは？」）。
発注者目線で言い換えると、開発会社がPマークを持っていれば「会社全体で個人情報の管理体制を整えている目安」になり、ISO27001を持っていれば「個人情報に限らず情報資産全般を管理する仕組みがある目安」になります。どちらが優れているということではなく、自社が委託するシステムが扱う情報の性質に照らして、どちらの認証がより関連するかを考えることが大切です。
比較表で一望する（保護対象・認証範囲・規格の性質）
3つの関係を整理すると、次のようになります。
項目 | ISMS | ISO27001 | Pマーク |
|---|---|---|---|
位置づけ | 情報セキュリティを管理する「仕組み」そのもの | ISMSの国際規格・認証の名称 | 個人情報保護に特化した認証制度 |
保護対象 | 情報資産全般 | 情報資産全般（個人情報・財務・技術情報など） | 個人情報のみ |
認証範囲 | ― | 部署・事業所単位で取得可能 | 原則として会社全体 |
規格の性質 | ― | 国際規格 | 日本国内の制度 |
実務上、ISMSとISO27001はほぼ同義で使われるため、発注者が押さえるべき対比は「ISO27001（情報資産全般・範囲を区切れる）」と「Pマーク（個人情報特化・会社全体）」の2つだと考えるとシンプルです。なお、情報セキュリティの第三者評価については、2026年以降に新たな評価制度の運用開始が予定されており、認証をめぐる選択肢は今後も広がっていく見込みです（出典: 認証パートナー、2026年）。
発注者が把握すべきセキュリティ認証と、その見方
ISMS・Pマーク以外にも、発注の場面で出会いやすい認証や基準があります。すべてを深く理解する必要はありませんが、「こういうものがある」と知っておくと、開発会社の説明を受けたときに戸惑わずに済みます。さらに重要なのは、認証を「あれば安心」と受け取らず、正しく使う見方を身につけることです。
発注時に出会いやすい認証・基準の早見
発注者が見聞きしやすい認証・基準には、たとえば次のようなものがあります。深入りはせず、概要だけ押さえておきましょう。
- ISO27017: ISO27001を補完する位置づけで、クラウドサービスの利用・提供に関するセキュリティに焦点を当てた規格です。クラウド上で動くシステムを発注する際に関連します。
- SOC2: 主に米国で広く参照される基準で、サービス提供事業者のセキュリティや可用性などの管理体制について、第三者が報告書の形で評価するものです。海外製のSaaSやクラウド基盤を組み込む場合に名前を見かけることがあります。
- 業界別の基準: 金融、医療、行政関連など、扱う情報の性質によって業界ごとのガイドラインや基準が存在します。自社の業界に該当するものがあれば、発注前に確認しておくと安心です。
これらは「より詳しい人に確認すべき対象」を見分けるための見出し程度に捉えてください。重要なのは個々の規格の細部ではなく、次に述べる「認証との向き合い方」です。
「認証あり」を鵜呑みにしない ― 認証範囲を確認する
認証マークがあると、それだけで「この会社は安全だ」と安心してしまいがちです。しかし、ここに落とし穴があります。先ほど触れたとおり、ISO27001は部署や事業所など特定の範囲を区切って取得できます。つまり「ISO27001認証あり」と書かれていても、自社の案件を担当する部署やサービスが、その認証の対象に含まれているとは限らないのです。
そのため発注者が確認すべきは、「認証を持っているか」だけでなく「その認証の範囲はどこまでか」です。具体的には、次のような質問を投げかけるとよいでしょう。
- 認証の対象範囲（適用範囲）には、今回の案件を担当する部署や開発拠点が含まれていますか。
- 今回利用するクラウド環境やサービスは、認証の対象に入っていますか。
- 認証はいつ取得し、直近の更新審査はいつでしたか。
認証は「組織として管理体制を整えようとしている目安」であって、案件単位の安全を保証するものではありません。認証の有無を入り口にしつつ、その範囲を具体的に確認することで初めて、認証は発注判断の材料として役に立ちます。「マークがあるから大丈夫」で止まらず、一歩踏み込んで質問する姿勢が、意思決定の質を高めます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
情報セキュリティポリシーと、セキュリティ要件整理の基本フレーム
ここまでで、ガバナンスという体制、CIAという守る対象の視点、ISMSやPマークという認証を理解しました。次は、これらを「自社のセキュリティ要件をどう整理するか」という実務につなげていきます。その橋渡しになるのが、情報セキュリティポリシーという考え方です。
情報セキュリティポリシーの3階層（基本方針・対策基準・実施手順）
情報セキュリティポリシーとは、組織として情報をどう守るかを定めた方針・規程の総称です。一般的に、次の3つの階層で構成されます。
- 基本方針: 「当社は情報セキュリティにどう取り組むか」という最上位の宣言。経営層が定める、組織としての姿勢を示すものです。
- 対策基準: 基本方針を実現するために「何を守り、どんなルールを設けるか」を定めた具体的な基準。アクセス権限の考え方やデータの取り扱いルールなどがここに入ります。
- 実施手順: 対策基準を現場で実行するための「具体的な手順書・マニュアル」。日々の運用レベルのルールです。
この3階層は、上位の方針が下位の手順を方向づけるという関係になっています。もし自社にすでに情報セキュリティポリシーがあるなら、その内容は、これから発注するシステムのセキュリティ要件のベースになります。ポリシーで「個人情報はこう扱う」と定めているなら、新しいシステムもその方針に沿っている必要があるからです。発注を担当することになったら、まず自社のポリシーの有無と内容を確認してみてください。
発注者がセキュリティ要件を整理する4ステップ
自社のポリシーを踏まえたうえで、発注者がセキュリティ要件を整理する流れを、4つのステップにまとめます。
- 守る情報資産を洗い出す: そのシステムが扱う情報を具体的にリストアップします。顧客の個人情報、取引データ、社内の業務情報など、何が含まれるかを明らかにします。
- CIAでどの要素を重視するか決める: 洗い出した情報資産ごとに、機密性・完全性・可用性のどれを特に重視すべきかを考えます。これが要件の優先順位になります。
- 自社の方針・法令・業界基準を確認する: 自社の情報セキュリティポリシー、個人情報保護法などの法令、業界固有の基準に照らして、満たすべき条件を確認します。
- 開発会社に任せる技術部分との切り分けを決める: ここまでで「自社が決めるべきこと」が明確になります。残る具体的な技術手段（暗号化方式、認証の仕組みなど）は、開発会社の専門領域として相談・委任する部分です。
このステップを踏むと、漠然としていた「セキュリティ要件」が、自社が判断する部分と開発会社に委ねる部分に分かれていきます。重要なのは、ステップ1から3までは発注者が主体になって進めるべきだということです。技術の詳細は任せられても、「何を守りたいか」は発注者にしか決められません。
自社が決めること／開発会社に任せること／認証で確認できること
要件整理の到達点として、役割を切り分けた整理表を示します。発注プロジェクトの初期段階で、この表を自社の状況に当てはめて考えてみてください。
区分 | 内容の例 | 進め方 |
|---|---|---|
自社が決めること | 守る情報資産の範囲／CIAの優先順位／自社ポリシー・法令上の必須条件／公開・非公開の範囲 | 業務を理解する発注者が主体的に決める |
開発会社に任せること | 暗号化方式・認証の仕組み・脆弱性対策などの具体的な技術手段／実装上のセキュリティ設計 | 自社の方針を伝えたうえで専門家として相談・委任する |
認証で確認できること | 委託先が組織として情報管理体制を整えているか（ISO27001・Pマーク等の有無と範囲） | 認証の有無と適用範囲を質問して確認する |
この3つの切り分けができれば、「丸投げか、全部自分で抱えるか」という極端な二択から抜け出せます。発注者は方針を決める役割に集中し、技術は専門家に委ね、組織体制は認証で確認する。この役割分担こそが、過不足のないセキュリティ要件整理の土台です。なお、整理した要件を実際に仕様書やRFPへどう書き起こすかについては、セキュリティ要件の書き方ガイドで具体的な記載項目とフォーマット例を解説しています。
外注先のセキュリティ体制を確認する方法
セキュリティ要件の切り分けができたら、次は実際に依頼する開発会社・委託先のセキュリティ体制を見極める段階です。ここで大切なのは、専門知識で相手を試すことではなく、適切な質問を投げかけて対話することです。発注者が確認のための質問を持っているだけで、丸投げではない関係を築けます。
認証・体制を確認する質問リスト
開発会社の選定時や、見積もり・提案を受ける段階で、次のような質問をしてみましょう。専門用語を使う場面でも、聞き方さえ分かっていれば発注者として十分に確認できます。
- ISO27001やPマークなどの認証を取得していますか。取得している場合、その適用範囲に今回の案件を担当する部署・拠点は含まれますか。
- 当社が扱う情報（個人情報など）について、御社の情報管理ルールはどうなっていますか。
- 開発に関わるメンバーに対して、情報セキュリティの教育や研修を実施していますか。
- 開発で使うパソコンやクラウド環境への、アクセス管理・持ち出し制限はどうなっていますか。
これらの質問にスムーズかつ具体的に答えられる会社は、組織としてセキュリティを意識している可能性が高いと判断できます。逆に、質問の意図が伝わらなかったり回答が曖昧だったりする場合は、より詳しく確認すべきサインです。
開発・保守プロセスで確認すべきこと
体制だけでなく、開発と保守の進め方についても確認しておきたい点があります。
ひとつは「セキュリティ・バイ・デザイン」という考え方を持っているかです。これは、開発の最初の設計段階からセキュリティを組み込む進め方を指します。完成後にセキュリティ対策を後付けするのではなく、要件定義や設計の段階から考慮するという姿勢です。開発会社にこの考え方が根づいているかは、提案内容や打ち合わせの中での説明から読み取れます。
もうひとつは、リリース後の保守契約の範囲です。システムは公開して終わりではありません。新たな脆弱性が見つかったときの修正対応や、利用しているソフトウェアのセキュリティアップデートが、保守契約に含まれているかを必ず確認してください。ここが契約に含まれていないと、リリース後にセキュリティ上の問題が見つかっても、追加費用や対応の遅れに直面することがあります。脆弱性診断（システムに弱点がないかを専門的に検査すること）の実施有無や、再委託が発生する場合の管理方法についても、あわせて確認しておくと安心です。
これらの確認は、相手を疑うためのものではなく、認識をそろえて良い関係を築くための対話です。発注者が確認の視点を持っていることは、開発会社にとっても「この案件はセキュリティを大事にしている」という明確なメッセージになります。
セキュリティインシデント時に発注者が問われる責任
最後に、「なぜ発注者がここまで理解しておく必要があるのか」という問いに、改めて答えておきます。重く受け止めてほしいというより、事前の備えがいかにリスクを下げるかを知っていただくためのセクションです。
外注しても発注者に残る責任とは
開発を外部に委託していても、情報を扱う主体が発注者である以上、発注者には一定の責任が残ります。個人情報を扱うシステムの場合、これは法律上も明確です。個人情報保護法は、個人データの取り扱いを委託する事業者に対し、委託先が安全に管理できるよう「必要かつ適切な監督」を行うことを義務づけています。個人情報保護委員会のガイドラインでは、この監督義務を果たすために具体的な取り組みが必要とされています。
この監督義務には、一般に「委託先を適切に選ぶこと」「適切な内容で委託契約を結ぶこと」「委託先での取り扱い状況を把握すること」が含まれるとされています。さらに、委託先が再委託を行う場合には、最初の委託者は再委託先に対しても間接的に監督責任を負うと考えられており、個人情報保護委員会のガイドラインでも再委託先の監督に留意すべきとされています。
つまり、「開発会社に任せたから、何かあっても開発会社の問題」とはなりません。委託先の選び方や管理が不十分だった場合、発注者自身も責任を問われる可能性があります。作業は委託できても、監督する責任は発注者に残るのです。
事前のガバナンス・要件整理がリスクを下げる
このように責任が残ると聞くと不安になるかもしれませんが、見方を変えれば、これまで本記事で説明してきたことこそが、その責任を果たし、リスクを下げる備えになります。
委託先を適切に選ぶことは、認証の有無と範囲を確認する取り組みそのものです。適切な内容で契約を結ぶことは、整理したセキュリティ要件を仕様書や契約に反映することにつながります。取り扱い状況を把握することは、開発・保守プロセスを確認し、対話を続けることです。本記事で扱ってきたガバナンスの理解、CIAによる要件整理、認証の見方、外注先の確認は、そのまま「事前の備え」として機能します。
逆に言えば、何も準備せずに丸投げしてしまうと、トラブルが起きたときに「適切に監督していた」と示す材料がありません。事前にガバナンスを理解し、要件を整理し、確認のプロセスを踏んでおくことは、トラブルそのものを起こりにくくするだけでなく、万一の際に発注者自身を守る根拠にもなります。セキュリティの全体像を理解することは、過剰な心配のためではなく、安心して発注を進めるための準備なのです。なお、個人情報を扱うシステムを発注する際の委託先管理や契約条項のチェックポイントは、個人情報保護法対応のシステム開発チェックリストで詳しく整理しています。
まとめ ― 全体像を理解して、次の一歩へ
本記事では、IT発注を担当する非エンジニアの方に向けて、ITガバナンスと情報セキュリティの全体像を解説しました。最後に、記事全体を貫く階層を改めて確認しておきましょう。
情報セキュリティは、次の3つの層で捉えると整理できます。
- 組織としての統制の仕組み（ITガバナンス）: 誰が・何を・どう統制するかという体制。外部発注もこの一部であり、責任は発注者に残ります。
- 情報を管理する仕組み（ISMS・情報セキュリティポリシー）: ルールづくり・運用・見直しを回す枠組み。ISO27001やPマークは、この仕組みが整っているかの目安になります。
- 個別の技術要件: 暗号化や認証など、具体的な技術手段。これは開発会社の専門領域として委ねる部分です。
この階層が頭の中にあれば、断片的に見えていたセキュリティ用語が地図の上に並び、CIA（機密性・完全性・可用性）という軸で守る対象を言語化し、「自社が決めること・開発会社に任せること・認証で確認できること」を切り分けられるようになります。これが、過不足のないセキュリティ要件整理の出発点です。
ここまで読み進めたあなたは、もう「セキュリティはお任せします」と丸投げするしかない状態ではありません。次の一歩は、整理した方針を実際の仕様書や契約に落とし込む実務です。仕様書への具体的な書き方はセキュリティ要件の書き方ガイドで、個人情報を扱う場合の法令対応や委託先管理は個人情報保護法対応のシステム開発チェックリストで、それぞれ実務レベルの手順を確認できます。全体像を理解した今、自信を持って次の工程に進んでください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
