Security GAP Analysis — Prioritized by Budget and Time

A GAP analysis built on the team's own cost/effort delivery data, so recommendations could be re-prioritized to match a client's real budget and headcount — not a generic checklist.

✓ Turned inconsistent, advisor-dependent GAP analyses into one reusable methodology — delivered ~45 times over three years, prioritized by real cost/effort data instead of gut feel

References available upon request →

Approach

A GAP analysis in this market is usually one of two things: a vendor's assessment that conveniently points toward their own product, or a formal audit against a single framework that tells you whether you're compliant — not what to fix first, or what it will cost. On top of that, the team's own analyses had a third problem: every advisor ran them their own way, so the same client could get a different result depending on who showed up. As the methodology's inventor and lead, I built one reusable framework instead — grounded in recognized standards (NIST CSF, CIS Controls, BSI Grundschutz) so findings would hold up to scrutiny, but driven by the team's own real cost and effort data so the output was a prioritized action plan, not a scorecard and not a sales pitch.

Implementation

  • Built a shared effort/cost database from the team's own delivery history — implementation time-to-value per control (standing up a SOC measured in years, enabling SSL decryption measured in days) and a rough cost band for each, precise enough to separate "expensive" from "cheap," not so precise it became a budgeting exercise
  • Used that database to re-rank GAP findings by a client-specific weight — the same set of findings could be reordered for a budget-constrained client versus a headcount-constrained client, instead of handing every client the same generic priority list
  • Built a maturity-scoring methodology spanning six domains: network, identity, cloud, endpoint, datacenters, and remote-access/VPN
  • Standardized the interview and scoring process specifically to stop outcomes depending on which advisor ran the engagement
  • Delivered the analysis roughly 45 times over three years across a team of three managing consultants, as the methodology's original architect and team lead

Outcome

The cost/effort database is what made the findings actionable instead of aspirational — and the analysis caught things a checklist audit didn't. In one engagement, IAM was fully deployed but never extended to the most critical systems, because admins were afraid of losing access if something broke; a standard audit would have marked IAM "in place" and moved on. In another, a newly deployed IPS was running in passive-monitoring mode only — visible in the architecture diagram, invisible in the audit, and providing zero active protection. Findings like these are why the methodology prioritized by operational reality, not by what was technically deployed on paper.

Interested in working together?

Reach out and let's discuss your project.

Get in Touch