Your emulation gap register has forty open rows and no closures in two quarters — what do you do?

## Read the register before you read the estate A register of proven gaps that never closes is telling you something about your own process, not about your adversaries. Forty open rows over two quarters means either the routing step produced rows nobody agreed to, or the rows have no closure criterion, or the exercise programme is generating findings faster than the organisation can absorb them. All three are fixable; none is fixed by running another exercise. ## Sort the rows by why they are stuck Go row by row and classify: - **No owner.** Routing never actually happened; the finding was written down and filed. These are not stalled, they were never started. - **An owner who never agreed.** A ticket was opened in someone else's backlog and the exercise team declared it delivered. This is the most common failure and the most misleading, because the register looks correctly populated. - **No closure test.** The row says fix the gap without saying what proves it fixed. Nobody closes a row they cannot prove. - **Genuinely in progress.** A real change with a real date. Leave these alone. - **Overtaken.** The system was rebuilt, the workload retired, the technique no longer applies. Close them and say so. The distribution of that sort is your actual finding, and it is worth presenting as such. ## Define what closes a row This is the part specific to proven gaps. A remediation ticket closes when an engineer believes the change is deployed. A gap row closes when the **technique is executed again and the outcome has changed** — blocked at admission, or alerted within the expected window, observed by the same team that proved the miss. Until that is written into the row, closure is an opinion. Write the re-execution into the row at routing time, with a date. It gives the owner an unambiguous target and it gives you the evidence that the register is real. ## Stop intake If remediation capacity is the constraint, more findings do not help. Pausing or slowing the exercise cadence while the backlog is worked down is a defensible call, and saying so out loud is stronger than quietly letting the register rot. A programme that only produces findings is producing debt. ## Re-route rather than nag Many stalled rows are prevention rows sitting in a team's backlog behind product work. Instead of escalating each one, ask what destination you can reach without them: - Convert to an **interim detection** the security team owns and can ship this week, and leave the prevention row open with its own date. - Split a large prevention row into the part the owner can do now and the part that needs a migration. - Where the technique no longer matters — the workload is gone, the path leads nowhere — close it as overtaken instead of carrying it. ## Accept the tail, out loud Whatever survives all of that is a set of gaps nobody is going to fix. Recording them as accepted, each with the person who accepted it and a revisit date, is not giving up; it is the difference between a residual risk somebody owns and a residual risk hidden inside a long list. It also shrinks the register to rows that are genuinely moving, which is what makes the register usable again. ## Rank what is left If twenty rows remain and capacity covers five, rank by adversary reality rather than by exercise order: is the technique in current use against organisations like yours, does the gap sit on a path to something that matters, and would closing it also close several other rows because they share a control. A single admission change or a single logging source often retires a cluster of rows at once. ## What a healthy register looks like Few rows, each with a person outside the exercise team, a routing decision made deliberately, a date, and a booked re-execution. Rows leave it in both directions — closed by proof, or accepted by name — and the number of open rows is roughly stable between exercises rather than monotonically climbing.