セキュリティコンサルの職務経歴書｜SOC・CSIRT経験をリスク改善の実績として書く

セキュリティコンサルの職務経歴書で最初に伝えること

SOC・CSIRT・セキュリティエンジニアから応募するなら、職務経歴書の冒頭で「守った事業・資産、見立てたリスク、変えた統制、残存リスク」を示します。対象は、監視・事故対応・製品や基盤の設計経験を、セキュリティコンサルタントの応募書類にまとめたい方です。

職務経歴書の中心に置きたいのは、アラートや脆弱性をいくつ扱ったかだけではありません。どの事業・資産を守るためにリスクを見立て、どの統制を変え、効果と残る課題をどう確かめたかまで書くと、技術対処から助言・改善へ進める人だと伝わる構成です。

書類で答える問い	残す内容
何を守ったか	事業、重要業務、情報資産、システムの範囲
何をリスクと見たか	脅威、弱点、想定される事業影響、優先順位
何を変えたか	検知、対応手順、技術対策、規程、役割分担、例外処理
誰を動かしたか	経営層、事業部門、法務、広報、IT部門、外部委託先
何が残ったか	効果の確認方法、今後の対応事項、残存リスク、次の施策

採用側は「技術対処の先」を見ている

NIST Cybersecurity Framework 2.0は、サイバーセキュリティの活動をGovern、Identify、Protect、Detect、Respond、Recoverの6機能で整理して公開されています。監視や事故対応は主にDetectとRespondに当たりますが、コンサルティングでは事業目標、リスク許容度、役割、方針を扱うGovernや、重要資産とリスクを捉えるIdentifyまでが対象です。

IPAのデジタルスキル標準ver.2.0も、サイバーセキュリティを、業務プロセスを支えるデジタル環境のリスク影響を抑える役割とする基準です。つまり、「設定を変えた」で止まらず、どの業務影響を抑える施策かを書くことが必要です。

運用実績としての記載	コンサル応募で加える視点
アラートを分析した	重大度と重要資産をどう結び、誰へいつ上げる設計にしたか
インシデントへ対応した	事業影響をどう判定し、封じ込め・復旧・対外連携をどう選んだか
脆弱性を修正した	資産の重要度と悪用可能性から期限・例外・再評価をどう決めたか
製品を導入した	脅威と制約を踏まえ、代替案、運用負荷、有効性をどう比較したか

本記事では、厚生労働省job tagのセキュリティ運用・監査の近接分類と、IPAの役割標準、企業の公式採用情報を組み合わせて評価観点を整理します。

SOC・CSIRT・エンジニアで強調する実績は違う

リメディの見解では、応募書類に選ぶ案件は前職の担当範囲によって変えるべきです。SOCならリスクの選別、CSIRTなら有事の判断境界、エンジニアなら統制を実装できる設計理由を優先します。

現在の経歴	前面に出す案件	成果物・証拠	補いたい視点
SOC	重大度定義、検知ルール改善、エスカレーション再設計	検知条件、優先順位表、運用手順、改善前後の本人実績	重要資産・事業影響との接続
CSIRT	封じ込め、復旧、部門横断連携、事後改善	対応手順、連絡体制、判断記録、再発防止計画	停止・継続の比較と残存リスク
セキュリティエンジニア	製品・基盤の選定、設計、導入、有効性確認	比較基準、設計方針、例外処理、運用評価	技術仕様と業務リスクの因果
セキュリティ監査	評価基準、指摘の優先順位、改善フォロー	評価観点、改善計画、責任者、再評価結果	指摘から実行可能な施策への接続

同じ案件を「監視」「調査」「報告」と分割して水増しするより、技術判断の深さが分かる案件、複数部門の合意を動かした案件、現状評価から改善計画まで描いた案件を一つずつ選ぶ方が役割の幅を示せます。

弱く見える書き方を、意思決定が読める文章へ直す

改善例は、そのまま転記する例文ではありません。角括弧の中を自分が確認できる事実へ差し替え、集計期間、自分の担当範囲、チーム成果との境界を説明できる状態にしてください。数値は自分の実績に置き換え、確認できない値や誇張した値を使わないでください。

経歴	Before	Afterの構造
SOC	セキュリティ監視とアラート分析を担当	[重要業務・資産]を対象に、[重大度・調査開始条件]を再整理。[関係者]とエスカレーション基準を合意し、[本人が確認した期間と実績]をもとにルールを改善した。
CSIRT	インシデント対応をリード	[事象]発生時に[事業影響]を評価し、[封じ込めと継続の判断]を関係部門へ提示。[復旧・再発防止]の責任者と期限を定め、[確認できる実施結果]まで追跡した。
エンジニア	セキュリティ製品の導入を担当	[脅威・対象資産]への対策として[複数案]を、検知範囲、業務影響、運用負荷で比較。[選定理由]を合意し、導入後は[本人の実績値]で有効性と残る課題を評価した。

顧客名や攻撃の詳細を出せない場合は、業界、重要業務の種類、判断基準を抽象化します。秘密情報を隠すことと、自分の判断を曖昧にすることは別です。「機密のため非開示」で文章を終えず、公開できる範囲で役割・選択肢・結果を残します。

3社の募集要項から成果指標を逆算する

2026年8月9日に3社の公式採用ページを確認しました。KPMG FASはインシデント対応支援、セキュリティアセスメント、サイバーデューデリジェンス、各種助言を募集職務に挙げています。PwCはサイバー脅威、AIリスク、経済安全保障などの複合課題への対応、デロイト トーマツ サイバーは経営変革をセキュリティ面から支える役割を示しています。

募集要項で求められる経験	職務経歴書で書く項目	成果指標の候補	弱い表現	改善方向
インシデント対応支援	事象、事業影響、初動判断、部門連携、復旧、再発防止	判断・連絡・封じ込め・復旧の本人実績、改善策の実施状況	事故対応を実施	誰が何を決める状態を作ったかまで書く
セキュリティ評価	対象範囲、評価基準、発見事項、優先順位、改善計画	重要リスクの可視化、責任者設定、再評価結果	リスク評価を担当	基準と事業影響から優先順位を説明する
複合リスクへの助言	事業目標、複数のリスク、選択肢、推奨案、残存リスク	意思決定、施策採用、計画化、継続監視の状況	経営層へ提言	比較した選択肢と採用理由を示す
経営変革とセキュリティ	新規事業・DXの目的、必要な統制、例外、実装順序	事業要件と統制の合意、施策の実装・定着状況	DXをセキュリティ面で支援	事業を止めずに何を守る設計にしたかを書く

応募先の支援領域によって案件の選び方を変える

セキュリティコンサルティングは一枚岩ではありません。ガバナンス・リスク支援、インシデント・フォレンジック、技術実装を伴う変革支援では、同じ経験でも前面に出す部分が異なるためです。

支援領域	選ぶ案件	書類で強める論点	避けたい偏り
ガバナンス・リスク	全社評価、規程・基準、第三者リスク、改善計画	経営課題、リスク許容度、統制オーナー、施策順序	規程名の列挙
インシデント・フォレンジック	重大事象の調査、封じ込め、復旧、再発防止	証拠保全、判断時点、部門連携、事業継続	攻撃手法の派手さだけを強調
技術実装・変革	セキュリティ施策の設計・導入	脅威・資産・業務、代替案、例外、運用定着、有効性確認	製品資格と設定項目だけを書く

隣接経験者が補うべき証拠

KPMG FASの募集要項は、ITベンダー等の隣接経験を応募対象に含めている点が特徴です。前職名だけで対象外と決めず、応募先の仕事へつながる証拠の有無を確かめましょう。

経験	すでにある証拠	補う内容
セキュリティ運用	検知、調査、初動、エスカレーション	事業影響、統制変更、改善計画
監査・内部統制	基準、客観評価、指摘、報告	技術的な成立性、改善の実行支援
インフラ・クラウド	設計、構築、可用性、運用	脅威分析、例外管理、リスク受容の判断
セキュリティに隣接しない経験	業務理解、顧客折衝、分析、プロジェクト推進	実務で検証できるセキュリティの案件・役割。学習歴だけで経験者と同じ表現をしない

面接で深掘りされる判断を先に書く

職務経歴書に強い成果を書くほど、面接では判断の根拠まで問われます。書類を仕上げる前に、次の問いへ答えられるか確認してください。

• なぜその資産・業務を優先したのか
• どの代替案を比べたのか
• 技術部門と事業部門の意見が違ったとき、何を判断基準にしたのか
• 自分が決めた範囲と、責任者へ提案した範囲はどこか
• 対策後も残ったリスクを誰がどの条件で受け入れたのか
• 同じ状況を別企業で扱うなら、何を共通化し、何を変えるのか

特にCSIRT案件は、結果を知った後なら正しい判断が簡単に見えます。面接では、情報が揃っていない時点で何を根拠に動いたか、追加情報で判断をどう変えたかまで準備しておくと、再現性を説明しやすくなります。

インシデント案件は時系列ではなく判断点で構成する

SOCやCSIRTの経歴書は、「検知し、調査し、封じ込め、復旧した」という時系列になりがちです。この書き方では手順を正確に実行したことは伝わっても、セキュリティコンサルとして他社の状況を診断し、選択肢を示せるかは分かりません。時系列の中から、情報が不足した状態で本人が判断した箇所を抜き出します。

判断点	職務経歴書に書くこと	面接で補うこと	書かない情報
重大度判定	重要資産、業務影響、確度、優先した根拠	追加情報で判断を変えた条件	識別可能な顧客名・未公表被害
封じ込め	事業影響とリスク比較	事業責任者・IT・法務との役割境界	悪用可能な詳細手順
復旧	復旧条件、確認した証拠、残した監視	完全復旧を待たず再開した場合の受容条件	内部構成・アクセス情報
再発防止	原因、変更した統制、責任者、確認時期	採用しなかった対策と理由	チーム成果を本人だけの成果にする表現

結果を知った後の正解ではなく、その時点で利用できた証拠を示すことが重要です。たとえば端末隔離を選んだなら、観測した兆候、対象端末の重要性、横展開の可能性、業務停止の影響をどう比較したかを書きます。判断が後に修正された場合も、追加情報と変更理由を説明できれば、状況に応じて仮説を更新した経験になります。

運用改善はCurrent・Target・優先施策へ分ける

検知ルールの追加、EDRの展開、脆弱性対応の短縮といった実績は、その施策だけを書いてもコンサル業務との接続が弱いものです。NIST CSF 2.0のProfilesは、現在と目標の状態を比較して改善機会を特定する考え方を示します。職務経歴書でも、現状、目標、差分、優先施策、効果確認の順にすると、技術変更をリスク改善として説明できます。

たとえば脆弱性管理なら、検出件数を成果にせず、重要資産が一覧と結び付いていなかった、対応期限が事業影響を反映していなかった、例外の承認者と再評価日が不明だった、と現状を定義します。目標は「すべて直す」ではなく、重要度・露出・事業影響で期限を決め、例外を期限付きで承認し、残存リスクを見直せる状態です。

成果物	運用実績から示す証拠	コンサル支援での使い道
現状評価	対象範囲、評価基準、確認した証跡、除外条件	診断の再現性と追加調査の設計
目標状態	守る業務、許容するリスク、必要な役割・統制	経営・事業側との合意
改善ロードマップ	施策の依存関係、費用、期限、責任者	複数案の比較と実行可能性
有効性確認	指標、確認周期、例外、追加修正	導入後の定着・継続改善

NISTのTiersを単純な成熟度の順位として扱い、「Tierを上げた」とだけ書くのは避けてください。組織のリスク管理実務をどの観点で評価し、どの変更が事業上必要だったかを示します。フレームワーク名は判断を整理する道具であり、本人の成果そのものではありません。

支援領域ごとに提出する三案件を入れ替える

一つの職務経歴書をすべてのセキュリティコンサル求人へ出すと、技術の幅は伝わっても、応募先で使える証拠が薄まります。ガバナンス・リスク支援では、全社評価、第三者リスク、規程・基準、改善計画を主役にします。インシデント・フォレンジックで選ぶのは、証拠、判断時点、封じ込め、復旧、部門連携、再発防止です。技術変革では、製品名より脅威モデル、代替案、例外、導入後の有効性を前へ出します。

応募領域	一件目	二件目	三件目	外しやすい案件
ガバナンス・リスク	現状評価と重要リスク	統制設計と部門合意	ロードマップと定着確認	自分が設定変更だけを担った案件
インシデント・フォレンジック	重大度・初動判断	部門横断の封じ込め・復旧	原因分析と再発防止	詳細を守秘できず説明不能な案件
技術変革	脅威・資産からの要件	製品・方式の比較	例外管理と効果確認	製品名と資格だけで終わる案件
第三者・サプライチェーン	評価基準と対象選定	契約・改善要求・例外	継続監視と再評価	チェックシート配布だけの案件

三件すべてが大規模である必要はありません。小さな改善でも、本人がリスクを特定し、選択肢を比較し、責任者と合意し、実施後の効果を確かめたなら、判断の連続性があります。反対に著名なインシデントでも、決められた情報収集だけを担った場合は、その役割境界を正直に書き、別案件で設計や合意形成を補います。

入社後に深める専門性を応募理由へつなげる

セキュリティコンサルのキャリアパスは一つではありません。インシデント調査・フォレンジックの専門性を深める道、GRCや第三者リスクで全社的な統制を設計する道、クラウドやゼロトラストなど技術変革を支援する道があります。現在のSOC・CSIRT・エンジニア経験から何を残し、どの責任を増やしたいかで志望領域を決めます。

「経営に近い仕事がしたい」だけでは、なぜその求人かが伝わりません。検知・対応で得た知見を全社のリスク優先順位へつなぎたいのか、インシデント判断を他社でも再現できる調査手法へ深めたいのか、技術選定を業務定着まで支援したいのかを一文にします。入社後の案件を確約する表現は避け、公式募集要項で担当領域を確認してください。

年収交渉で説明できる実績の粒度

本記事では職種平均の年収を推定しません。年収交渉に備えるなら、実績を大きく見せるのではなく、責任の範囲と再現性を明確にします。顧客・自社の規模を出せない場合も、対象業務の重要性、関係部門、意思決定への関与、実装・定着までの範囲は整理できます。

交渉材料	確認すること
責任範囲	どこまで本人が担ったか
複雑性	対象資産、関係部門、規制、委託先、時間制約を説明できるか
成果	本人が根拠資料や集計条件を説明できる実績か
再現性	別の企業・業界でも使える判断手順と、固有条件を分けられるか

SOC・CSIRT・エンジニアで一案件の主語を変える

SOC経験者にとって、処理量よりも優先順位の設計を主語に据えるのが基本です。「アラートを監視した」ではなく、どの重要資産と脅威を対象に検知条件を見直し、重大度、調査着手、エスカレーションをどう変えたかを書きます。誤検知を減らした場合は、単に削減率を置かず、見逃しを増やさないための確認、例外、再評価を添えます。

CSIRT経験者は、速い初動だけでなく、複数部門の判断を束ねた場面を主語にします。たとえば業務停止を伴う封じ込めで明示するのは、技術的な危険性、停止対象の重要度、継続した場合の影響、代替手段、意思決定者です。広報・法務・個人情報・顧客対応に関わる場合は、各専門家の判断を自分の成果にせず、自分が提供した証拠と統合した論点を分けます。

セキュリティエンジニア経験者は、導入製品ではなく方式を選んだ理由を主語にします。対象脅威、既存構成、可用性、利用者負荷、運用体制、費用を比較し、どの案を採り、どのリスクを残したかを示します。クラウド設定や認証方式の変更で選ぶべきなのは、設計だけでなく、例外、移行、監視、利用部門への定着まで書ける案件です。

監査・内部統制から移る人は、基準との適合だけで終わらせず、指摘の技術的な成立性と改善の実行可能性を確認した経験を探します。インフラやクラウドから移る人は、可用性・性能の設計と、脅威・リスク受容の判断を分けます。隣接経験を大きく見せるのではなく、すでに持つ証拠と、応募前に補うセキュリティ判断を一つずつ示す方が誠実です。

成果数値は集計条件と本人の寄与をセットにする

調査着手時間、誤検知、脆弱性対応期限、復旧時間などは、セキュリティ業務で使いやすい数値です。しかし、対象範囲や集計期間が違えば比較できず、チーム全体の改善を本人の成果として書く危険もあります。数値を置く前に、母集団、期間、除外条件、比較時点、本人が変えた要素を確認してください。

数値候補	同時に書く条件	本人の寄与	数値を使わない判断
調査着手までの時間	重大度、対象時間帯、計測起点・終点	受付、優先度、通知、当番設計の変更	起点が途中で変わり比較不能
誤検知・アラート量	対象ルール、期間、見逃し確認	ルール調整、抑制条件、再評価	削減だけで安全性を説明できない
脆弱性対応	重要度、資産範囲、期限、例外	優先順位、責任者、再評価の設計	検出件数しか残っていない
封じ込め・復旧	事象類型、業務影響、判断時点	手順、連絡、判断材料の改善	機密上、条件を説明できない

数値を出せない場合は、成果を曖昧にする必要はありません。以前は誰が判断するか不明だった例外に責任者と期限を設定した、重大事象の報告に必要な証拠を標準化した、復旧後の監視と事後レビューを手順へ組み込んだ、といった状態変化を示します。数字の有無ではなく、対策前後で意思決定と統制がどう変わったかが重要です。

職務要約で技術経験と助言責任を一度に伝える

職務要約は、保有資格や製品名から始めず、現在の役割、扱ってきた事業リスク、代表的な判断、志望領域の順でまとめます。SOC経験者なら監視年数ではなく、重要資産の検知・初動からルール改善や経営報告へ役割を広げたことを置きます。CSIRTで前面に出すのは、技術対処と事業継続の判断をつないだ経験です。

技術スタックは本文の案件を理解するために必要な範囲へ絞ります。利用製品をすべて列挙するより、クラウド、ネットワーク、エンドポイント、IDなど、どの領域で設計・運用・調査を担ったかを示します。資格は知識の証拠として記載し、リスク受容、優先順位、合意形成を担った経験の代わりにはしません。

最後の一文では「上流へ進みたい」とせず、インシデント判断を他社でも再現できる支援へ深めたい、技術施策を全社リスクと改善ロードマップへつなぎたい、第三者リスクの評価から定着まで担いたい、など、応募先の仕事内容に対応する責任を示します。職務要約と代表案件の主張が同じ方向を向けば、採用側が詳細を読み進めやすくなります。

書類の冒頭と各案件で専門領域がばらばらに見える場合は、共通する判断を一つ選びます。たとえば「重要資産と事業影響から優先順位を決め、技術部門と事業部門が運用できる統制へ変えた」という軸です。SOC、CSIRT、クラウド設計の経験が混在していても、同じ判断軸に沿って案件を並べれば、経験の幅が散漫ではなく一貫した強みとして読めます。

案件ごとの記載量は、技術の難しさではなく応募先との対応で決めます。志望する支援領域に最も近い案件へ、判断条件、代替案、役割境界、実施後の確認を厚く置きます。補助案件は異なる能力を一つだけ加え、同じ強みを重ねません。これにより、読み手は最初の数分で専門領域と助言責任の両方を確認できます。

提出前には、各案件の主語と根拠資料の種類をもう一度そろえてください。

提出前に3件の案件を選び切る

最後に、技術判断、部門横断の合意、改善ロードマップの3種類から一件ずつ候補を選びます。すべてを一つの案件で満たす必要はありません。案件ごとに「守る対象、リスク、判断、統制、効果、残る課題」を一行で書き、説明できない欄がある案件は補足資料を探します。

自分で進めやすい状態	第三者と整理した方が早い状態
応募先の支援領域が決まり、対応する案件を3件選べている	ガバナンス、事故対応、技術実装のどこを狙うか決まっていない
成果数値の集計条件と自分の寄与を説明できる	チーム成果と自分の判断を分けられない
機密を伏せても意思決定の流れを話せる	情報を伏せると「対応した」だけの文章になる
書類の各主張に面接で答える準備がある	残存リスクや代替案を問われると説明が止まる

提出直前の確認では、文章の華やかさより、事実の境界が揃っているかを優先してください。何を知り、何を決め、誰と合意し、どこまで実行したかが一貫していれば、SOC・CSIRT・エンジニアの経験をセキュリティコンサルタントの仕事へ無理なくつなげられます。