A policy gap analysis is the process of comparing a written policy against a baseline of what it should cover, to find what's missing before an auditor finds it for you. It's one of the most routine pieces of GRC work: policies get written, frameworks evolve, and nobody consistently rechecks the two against each other unless someone owns that job.
How it actually works
Take a draft Access Control Policy. A baseline checklist for a complete access control policy might include: unique user IDs, password requirements, an access approval process, an offboarding/revocation timeline, periodic access review, and multi-factor authentication for privileged accounts. Line up the draft policy's clauses against that checklist, one by one. Whatever the checklist has that the draft doesn't mention is a gap.
A real example
A draft policy might clearly cover unique IDs, password rules, an approval process, and a 5-business-day offboarding requirement — four solid clauses. But if it never mentions re-checking who still needs access after it's granted, or requiring a second authentication factor for privileged accounts, those are two real gaps, even though the policy reads as reasonably complete on its own. This exact scenario is what the Policy Gap Analysis Challenge walks through.
Why this catches things a first read misses
Reading a policy top to bottom tells you what's there. It doesn't reliably tell you what's absent — that requires a checklist to compare against, because the human eye is bad at noticing something that simply isn't mentioned. This is exactly why gap analysis is a structured exercise rather than "read it and see if it looks okay."
What happens after you find a gap
A found gap becomes a to-do: either the policy gets rewritten to add the missing clause, or, if the control genuinely doesn't exist yet, it becomes a new risk register entry until it's built. Either way, a policy gap analysis feeds directly into the same risk-tracking and control-testing loop as the rest of GRC work.