Case Study: Conducting a Gap Analysis

This lesson is different from the others — instead of introducing new concepts, it walks through a single, connected, realistic gap analysis for a fictional company, SecureLearn, a small cybersecurity training platform. Every finding below is a composite of the kind of thing that shows up repeatedly in real gap analyses — nothing here is hypothetical or exaggerated for teaching effect.

The setup

SecureLearn is a small, Django-based ed-tech platform, hosted on a cloud provider, run by a lean team. Before pursuing ISO/IEC 27001 certification, they commission an internal gap analysis across clauses 4-10 and all 93 Annex A controls. The analysis is done by directly examining the codebase, configuration, and infrastructure — not by asking the team to self-report.

Finding 1: A stale document claiming a fixed control

The team has an old security audit document claiming a specific technical control — a CSRF (cross-site request forgery) protection setting — was "verified fixed" months earlier. But a direct code search for that exact setting in the current codebase returns zero results. The setting the document claims exists simply isn't there.

The lesson: when a document and the actual system disagree, the system's current state is the evidence that matters, not the document's claim — however official-looking the document is. This connects directly to lesson 11's traceability principle: an SoA entry (or any control claim) is only as good as the evidence actually backing it right now, not the evidence that existed when someone last wrote about it. The gap analysis flags this explicitly as a "circular evidence" problem: the only document resembling a risk register was itself unreliable, so it couldn't be used as evidence of anything.

Finding 2: Evidence the codebase alone could never reveal

Early in the analysis, backups appeared to be a serious gap: the application's own backup script wrote dumps to local disk on the same server as production, with no off-site copy — a classic single point of failure. This was documented as a significant finding.

Later, the SecureLearn team mentioned, almost in passing, that their infrastructure provider's dashboard shows automatic, provider-managed server snapshots running daily, retained for a week, completely separate from anything the application code does.

The lesson: a codebase-only review has a blind spot — infrastructure-level configuration in a provider's console is invisible to anyone only reading source code. The gap analysis had to be honestly revised: the finding wasn't wrong about the application-level backup script, but it had overstated the overall risk by not asking about infrastructure-level protections that exist outside the repository entirely. Good gap analysis practice means explicitly asking "what exists in consoles/dashboards we haven't looked at?" — not just trusting that a thorough code review is a thorough gap analysis.

Finding 3: Strong on one control, silent on its close cousin

SecureLearn maintains an excellent internal log of every law, regulation, and contractual clause that applies to their business — genuinely strong evidence for the "legal and regulatory requirements" control. But when asked where end-user personal data is actually stored, for how long, and how a deletion request would be handled, no one could produce an answer. No inventory of personal data existed anywhere.

The lesson: this is precisely the 5.31-vs-5.34 distinction from an earlier lesson, playing out in a real assessment. Being excellent at tracking that a law applies (5.31) says nothing about whether the specific operational practices that law requires (5.34, for personal data specifically) have actually been implemented. Auditors — and good gap analyses — test both, separately, because organizations routinely excel at one while neglecting the other.

Turning findings into a prioritized list

A gap analysis isn't useful as an unordered pile of findings — it needs prioritization. SecureLearn's analysis sorted findings roughly by (impact if left unaddressed) × (ease of remediation):

1. Quick, high-value fixes first: the stale CSRF setting (Finding 1) was a same-day code change once discovered.
2. Corrections to overstated risk: the backup finding (Finding 2) was downgraded from "critical gap" to "partially covered, needs a documented second layer" once the infrastructure evidence was found — an honest correction, not a defensive one.
3. Genuine open gaps needing a business decision: the PII inventory gap (Finding 3) couldn't be fixed with a code change alone — it required the organization to actually decide on and document data retention practices, a business decision no amount of engineering effort could substitute for.

This ordering — not the order findings happened to be discovered in — is what makes a gap analysis actionable rather than just a long list of scary-sounding problems.