Back Book

What the back book means in practice

The back book is the legacy population that predates a new control, policy, or assurance requirement. It matters because a security rule can be fully enforced for new joins while the pre-existing population remains outside the intended standard until it is found, assessed, and migrated.

In other words, the term describes a transition problem, not a product feature. The operational challenge is usually less about defining the rule and more about dealing with the accounts, customers, or users that were created before the rule existed.

Why the back book creates assurance gaps

The back book is where uneven assurance most often appears. New registrations may pass stronger checks, but older records may still rely on weaker evidence, incomplete identity data, or obsolete policy logic, which creates a split population inside the same service.

This is especially important when a control is introduced after launch, because the service can appear compliant at the front door while a large historical cohort remains untouched. That gap is often the real governance issue, not the policy itself.

Age assurance, migration, and legacy cohorts

In age assurance, the back book is the set of accounts that may never have been verified to the newly expected standard. Organisations need to decide whether those users can be re-verified, risk-rated, restricted, or removed, because the legacy population may not support the same trust level as new users.

The term is therefore most useful when a service changes its assurance posture over time. A younger cohort can be brought in under the new process, but the historical cohort often needs a separate migration path with clear decision rules and user communication.

What makes the back book hard to govern

The back book becomes difficult when record quality is poor, ownership is unclear, or the service has grown faster than its ability to re-check older accounts. The larger and older the population, the more likely it is that exceptions, dormant accounts, and stale assurance states will accumulate.

It also creates a policy consistency problem. A service may define a current standard, but unless the legacy population is explicitly mapped, the organisation may not know which accounts are protected by the new rule and which are still operating under the old one.

Risk and Threat Considerations

The back book creates a concentrated exposure because legacy accounts may retain access or eligibility without meeting the newer assurance standard. That can leave an organisation with a vulnerable historical cohort that is harder to distinguish, harder to remediate, and easier to overlook than newly onboarded users.

Failure mechanism: Older accounts bypass the new control path because they were created before the policy change, were never re-validated, or were exempted during rollout.

Impact: The service can continue operating with a hidden population that has weaker assurance, which increases the chance of unauthorised access, policy inconsistency, and failed compliance evidence.

Practitioner Guidance

Governance implication: Treat the back book as a separate population with its own ownership, review cadence, and migration status. A policy change is incomplete until the legacy cohort is explicitly accounted for, not merely because the new joiner flow has been updated.

What to watch for: Look for services where the current control standard is newer than the account base, especially when legacy users were onboarded under looser rules or before reliable verification was available. The practical question is not whether the policy exists, but whether the back book has actually been brought into scope.

Related resources from NHI Mgmt Group

• Why do IAM findings keep coming back in cloud environments?
• Why does scaled-back governance increase breach risk?
• How do security teams decide whether HRIS write-back is safe in joiner automation?
• What breaks when identity programmes cannot map access back to a real subject?