This is a ready-to-use register for the data flow mapping program as a whole, not for one data element. A single map is a project; a site has hundreds of candidate data elements and will never map them all at once, so the program lives or dies on a visible, defensible backlog. This register is the master tracker: it scores and ranks the candidates, records which are mapped and which are not, and carries forward the shared boundary controls one map already established so later maps do not re-litigate the same spreadsheet or the same shared drive. It is the backlog location referenced by the SOP for building and maintaining data flow maps and it pairs with the Data Flow Map Worksheet, which is the fill-in tool for one element once that element reaches the top of this list. Replace every <<FILL: ...>> placeholder with your own specifics and route it through your normal document control, review, and approval. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.
Why this register exists
A criticality assessment tells you what matters. It does not tell you what to map first when the same tier holds a dozen elements, some of which move through a single validated interface and some of which pass through three manual re-keys on the way to the record of record. Ranking by criticality alone leaves that tie unresolved and, in practice, tends to get resolved by whichever data element made the most noise that quarter rather than by exposure. This register scores each candidate on criticality and on a manual-transfer-step count, a simple proxy for exposure, and ranks the backlog by the product of the two, so the order in which elements get mapped is a documented decision rather than a habit. It also tracks the mapping status and periodic-review clock for elements already mapped, and the shared boundary controls a given map already covers, so the same load-bearing spreadsheet or shared drive is not re-discovered and re-controlled from scratch on every pass.
Document control header
| Field | Entry |
|---|---|
| Document title | Data Flow Map Coverage and Prioritization Register |
| Document number | <<FILL: LOG-ID, e.g. LOG-DI-004>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Register owner | <<FILL: role, e.g. Data Integrity / Data Governance Lead>> |
| Approvers | <<FILL: e.g. Head of Quality Assurance>> |
| Applies to | <<FILL: sites / business units in scope>> |
| Scoring basis | <<FILL: how criticality score is sourced, e.g. from the data criticality and risk assessment>> |
| Review cadence | <<FILL: e.g. backlog re-scored quarterly, coverage milestone tracked monthly>> |
How to use this register
- Set the document number, owner, and approvers in the header.
- Pull candidate data elements from the system inventory and the data criticality assessment, not from memory. A candidate is any GxP data element that has not yet been walked end to end and captured on a worksheet.
- Score each candidate for criticality (use the same scale as your data criticality assessment) and for manual-transfer exposure (a plain count of the manual export, transcription, re-key, and hand-off steps in its likely flow, estimated from the process owner if the flow has not been formally walked yet).
- Multiply the two scores to set the priority score and rank the backlog. Where your risk policy weights criticality more heavily than exposure, or the reverse, state the weighting formula in the header and apply it consistently; do not change the formula element by element.
- Work the backlog top to bottom. When a map is complete, update mapping status, map owner, last review date, and the shared boundary controls column with anything reusable for the next elements in the queue.
- Re-score and re-rank on the cadence in the header, and immediately whenever a new candidate surfaces (a new system, a new process, a finding from an inspection or an internal audit) or a completed map reveals that the real flow was more, or less, manual than estimated.
- Track the coverage milestone (for example, all high-criticality elements mapped within a defined window) as a single line the register owner can report without reassembling it from individual maps.
Field definitions
| Field | What goes in it | Format / allowed values |
|---|---|---|
| Element ID | Unique identifier for the candidate data element | Short code, e.g. DFM-014 |
| Data element | Name and one-line boundary description of the element, matching the scope statement it will carry onto its worksheet | Text |
| System(s) | The system(s) the element is expected to pass through | Text, comma-separated |
| Criticality score | Score from the data criticality and data risk assessment | Numeric, e.g. 1 to 5, or High / Medium / Low mapped to a number |
| Manual-transfer exposure score | Count of manual export, transcription, re-key, or hand-off steps in the flow | Integer count |
| Priority score | Criticality score multiplied by exposure score (or your stated weighted formula) | Numeric |
| Priority rank | Position in the backlog after sorting by priority score, ties broken by criticality | Integer |
| Mapping status | Current state of the mapping effort for this element | Not started / In progress / Complete / Periodic review due |
| Map owner | Person or role accountable for building and maintaining this element’s map | Role / name |
| Last review date | Date the map was last built or periodically reviewed | Date |
| Shared boundary controls reused | Controls already established on another map that apply to a boundary this element also crosses (a named spreadsheet, shared drive, or manual export) | Text, reference the source map |
| Notes | Anything that changes the ranking logic for this element, or context for a reviewer | Free text |
Register (blank)
| Element ID | Data element | System(s) | Criticality score | Exposure score | Priority score | Rank | Mapping status | Map owner | Last review date | Shared boundary controls reused | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Coverage summary (derived, for periodic reporting)
Summarize the register by mapping status and by criticality tier so the register owner can state coverage in one line without recounting rows by hand.
| Criticality tier | Total candidates | Mapped (complete) | In progress | Not started | Periodic review due | % complete |
|---|---|---|---|---|---|---|
| High | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Medium | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Low | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Acceptance criteria
- Every GxP data element identified through the system inventory or the data criticality assessment appears as a row, whether or not it has been mapped yet.
- Each row carries a criticality score and a manual-transfer exposure score, and the priority score is calculated consistently using the stated formula.
- The backlog is ranked by priority score, and the rank is kept current, not calculated once and left static while the underlying scores drift.
- Completed maps show mapping status, map owner, last review date, and any shared boundary controls the map established for reuse.
- The coverage summary can state, without manual recount, how much of the high-criticality tier is mapped and what remains.
- The register is under change control and re-scored on the stated cadence, plus whenever a new candidate or a completed map changes the picture.
Roles and responsibilities
| Role | Responsibility |
|---|---|
| Data integrity / data governance lead (register owner) | Maintains the register, sets and documents the scoring formula, runs the re-scoring cadence, reports coverage. |
| System or process owner | Supplies an honest exposure estimate for candidates in their area and confirms it once the element is actually mapped. |
| Map owner (per element) | Builds or maintains the map for their assigned element, updates status and last review date, and flags reusable boundary controls back to the register. |
| Quality Assurance | Approves the register, the scoring formula, and the coverage milestone; uses the register in inspection defense of the mapping program’s scope and sequencing. |
| Validation | Confirms that a completed map’s mapping status reflects a map that also matches the validated state of the systems it crosses. |
Regulations this supports
EU GMP Annex 11 (computerised systems, including the system inventory expectation and the data integrity lifecycle principle); 21 CFR Part 11; FDA Data Integrity and Compliance With Drug CGMP: Questions and Answers (final, December 2018); MHRA GxP Data Integrity Guidance and Definitions (March 2018); PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments; ICH Q9(R1) (Step 4, January 2023), Quality Risk Management, for the risk-based prioritization principle this register operationalizes.
Cite these by number and title only and confirm the current version before you rely on any of them.
Retention
Retain the register and its superseded versions as controlled records for not less than <<FILL: retention period per records policy>>. When an element’s mapping status reaches Complete, keep its row in this register even after the detailed worksheet moves to its own document control, so the priority history and the reuse chain remain visible.
Filled specimen
The following shows a representative backlog snapshot using the same six illustrative candidate elements and scoring logic as the worked example in the Building a GxP Data Flow Map article, so the two are consistent. Company, system, and owner names are fictional and used only to illustrate format.
Register header (specimen)
| Field | Entry |
|---|---|
| Document title | Data Flow Map Coverage and Prioritization Register |
| Document number | LOG-DI-004 |
| Version | 2.0 |
| Effective date | 10 September 2026 |
| Register owner | Data Integrity Lead (S. Okoye) |
| Applies to | Acme Bio, Site B (drug substance, drug product, and QC) |
| Scoring basis | Criticality score from the site data criticality assessment, 1 (low) to 5 (high) |
| Review cadence | Backlog re-scored quarterly; coverage milestone tracked monthly |
Register (specimen)
| Element ID | Data element | System(s) | Criticality score | Exposure score | Priority score | Rank | Mapping status | Map owner | Last review date | Shared boundary controls reused | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
| DFM-001 | Batch disposition summary compilation | LIMS, ERP-QM, controlled spreadsheet | 5 | 3 | 15 | 1 | In progress | J. Marsh (QA) | n/a, target 15 Oct 2026 | None yet identified | Pulls from three systems into one memo before disposition; highest exposure in the estate |
| DFM-002 | Environmental monitoring viable count | Paper worksheet, LIMS micro module | 5 | 2 | 10 | 2 | Complete | A. Osei (Micro) | 25 June 2026 | Pre-numbered worksheet reconciliation control | Reused as the model for DFM-005’s paper-to-system step |
| DFM-003 | Cleaning verification swab result | Paper swab log, LIMS | 4 | 2 | 8 | 3 | Not started | <<FILL>> | n/a | Expected: worksheet reconciliation control from DFM-002 | Queued next after DFM-001 |
| DFM-004 | Stability pull scheduling and result entry | Controlled spreadsheet, LIMS | 3 | 2 | 6 | 4 | Not started | <<FILL>> | n/a | Expected: controlled-spreadsheet access control from DFM-006 | |
| DFM-005 | Finished-product release assay result | CDS, LIMS | 5 | 1 | 5 | 5 | Complete | R. Gomez (QC) | 12 August 2026 | Validated CDS-to-LIMS interface, no manual step | Lowest exposure among the High tier; single validated interface |
| DFM-006 | Bioreactor pH in-process reading | DCS, historian, MES | 4 | 1 | 4 | 6 | Periodic review due | T. Vance (Automation) | 03 March 2025 | Historian export-to-batch-record reconciliation control | Periodic review overdue; scheduled for the next quarter’s cycle |
Coverage summary (specimen)
| Criticality tier | Total candidates | Mapped (complete) | In progress | Not started | Periodic review due | % complete |
|---|---|---|---|---|---|---|
| High | 3 | 2 | 1 | 0 | 0 | 67% |
| Medium | 2 | 0 | 0 | 2 | 0 | 0% |
| Low | 1 | 0 | 0 | 0 | 1 (overdue) | 0% |
The specimen shows the register doing its real job in two places. DFM-001 outranks DFM-005 despite an identical criticality score, because the compiled disposition summary carries three manual touches against the release result’s single validated interface, exactly the tie-break the scoring exists to make explicit. And DFM-006’s periodic review is shown as overdue rather than silently dropped, so the coverage summary reports the true state of the estate instead of a number that only counts elements mapped at least once.
Common inspection findings this register prevents
- A mapping program that can name its method but cannot show which elements are mapped, which are in progress, and which have not started, because no single record tracks the backlog.
- A prioritization claim (“we map by risk”) with no scoring record behind it, so the sequencing looks arbitrary when an inspector asks why one element was mapped before another of similar criticality.
- A completed map’s periodic review quietly lapsing because nothing outside the map itself carried a due date.
- The same shared boundary (a spreadsheet, a shared drive, a manual export) rediscovered and re-assessed from scratch on every new map, because no register carried the control forward.
- A coverage claim that cannot be substantiated without manually reopening every individual map.
How to adapt this register
- Set the document number, owner, and approvers, and decide whether the controlled master lives in a spreadsheet or a validated tool.
- Seed the register from your system inventory and data criticality assessment so the first version reflects the whole candidate list, not just the elements someone already thought to map.
- Fix your scoring formula (multiplicative, as shown, or weighted) in the header and apply it uniformly; do not adjust it element by element to fit a preferred ranking.
- Wire the “shared boundary controls reused” column into your actual worksheet and SOP so a control established on one map is deliberately checked against every open candidate that shares the boundary.
- Set your coverage milestone and re-scoring cadence, and report the coverage summary on that cadence rather than only when asked.