開発部門とPマーク

【2026年10月時点の注記】
本記事は2017年11月の公開時点の情報をもとにしています。JIS Q 15001は2023年に改正され、プライバシーマークでは2024年10月1日から「構築・運用指針【JIS Q 15001:2023準拠】」に基づく申請受付が始まっています。
今回の記事で取り上げる「開発部門」とは特にIT関連の事業を展開する会社においてWebやアプリケーションなどのシステム開発を担当する部門を念頭に置いています。
開発部門はプログラミングを行ったりサーバシステムやネットワークの構築・更新・保守を行ったりと技術面で極めて高い専門性が求められるため、その分個人情報保護やセキュリティ面でプライバシーマーク(Pマーク)上要求されることも特殊です。
これからプライバシーマーク(Pマーク)取得会社において開発部門が特に留意すべき個人情報保護の注意点とは何かを考えてみましょう。
この記事のポイント
- システムの開発・変更時には、必ずセキュリティ面も考慮し、変更後のセキュリティが変更前と同等以上になるように設計する
- アクセス制御・パスワード管理を部門として徹底し、システムに許可されないアクセスがないかどうかを定期的にアクセスログをチェックするなどして点検する
- 会社が業務用として指定した機器や環境に関するルールを守り、指定外の機器などを使用する必要がある場合は、必ず承認を得てから使用する
システムの開発・変更時にはセキュリティレベルが確保されるようにする
開発部門では新しいWebシステムを開発したり変更したりする際、常にシステム仕様書を作成してどのような仕様のシステムを構築するかを綿密に計画するはずです。
仕様を決める際は必ずセキュリティ面も考慮しなければなりません。Webでユーザーの個人情報を取得する場合はSSL通信を実装するなどのセキュリティ対策は初歩的な部分ですが、そのほかにも必要な対策があればプライバシーマーク(Pマーク)取得会社として実行しなければなりません。
システム変更の際も、変更後のセキュリティが変更前と同等以上になるように設計すべきなのが原則です。システム変更に伴って公開されるべきでない個人情報などが閲覧可能な状況になっていたりしないかどうかも公開前にテストしておくべきです。
アクセス制御・パスワード管理を徹底する
開発部門はほかの従業員が操作できないようなシステムや情報にアクセスする権限が付与されることもあるでしょう。たいていそのような場合はID・パスワードが割り当てられ、その権限でシステムにログインすることになります。
このように開発部門では他部門よりもパスワード情報を使う機会が多い傾向にありますので、パスワードの管理を部門として徹底するなどの措置を講じなければなりません。
またシステムに許可されないアクセスがないかどうかも定期的にアクセスログをチェックするなどして点検しなければなりません。
会社が業務用として指定した機器や環境に関するルールを守る
プライバシーマーク(Pマーク)取得会社では社内のセキュリティを維持するために業務で利用するコンピュータや機器・アプリケーションソフト、ネットワーク環境が指定されることもあります。
開発部門の社員としてはどうしてもITに詳しいため自分好みの機器やソフトを利用したい気持ちもあるかもしれませんが、この点では会社のルールを守るようにしましょう。業務上どうしても指定外の機器などを使用する必要がある場合は、必ず承認を得てから使用するようにしてください。
まとめ
プライバシーマーク(Pマーク)(Pマーク)における技術的安全管理措置を実践するうえで開発部門は非常に重要な役割を担っています。開発部門は自部門のミッションを遂行するにあたり個人情報保護やセキュリティ面での要求事項も満たすように努めましょう。
この記事のまとめ
- Pマークにおける技術的安全管理措置を実践するうえで、開発部門は非常に重要な役割を担っている
- 開発部門は自部門のミッションを遂行するにあたり、個人情報保護やセキュリティ面での要求事項も満たすように努める
・こちらの記事もおすすめです
→【Pマークって日本だけ?】
株式会社UPFについて(2026年10月1日時点)
株式会社UPFは、プライバシーマーク(Pマーク)・ISMS(ISO/IEC 27001)・AIMS(ISO/IEC 42001)・TISAXなどの認証の取得・運用支援と、セキュリティ監査、AI利用ガイドラインの策定支援を行う情報セキュリティの専門会社です。
- 創業:2005年5月(認証取得支援は2009年から)
- 支援実績:累計5,695社(うちプライバシーマーク4,261社、ISMS 1,199社)
- 継続率:95%(2020〜2026年平均。初めてUPFを利用したお客様が、次回の更新もUPFに依頼した割合)
- 体制:プライバシーマーク審査機関(JIPDEC)の現役審査員が在籍(自らがコンサルティングを担当する企業の審査は行いません)。年間2,000件を超える審査関連の情報が社内に集まります
- 自社でも取得:プライバシーマーク、ISMS(ISO/IEC 27001)、ISO/IEC 27701
- 拠点:東京(本社)・名古屋・福岡。全国の企業に対応
- 数字の定義と根拠:UPFの支援実績・継続率などの数字の定義と根拠
この記事を書いた人
株式会社UPF
同じテーマの記事はこちら
AI利用ガイドラインは自社で作る?テンプレート?専門家に依頼?3つの作り方を費用・期間・注意点で比較【2026年】
「社内でもAIを使い始めたので、利用ルールを決めておきたい」 この1年で、こうしたご相談を本当に多くいただくようになりました。 総務省の「令和8年版 情報通信白書」によると、生成A […]
AI利用ガイドラインとAIMS(ISO/IEC 42001)はまったく別のもの|目的・中身・費用・期間の違いと、自社に必要なのはどちらか
「AIのルールを整えたいのですが、AIMSを取ったほうがいいのでしょうか」 AI利用ガイドラインのご相談のなかで、こうしたご質問をいただくことがあります。 どちらも「AI」と「ルー […]
【2026年10月】名古屋・大阪・福岡でAI社内ガイドライン策定を頼める会社比較|地域別の依頼先と料金・支援内容
「生成AIの社内ルールを整えたいが、名古屋(大阪・福岡)で頼める会社はどこか」 東京以外の企業様からも、こうしたご相談をいただくことが増えてきました。 本記事では、名古屋・大阪・福 […]
「破られる前提」で備える時代へ——PHPの深刻な脆弱性(php2shell)とAI時代のサイバー攻撃について、私が考えたこと
2026年10月、サーバー側の言語が判明しているWebサイトの約7割で使われるPHPに、認証なしで外部からコードを実行され得る深刻な脆弱性(php2shell、CVSS 9.2)が公表され、国内外でサイト停止が相次ぎました。10年以上潜んでいた穴の攻撃経路をAIが突き止めた今回の件から、企業が「破られる前提」で備えたいことを、情報セキュリティの支援会社の代表として考えます。 […]
AI利用ガイドラインには何を書く?入れるべき項目と分量の考え方、作った後の社内展開・見直しまで
「どういう内容で、どれぐらいのボリュームで作るのが正解なのか、まったくイメージが湧かなかった」 AI利用ガイドラインの策定をご依頼いただいた、PR会社の株式会社LITA様の言葉です […]