「弊社はISO27001を取得済みなので、セキュリティは万全です」。複数の開発会社を比較するなかで、1社の営業からこう言われ、提案資料にも認証マークが大きく載っている。自社の顧客情報や売上データを扱うシステムの開発を任せる以上、セキュリティは重視したい。だからこの一言は心強く聞こえます。
ただ、いざ発注を決める段になると手が止まります。「ISO27001取得済み」が具体的に何を保証してくれるのか、自分の言葉で説明できないからです。上司からは「その外注先、セキュリティは本当に大丈夫なのか」「もし情報が漏れたらどうするんだ」と問われている。認証マークがあれば「この会社なら安全です」と言い切ってよいのか、確信が持てないまま社内承認の資料を作ろうとしている――そんな状況ではないでしょうか。
セキュリティの専門知識がない立場で、認証の有無だけを根拠に「安全」と判断するのは不安なものです。さらに調べていくと、外注先で情報漏洩が起きた場合、委託した自社（発注者）の側も責任を問われ得る、という話まで出てきます。そうなると、認証マークを鵜呑みにして発注先を決めることのリスクが、いっそう重く感じられます。
結論からお伝えすると、ISO27001（ISMS）は「情報を守る仕組みが第三者に認められている」という信頼の目安にはなりますが、「この会社に任せれば絶対に事故が起きない」という保証書ではありません。大切なのは、認証を過信も軽視もせず、何が保証され・何は保証されないのかを理解したうえで、発注者自身が確認すべき点を確認することです。
本記事では、ISO27001（ISMS）とは何かという基礎から、ISMSとの違い、認証が保証するもの・しないもの、最も見落とされやすい「認証スコープ」の確認方法、委託元（発注者）が負う責任、そして次の打ち合わせでそのまま使える契約前チェックリストまでを、専門知識がなくても判断できる形で解説します。読み終えたとき、「取得済み」の一言を自分で検証し、発注の意思決定と社内説明ができる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ISO27001とは｜発注者がまず押さえるISMSとの関係
最初に、営業に言われた「あの認証」が何なのかを腹落ちさせておきましょう。ISO27001を理解する出発点は、「ISMS」と「ISO27001」という2つの言葉の関係を整理することです。両者は混同されがちですが、意味する対象が異なります。
ISMSとISO27001の違い（仕組みと国際規格）
ISMSは「Information Security Management System」の略で、日本語では「情報セキュリティマネジメントシステム」と訳されます。平たく言えば、会社が情報を守るために整えた仕組み・体制・ルールの全体を指します。誰がどの情報にアクセスできるか、パソコンや書類をどう管理するか、事故が起きたときに誰がどう動くか――こうした取り決めをばらばらに持つのではなく、組織として体系立てて運用している状態がISMSです。
一方のISO27001は、そのISMSが満たすべき要求を定めた国際規格です。国際標準化機構（ISO）と国際電気標準会議（IEC）が定めた規格で、正式にはISO/IEC 27001と表記されます。情報セキュリティの仕組みを「どのレベルで、どんな観点で整えるべきか」の世界共通のものさし、と捉えるとわかりやすいでしょう。
つまり両者は対立するものではなく、「ISMS（仕組み）」を「ISO27001（国際規格）」というものさしで測る、という関係にあります。ISMSとISO27001は実務上ほぼ一体のものとして語られることが多く、「ISMS認証」と「ISO27001認証」はおおむね同じものを指します（マネーフォワード クラウドでも、ISMS＝仕組み、ISO27001＝規格という整理が示されています）。
「ISO27001取得済み」が意味すること（第三者審査を通った証拠）
では「ISO27001を取得済み」とは何を意味するのでしょうか。これは、その会社のISMS（情報を守る仕組み）が、利害関係のない第三者の審査機関による審査を受け、ISO27001の要求を満たしていると認められたことを意味します。
ポイントは「第三者が検証した」という部分です。自社で「うちはセキュリティをしっかりやっています」と主張するだけなら誰でもできますが、ISO27001の取得は、外部の審査機関が書類や運用実態をチェックし、客観的に「規格に適合している」と判断した結果として与えられます。さらに、一度取得すれば終わりではなく、認証を維持するには通常1年に1回以上の維持審査（サーベイランス審査）を受け、3年ごとに更新審査を通過する必要があります。継続的に運用していなければ認証は維持できない仕組みです。
この「第三者による客観的なお墨付き」という点が、発注者にとっての価値です。少なくとも、情報を守る仕組みを体系的に整え、外部審査に通る水準で運用している会社である、という一定の信頼の根拠になります。
Pマーク・他の認証との違い（どこまでが守備範囲か）
セキュリティ関連の認証として、ISO27001と並んでよく耳にするのが「Pマーク（プライバシーマーク）」です。両者は似て見えますが、守備範囲が異なります。
- ISO27001（ISMS）: 顧客情報・売上データ・社員情報・技術情報・ソースコードなど、会社が扱う情報資産全般を守る仕組みを対象とする国際規格
- Pマーク（プライバシーマーク）: 守る対象を個人情報に特化した、日本国内の制度
開発を委託する場面では、顧客の個人情報だけでなく、自社の業務データや仕様・ソースコードといった機密情報も外注先に渡ります。その意味で、情報資産全般をカバーするISO27001のほうが、開発委託先の評価軸としては範囲が広いと言えます。どちらが上位ということではなく、「何を守る仕組みなのか」が違う、と理解しておけば十分です。
ここまでで、「ISO27001取得済み」が一定の信頼の根拠になることはわかりました。ただし、それを「絶対安全」と読み替えてよいかは別の話です。次に、認証が保証するものと保証しないものを切り分けていきます。
ISO27001が保証するもの・保証しないもの
ここが本記事の中心です。「取得済み＝安全」と考えてよいのかという不安に、正面から答えます。結論を先に言えば、認証は足切りの目安であって、個別案件の安全を約束する保証書ではありません。何が保証され、何は保証されないのかを切り分けて理解することが、過信も軽視もしない判断につながります。
ISO27001が保証するもの（仕組み・運用・第三者検証）
ISO27001の取得が示してくれるのは、主に次の3点です。
- 情報を守る仕組み・体制・ルールが整備されている: アクセス権限の管理、情報資産の取り扱いルール、社員教育、事故発生時の対応手順などが、場当たり的ではなく組織として体系立てて定められている
- その仕組みが実際に運用されている: ルールが文書上あるだけでなく、日々の業務で運用され、維持審査を通じて継続的に確認されている
- 以上を第三者が客観的に検証している: 自己申告ではなく、外部の審査機関が審査して適合を認めた客観的な証拠である
これらは、情報を扱う会社として最低限整えておくべき土台が備わっていることの裏付けになります。社内説明の場面でも、「外部審査を通った仕組みを持つ会社です」と言える根拠になります。
ISO27001が保証しないもの（個別事故ゼロ・スコープ外・技術的脆弱性ゼロではない）
一方で、認証があっても保証されない領域があります。ここを誤解すると「取得済みだから任せきりでよい」という危険な判断につながります。
- 個別案件で事故が絶対に起きないこと: ISO27001は「仕組みが整っている」ことの認証であって、「今後一切の漏洩・事故が起きない」ことを約束するものではありません。仕組みが整った会社でも、人為的ミスや想定外の攻撃で事故が起きる可能性はゼロにはなりません
- 認証スコープの外側の業務の安全: 後ほど詳しく触れますが、認証は会社全体ではなく特定の事業所・部門・サービス単位で取得されているのが一般的です。自社が発注する業務がその範囲（スコープ）の外にあれば、その業務には認証の効力が及びません
- 技術的なセキュリティ品質そのもの（脆弱性が皆無であること）: ISO27001は「組織がセキュリティを管理する仕組み」を見る規格であり、開発される個々のシステムにバグや脆弱性が一つもないことを保証するものではありません。実際に作られるシステムの安全性は、設計や実装の品質、そして必要に応じた脆弱性診断などで別途確かめる領域です（システムそのものの安全性確認については、脆弱性診断とはもあわせてご覧ください）
だから「認証＋自社での確認」がセットになる理由
整理すると、ISO27001は「この会社は情報を守る土台を持っている」という出発点を示してくれますが、「あなたの案件が安全だ」と言い切ってくれるわけではありません。だからこそ、認証の有無を確認したうえで、その認証が自社の案件に本当に効いているのか、そして認証ではカバーされない部分をどう担保するのかを、発注者自身が確認する必要があります。
認証を過信して任せきりにするのでも、認証を軽視して無意味と切り捨てるのでもなく、「認証＋自社での確認」をセットで進める。これが、専門知識がなくても取れる現実的な構えです。次の章から、その「自社での確認」を具体的な手順に落としていきます。
見落とされがちな「認証スコープ」と適用範囲の確認
発注者が最も見落としやすいのが、この「認証スコープ（適用範囲）」です。ここを押さえると、「取得済み」という言葉を自分の手で検証できるようになります。
「取得済み」でも自社案件が対象外になるケース（スコープの罠）
「ISO27001を取得済み」と聞くと、つい「会社全体がまるごと認証されている」とイメージしがちです。しかし実際には、認証は特定の事業所・部門・サービス単位で取得されているのが一般的です。たとえば「東京本社の受託開発部門」だけが認証範囲で、地方の拠点や別事業は範囲外、というケースがあり得ます。
この場合、もし自社が発注する業務を担当するのが認証範囲外の拠点・部門であれば、「会社としては取得済み」でも、自社の案件には認証の効力が及んでいないことになります。営業の「取得済みです」という言葉が嘘というわけではなくても、それが自社案件にそのまま当てはまるとは限らない――これがスコープの罠です。
認証スコープ・適用範囲の見方（発注業務が含まれるか）
ですから、確認すべきは「取得しているか／していないか」だけではありません。自社が発注しようとしている業務・拠点・サービスが、その認証の適用範囲に含まれているかです。具体的には、相手の認証情報について次の点を確認します。
- どの事業所・部門が認証範囲に含まれているか（自社案件を担当する拠点・チームが入っているか）
- どの事業・サービスが対象か（受託開発が範囲に含まれているか）
- 適用されている規格がISO/IEC 27001であること（クラウドサービスを利用する場合は、クラウド向けの追加認証の有無も確認の余地があります）
これらは、相手に認証の登録内容を見せてもらうことでも確認できますが、後述のとおり発注者自身が公的なデータベースで裏取りすることもできます。
ISMS-ACで証明書の有効性・有効期限を自分で確認する方法
ISO27001（ISMS）の認証取得組織は、認定機関であるISMS-AC（情報マネジメントシステム認定センター）が運営する「ISMS認証取得組織検索」で、誰でも無料で検索・確認できます（ISMS認証取得組織検索）。営業の言葉ではなく、公的なデータで裏取りできるのが大きな利点です。
検索画面では、企業名や所在地などで組織を絞り込むと、その組織の認証範囲（適用範囲）・適用規格・登録の有効期限・登録状況といった情報を確認できます。ここで、自社が発注する業務・拠点が範囲に含まれているか、登録が現在も有効か（失効していないか）をチェックします。
なお、すべての取得組織が情報を公開しているわけではない点には注意が必要です。ISMS-ACのデータベースは認証機関から報告されたデータに基づいており、非公開を希望している組織や登録準備中の組織は検索に表示されないことがあります（ISMS-AC FAQ）。検索でうまく見つからない場合は、相手に認証登録証（証明書）の写しを見せてもらい、登録番号・認証範囲・有効期限を直接確認するとよいでしょう。
「取得済み」という言葉を、こうして自分の目で公的データに照らして確かめられるようになれば、不安の多くは主体的に解消できます。
情報漏洩は誰の責任か｜委託元（発注者）が負う監督責任
ここまでは「認証をどう検証するか」を扱ってきました。本章では、もう一つの重要な論点――「もし外注先で情報が漏れたら、責任は誰が負うのか」に踏み込みます。「自社の責任になると聞いて不安」という最初の問いに、ここで答えます。
外注先で漏洩しても委託元が問われる理由（委託先監督義務）
直感的には「漏らしたのは外注先なのだから、責任も外注先にある」と考えたくなります。しかし、こと個人情報に関しては、そう単純ではありません。
個人情報保護法は、個人データの取り扱いを外部に委託する場合、委託元（発注者）に対して委託先を監督する義務を課しています（個人情報保護法第25条）。この監督義務は、一般に「①適切な委託先の選定」「②委託契約の締結」「③委託先における取り扱い状況の把握」という要素から成るとされています（みらい総合法律事務所、Conoris Labo）。
つまり、外注先で漏洩が起きた場合でも、委託元が適切な監督を怠っていたと判断されれば、委託元自身の責任が問われ得るのです。実務上も、顧客と直接の取引関係にあるのは委託元であるため、まず委託元が顧客対応や公表の矢面に立つことになります。「認証があるから任せきりでよい」という構えが危険なのは、まさにこの点です。認証はあくまで「①適切な委託先の選定」を支える材料の一つにすぎず、それだけで監督義務を果たしたことにはなりません。
認証だけでは埋まらない部分を契約で担保する（再委託・責任分担・報告・監査権）
監督義務の3要素のうち、認証の確認が貢献するのは主に「選定」の部分です。残る「契約の締結」と「取り扱い状況の把握」は、認証マークだけでは埋まりません。ここを埋めるのが契約での取り決めです。発注契約や業務委託契約のなかで、少なくとも次の点を明文化しておくことが、認証で足りない部分を補う現実的な手段になります。
- 再委託の制限: 外注先がさらに別の会社へ業務を再委託する場合のルール（事前承諾の要否、再委託先にも同等のセキュリティ義務を課すこと）
- 責任分担: 漏洩・事故が発生した場合の責任の所在と負担の取り決め
- 報告義務: 事故やインシデントが起きた際に、いつ・どのように委託元へ報告するかのフロー
- 監査権・状況把握: 委託元が委託先の取り扱い状況を確認・点検できる権利（定期的な報告や、必要に応じた確認の取り決め）
これらは専門的に見えますが、発注者として「契約書にこの観点が入っているか」を確認するだけでも、漏洩時に「適切な監督をしていた」と説明できる立場に近づきます。認証で「選定」を、契約で「契約締結」と「状況把握」を担保する。この二段構えが、委託元の責任という不安への具体的な答えになります。
2026年に始まる「セキュリティ対策評価制度」とISO27001の関係
外注先のセキュリティを見極める軸として、近い将来に新しい客観指標が加わります。それが、経済産業省とIPA（情報処理推進機構）が準備を進めている「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」です。現時点では発注者が今すぐ対応を迫られるものではありませんが、今後の外注先選定の視野を広げる意味で、概要を押さえておく価値があります。
セキュリティ対策評価制度とは（★3〜★5の段階評価）
この制度は、サプライチェーン全体のセキュリティ水準を底上げするために、企業のセキュリティ対策の度合いを**★（星）の段階で可視化**しようとするものです。経済産業省が2026年3月に公表した制度構築方針によれば、★3〜★5の段階で評価する仕組みが想定されています（経済産業省 報道発表、IPA SCS評価制度）。
- ★3: すべてのサプライチェーン企業が最低限実装すべき対策水準
- ★4: サプライチェーン企業が標準的に目指すべき対策水準
- ★5: 到達点として目指すべき対策水準
公表方針では、まず**★3および★4について2026年度末頃の制度開始（申請受付の開始）を目指す**とされ、★5はそれ以降に要求事項や評価スキームを具体化していく段階とされています（時期・区分は今後変更される可能性があるため、最新情報はIPAの公式ページでご確認ください）。なお、より基礎的な自己宣言の取り組みとしては、IPAが従来から提供する「SECURITY ACTION」があり、中小企業向けの支援策とあわせて制度全体が整理されつつあります。
ISO27001（ISMS）との違いと、発注者が今知っておくべき理由
ISO27001（ISMS）とこの新制度は、目的と見ている対象が異なります。ISO27001が「個々の組織のセキュリティ管理の仕組み」を第三者が認証するものであるのに対し、SCS評価制度は「サプライチェーン全体を見据えた対策水準」を★で可視化しようとするものです。両者は競合するというより、補い合う関係に近いと考えられます。
発注者が今この制度を知っておくべき理由は、外注先を見極める客観指標が「ISO27001の有無」だけでなく「★いくつか」という形でも示されるようになる可能性があるためです。制度が本格運用されれば、「ISO27001取得済み、かつ★4相当」といった形で、より多面的に外注先のセキュリティ姿勢を比較できるようになるかもしれません。現時点では「今すぐ必須の確認項目」ではありませんが、中長期で外注先を見直す際の判断軸として、頭の片隅に置いておくとよいでしょう。
契約前にISO27001取得先へ確認すべきチェックリスト
ここまでの内容を、次の打ち合わせでそのまま使える形に落とし込みます。「ISO27001取得済み」と言われたとき、認証そのものを検証する項目と、認証では埋まらない部分を契約で確認する項目に分けて整理しました。各項目には「なぜ確認するのか」を一言添えています。
認証そのものを検証する項目（スコープ・有効期限・適用規格）
確認項目 | 確認内容 | なぜ確認するのか |
|---|---|---|
認証スコープ・適用範囲 | 自社が発注する業務・拠点・サービスが認証範囲に含まれているか | 会社として取得済みでも、自社案件が範囲外なら認証の効力が及ばないため |
証明書の有効期限・登録状況 | 登録が現在も有効か、失効していないか（ISMS-ACの検索や登録証の写しで裏取り） | 過去に取得したが現在は維持していないケースを見抜くため |
適用規格 | ISO/IEC 27001で認証されているか（クラウド利用時はクラウド向け追加認証の有無も） | 何の規格に基づく認証かを確かめ、想定とのずれを防ぐため |
認証で埋まらない部分を契約で確認する項目（再委託・責任分担・報告・監査）
確認項目 | 確認内容 | なぜ確認するのか |
|---|---|---|
再委託の取り扱い | 再委託の有無、事前承諾の要否、再委託先への同等のセキュリティ義務 | 情報がさらに別の会社へ渡る経路を把握・管理するため |
漏洩時の責任分担 | 事故発生時の責任の所在と負担を契約に明記しているか | 万一の際に「誰がどこまで負うか」を事前に確定しておくため |
報告フロー | インシデント発生時に、いつ・どう委託元へ報告するか | 委託元が顧客対応・公表に迅速に動けるようにするため |
状況把握・監査権 | 委託先の取り扱い状況を確認・点検できる取り決めがあるか | 委託元の監督義務（取り扱い状況の把握）を果たすため |
（参考）将来の評価制度 | セキュリティ対策評価制度への対応方針 | 中長期の外注先選定の判断軸として把握しておくため |
このチェックリストがあれば、技術やセキュリティに詳しくなくても、「認証スコープに自社案件は含まれていますか」「登録の有効期限はいつですか」「漏洩時の報告フローは契約に書かれていますか」と、その場で具体的に確認できます。ISMS取得企業に発注することのメリットそのものをもう少し詳しく知りたい場合は、ISMS認証取得の開発会社に発注するメリットもあわせてご覧ください。
まとめ｜「ISO27001取得済み」を鵜呑みにせず自分で検証する
最後に、本記事の要点を振り返ります。
- ISO27001（ISMS）は信頼の目安だが保証書ではない: ISMSは「情報を守る仕組み」、ISO27001はその仕組みを測る国際規格です。「取得済み」は、情報を守る仕組みが第三者審査を通った客観的な証拠ですが、個別案件で事故が絶対に起きないことや、システムに脆弱性が皆無であることまでを保証するものではありません
- 認証スコープと有効性は発注者自身が検証できる: 認証は会社全体ではなく特定の事業所・サービス単位で取得されているのが一般的です。自社案件が範囲に含まれるか、登録が有効かは、ISMS-ACの検索や登録証の写しで、発注者自身が裏取りできます
- 漏洩時の責任は委託元にも及ぶため、契約での担保が不可欠: 個人情報の委託では、委託元に委託先の監督義務があり、外注先での漏洩でも委託元の責任が問われ得ます。認証は「選定」を支える材料にすぎず、再委託・責任分担・報告・監査権といった点は契約で明文化して補う必要があります
- 近い将来は新制度の★評価も判断材料になる: サプライチェーン強化に向けたセキュリティ対策評価制度が準備されており、今後は「★いくつか」という指標も外注先選定に加わる可能性があります
「ISO27001取得済み」という一言を鵜呑みにするのでも、無意味と切り捨てるのでもなく、認証を出発点として自分で検証し、認証では埋まらない部分を契約で担保する。本記事のチェックリストを手元に置けば、セキュリティの専門知識がなくても、発注の意思決定と社内への説明ができるはずです。次の打ち合わせでは、ぜひ「認証スコープ」「有効期限」「適用規格」を、その場で相手に確認してみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
