セキュリティ7 min readNEW

システム開発を外注する前に確認すべきセキュリティチェックリスト

開発会社に依頼する前に、権限・データの置き場所・ログ・本番アクセスをどこまで決めておくか。発注者が確認できる実務チェックリストを図で整理しました。

この記事でわかること

  • 発注前に決めておくべきセキュリティ項目がわかる
  • データの置き場所を一枚の図に落とせる
  • 見積・要件定義で開発会社と同じ前提を共有できる

なぜ発注前に決めるのか

システムができてから「誰が・どのデータに触れるか」を決めると、手戻りが大きくなります。

外注前に最低限の確認項目を揃えておくと、見積の精度も上がり、導入後の不安も減ります。

決めてから依頼 / 依頼してから決める

後回し

権限が曖昧
本番データの扱い不明

先に決める

役割と権限が明確
データの境界が共有される

確認チェックリスト

発注前に、社内でわかる範囲だけでも埋めておくと、開発会社との会話がスムーズになります。

  • 本番・検証・開発で環境が分かれているか
  • 管理者・現場・外部パートナーの権限が分かれているか
  • 個人情報・契約情報の取り扱い方針があるか
  • バックアップと復旧の手順があるか
  • 開発会社の作業ログ・アクセス範囲が説明できるか

データの置き場所を図にする

「どこに何があるか」を一枚の図にすると、社内でも開発会社でも同じ前提で話せます。

データの層(例)

外部公開

コーポレートサイトなど → 公開前提

社内業務

業務システム・社内FAQ → 権限必須

機密

契約・個人情報 → 最小権限・監査

本番アクセスと作業範囲を決める

「開発会社がどこまで触れるか」が曖昧だと、本番事故や情報持ち出しのリスクが残ります。

作業用アカウント・接続経路・承認フローを先に決めておくと、見積にも反映しやすくなります。

アクセスの分け方

社内

  • 本番権限の承認
  • データ分類の最終判断
  • 運用責任

開発会社

  • 検証環境での実装
  • 承認後の本番反映
  • 作業ログの提出
  • 本番への直接ログインは原則禁止(必要な場合は承認付き)
  • 検証環境で再現・確認してから本番反映する
  • 個人アカウントではなく、作業用の役割アカウントを使う
  • 作業ログが残る仕組み(いつ・誰が・何をしたか)を求める

次のアクション

チェックが揃ったら、要件定義で開発会社とすり合わせます。SHINJIDAIでは設計段階から権限・ログ・運用を含めて提案します。

進め方
  1. 01

    チェックリストを埋める

    社内でわかる範囲を先に整理

  2. 02

    見積・要件で共有

    開発会社と同じ図を見る

  3. 03

    設計に落とし込む

    権限・環境・ログを仕様化

よくある質問

なぜ発注前にセキュリティを決めるのですか?

システムができてから権限やデータの扱いを決めると、手戻りが大きくなります。先に最低限の確認項目を揃えると、見積の精度も上がります。

最低限、何を決めればよいですか?

環境の分離、役割ごとの権限、個人情報・契約情報の扱い、バックアップと復旧、開発会社のアクセス範囲とログ、の5点が出発点です。

社内データをRAGに入れる予定がある場合は?

外注時の権限・データ境界に加えて、資料の選別・出典・ログのルールも先に決めてください。関連コラムで図解しています。

CONTACT

課題の整理からご相談ください

要件が固まっていない段階でも構いません。業務システム・RAG構築・現場DXまで、一気通貫で伴走します。

お問い合わせ
THE FUTURE IS JAPAN.
THE FUTURE
IS JAPAN.