Register packs, access levels and masks
The National Data Registers hold reference data about businesses, societies, vehicles, land parcels, people, permits and places. Some of it is public; much of it is about people. This lesson explains how a register says how sensitive each field is, who sees what, and how identifiers are protected.
Two controls: who may search, and what they see
Every register has two layers of control:
- Its search policy decides who may search the register at all.
- Its register pack decides, field by field, what each caller sees in a record.
Search policies
| Search policy | Who may search |
|---|---|
public | Anyone, signed in or not |
authenticated | Any signed-in person |
officer | Staff |
restricted | Only holders of an active access grant and the register's custodians |
The order is public < authenticated < officer < restricted. A register about people is restricted: for example, the person register mapped from the legacy national register is restricted and index-only.
Register packs
A register pack is a JSON file that types a register. Core packs live in zcm-backend/data/ndr/packs/:
| Pack | Typical register |
|---|---|
business-entity | Companies and business names |
society | Registered societies |
vehicle | Vehicles |
land-parcel | Land parcels |
person | People |
civil-event | Births, marriages, deaths |
authorisation | Permits, licences, certificates |
code-list | Reference lists |
geography | Provinces, districts, places |
Modules contribute their own packs through the registers.packs extension point (for example co-operatives, labour establishments and agreements, energy projects).
A pack declares:
policy.defaultandpolicy.minimum: the search policy a register bound to the pack gets, and the lowest it mayever have. Setting a lower one is refused with
409 PACK_POLICY.fields: every field of a record, each with a label and a sensitivity. A field the pack does not describe isnever returned.
searchFields: the only fields that can be searched.identifiers: which fields hold identifiers (NRC, TPIN, passport, entity number, plate) and whose they are.samples: synthetic sample records, which must validate.
Sensitivity levels
| Sensitivity | Meaning | Example fields |
|---|---|---|
public | Anyone may see it | A company's name and number, a vehicle's make |
internal | Staff who may read the register | A founder's name inside a company record |
personal | Staff of the custodian ministry and approved machine callers | A founder's NRC, a phone number |
sensitive | Nobody by default | Health or similar special data; only through a grant that names the field |
Pack versions follow semantic versioning. A minor version only adds; a major version may make old records invalid, so each record keeps the version it was validated against and a new version never rewrites old records.
Clearance: who sees which field
The caller's clearance for a register is worked out per request:
| Clearance | Who |
|---|---|
public | Anyone who is not staff: citizens and anonymous callers |
internal | Staff who may read the register |
personal | Staff of the register's ministry, administrators and Support, a partner client whose scope includes the register |
sensitive | Never by default |
The rule: a field is shown in full when its sensitivity is at or below the caller's clearance. When it is above:
- a caller with at least
internalclearance sees it masked; - a
publiccaller does not get the field at all: it is withheld.
Every answer lists the masked and withheld paths, so a consumer knows what it did not see.
Masks
| Mask | Result (synthetic) |
|---|---|
nrc | ******/**/0 |
phone | only the last 3 digits |
email | j***@example.com |
partial | first and last character |
hidden (default) | null |
Searching above your clearance
Searching by a field above your clearance is refused with 403 FIELD_NOT_SEARCHABLE. Otherwise a person without clearance could learn a value by guessing it and seeing whether a record comes back.
Grants and reveals
Access beyond the defaults is given through access grants. A grant names a principal (a user, a ministry, a role, a partner client), the register, an end date and, optionally:
fieldScope: the only fields the grantee may see (field minimisation);revealColumns: personal fields the grantee may see in full.
Grants are issued by data-sharing agreements (lesson 3) or by custodians for their own ministry's needs, and are reviewed periodically.
A member of staff who needs one record's masked field in full uses a reveal: they give the record, the fields and a reason, and the reveal is audited.
The party index: linking without exposing
Identifiers in records feed a party index, which answers questions such as "which registers mention this company number?". The index never stores the identifier itself: it stores a keyed hash (HMAC-SHA256) of the normalised value.
- An NRC is normalised to the form
######/##/#, a TPIN to 10 digits, a plate to upper case without spaces. - A value that does not normalise is counted as malformed and never indexed.
- Party-link lookups show only registers the caller may read, and are audited with a hash of the value searched.
Example: one company record, three callers
A synthetic business-entity record has a public name and number, internal founder names, and personal founder NRCs.
| Caller | Name and number | Founder names | Founder NRCs |
|---|---|---|---|
| A citizen | Shown | Withheld | Withheld |
| An officer of another ministry | Shown | Shown | Masked: ******/**/0 |
| A custodian officer | Shown | Shown | Shown |
| A partner whose agreement covers only name and number | Shown | Not returned | Not returned |
Open data and small numbers
Some register data can be published as open data, decided by the DPO on a custodian's proposal. Rows are published only for registers that anyone may search and whose every field is public. Otherwise only counts are published, by public, non-identifying fields, with small-cell suppression: a cell below 10 is hidden, together with enough other cells that it cannot be worked out from totals. Rows of registers about people are never published.
Check your understanding
- What is the difference between a register's search policy and its pack's field sensitivities?
- A public caller asks for a record with a personal field. What do they receive for that field?
- Why is searching by a field above your clearance refused?
- What does the party index store instead of an NRC?
- Under which condition may register rows be published as open data?
Sign in to record your progress.
Previous: The Data Protection Act on the platform Next: Data-sharing agreements