A policy register is a list of every compliance policy your firm maintains, with metadata about each one: who owns it, when it was last reviewed, what regulatory obligations created it, and whether it is current. In most compliance teams, the register exists — but two of those four data fields are missing or outdated, which makes the register useful for inventory purposes and nearly useless for anything else.
The version that actually supports regulatory change management — the one where a new FCA instrument arrives and you can immediately answer "which of our 60 policies does this touch?" — requires a different architecture than most firms have built.
What a policy register is for (and what it is not for)
The first mistake is treating the policy register as a document management system. Its job is not to store the policies themselves — your SharePoint or document management platform does that. The register is a metadata layer: a structured inventory that describes each policy, its obligations source, its review cadence, its current status, and who is accountable for it.
A well-functioning register enables three things: supervisory readiness (you can produce a complete, current inventory when an examiner asks), change management triggering (when a regulation changes, you can identify affected policies within minutes rather than hours), and review cycle discipline (overdue reviews show up as exceptions in your compliance dashboard, not buried in someone's calendar).
We are not saying a policy register needs to be technically complex. A well-structured spreadsheet can serve these functions for a 15-person compliance team. What matters is the structure and the discipline to maintain it — not the platform.
The four data fields that make a register functional
1. Policy name and scope
Obvious, but worth being precise about. The scope field should describe which business activities, entities, or customer types the policy governs — not just the title. "Anti-Money Laundering Policy" is insufficient. "AML Policy — UK Payment Services activities, customers onboarded under FCA-authorized payment institution" tells you exactly when this policy applies and when a different policy applies (for example, for US-domiciled customers governed by FinCEN rules).
2. Regulatory source obligations
This is the field most registers are missing, and it is the most important one for regulatory change management. Each policy should be mapped to the specific regulatory instruments that created the obligation it implements. For an AML policy covering UK payment services, that might be: the Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017 (as amended), FCA SYSC 6.3 (systems and controls for financial crime), and the JMLSG guidance relevant to the firm's business lines.
When the FCA amends SYSC 6, you query your register by regulatory source and immediately see all policies that reference SYSC 6. Those are the policies that need impact assessment. Without this field, you are doing a manual cross-reference every time, which is why impact assessment takes two days instead of twenty minutes.
3. Control owner and review cadence
Every policy needs a named human who is responsible for ensuring it remains current, triggers reviews when the regulatory source changes, and signs off on the current version. This is not the CCO — the CCO is accountable at the program level. Control owners are the business-line or function heads who have subject-matter ownership of each policy's subject area.
Review cadence should vary by policy risk: policies touching fast-moving regulatory areas (AML, consumer duty, operational resilience) warrant annual or biennial reviews; stable policies (data retention, record-keeping) may be reviewed every two to three years. The cadence should be documented and tracked against the last review date, with overdue status surfacing as an exception.
4. Current status and version history
Current status needs more than a "yes/no" field. Useful statuses are: Current (reviewed within cadence, no pending regulatory changes), In Review (actively being updated due to regulatory change or scheduled review cycle), and Overdue (past review date with no scheduled update in progress). Version history — at minimum a date and brief description for each revision — is necessary for audit purposes. When a supervisory examiner asks "when did your firm update this policy, and in response to what?", the register version history should answer that question directly.
Why static spreadsheets fail at scale
A spreadsheet policy register works until the combination of policy count and regulatory change volume exceeds what a spreadsheet can reasonably track. That threshold is different for every firm, but consider a mid-size asset manager covering EU, UK, and Singapore operations with approximately 90 policies across three regulatory entities. When 40 or 50 regulatory changes arrive in a quarter — a realistic number for a firm in that regulatory footprint — manually updating the "regulatory source" mapping in a spreadsheet, tracking which changes triggered which review, and maintaining accurate status across 90 rows becomes a maintenance burden that either consumes significant analyst time or gets deprioritized.
The failure modes are predictable: the register falls behind by one or two quarters; status fields stop being updated in real time; the regulatory source mapping becomes stale after a few instrument rounds; and the register transitions from a live operational tool to a static document that reflects a snapshot of the program three years ago. At that point, it is only useful for producing an inventory list — not for the change management function it was supposed to support.
The solution is not necessarily software. For many firms, it is better structure and a clear owner whose performance is measured in part on register currency. But for firms handling more than 15-20 jurisdictions or more than 80 policies, a purpose-built or GRC-integrated register that receives change alerts automatically — so that a regulation change flags relevant policies directly — significantly reduces the manual overhead.
The one-time investment that pays off every regulatory cycle
Building the regulatory source mapping for the first time is the work that teams avoid because it looks expensive. For a firm with 60 policies and four covered jurisdictions, a thorough mapping exercise — going policy by policy, identifying every regulatory instrument referenced, and entering the structured citation — takes an estimated 40 to 60 hours of compliance analyst time, spread across two to four weeks.
That investment pays back the first time a major regulatory change arrives. Instead of a two-day cross-referencing exercise, the impact assessment takes a morning. For a firm experiencing 60 to 80 regulatory changes per year across its jurisdictions, the time savings compound quickly. And the audit readiness benefit — being able to trace every policy back to its source obligation on demand — has value that is harder to quantify but clearly real when an examination starts.
What to fix first
If your policy register is a spreadsheet with missing regulatory source fields, the priority sequence we recommend is: first, add the regulatory source field and complete it for your highest-risk policies (AML, consumer duty, capital adequacy — whatever your top-10 supervisory risk areas are). Second, assign a named control owner to every policy and ensure they know they own it. Third, set up a calendar process to surface overdue reviews as exceptions. Fourth, connect the monitoring of regulatory changes to the register by circulating alerts to control owners when their source obligations appear in a new publication.
The last step is where Fynrex sits in this process: we surface the regulatory change against your mapped policy register, so control owners receive a structured alert that says "this FCA instrument updated SYSC 6.3, which you have mapped to your AML Policy and your Financial Crime Risk Framework." The gap assessment is still human work — but it starts with the right policies already identified.