IT and information governance pack

Draft documents for your own DPIA and supplier checks.

Draft, 31 October 2026

The council is the controller and makes its own assessment. Plans are written as plans. Back to For IT and information governance.

Data protection impact assessment

Draft, 30 October 2026.

Version draft-2026-10-30. What changed

This is a draft for a council to adapt. The council is the controller for its licensing scheme and makes its own assessment.

The supplier is a processor and acts on the council's written instructions. Nothing here is legal advice.

The headings follow the ICO's guidance on DPIAs: Data protection impact assessments (DPIAs).

Step 1: The need for a DPIA

The council runs a property licensing scheme (HMO, additional or selective) and uses the product to take applications, decide them and publish the register. The software holds personal data about landlords, agents, managers, other people with an interest in a property, and tenants and occupiers named in the council's notes and letters.

Many councils choose to carry out a DPIA for a new system that holds this data. The council decides whether one is required.

Step 2: Describe the processing

Nature

Applicants create an account, apply for a licence, upload documents and pay fees.
Officers check applications, record notes, photos and visits, issue letters and decide.
The public register shows licences in force.
Team leaders export CSV files for the council's own systems, and download the full export: one zip file with every record, the audit log and every uploaded file.
Team leaders search for a person and download a subject access bundle: one zip file with the records they tick from those found, and the files on those cases. The search reads names, email addresses and postal addresses, and the text of notes, visit notes, representations, replies, letters and target notes. Each search and bundle is in the audit log with the search as typed and the records included.

The record of data held in this pack lists every field.

Scope

People: applicants (landlords and agents), proposed licence holders, managers, people in control, interested persons, relevant persons (owners, freeholders, mortgage lenders, leaseholders), officers, and tenants, occupiers, neighbours and other third parties named in free text (notes, visit notes, representations, replies, letters and target notes).
Data: names, postal addresses, email addresses, phone numbers, fit and proper declarations, property details, documents, case notes and photos.
Special category data is not asked for. Fit and proper declarations may include information about criminal convictions; the council decides how it handles this.
Volume: one scheme, usually hundreds to a few thousand properties.

Context

Licence holders and managers expect the council to hold this data, because the scheme requires a licence. Some interested persons (for example, a mortgage lender or freeholder) are named by the applicant and may not know. The application form tells the applicant that the council will contact each person named. A scheme cannot open for applications until the council gives its own privacy notice address. Every page of the application links that notice, and so does the foot of every page of the product.

Purposes

To run the licensing scheme under Parts 2 and 3 of the Housing Act 2004, and to keep the public register that section 232 of that Act requires.

Step 3: Consultation process

The council decides whom to consult. Suggested: its data protection officer, its IT security lead, the licensing team, and, where it sees fit, landlord representatives. The supplier will answer questions and take part in this step on request.

Step 4: Necessity and proportionality

Lawful basis: the council sets this. Public task is the basis most councils name for licensing.
Data minimisation: the forms ask for the fields in the prescribed application particulars and no more. Card details are not held; applicants pay on the council's own payment page.
Accuracy: applicants see and correct their own details until they submit; changes after grant go through a variation.
Retention: the council sets two periods for each scheme in the product, in years after a licence ends and after an application is refused or withdrawn. A team leader removes the personal details of records past them. The record of data held proposes a period for the other items.
Rights: the council handles requests. A team leader finds the records about a person by name, email address or postal address, or where notes and letters mention them, ticks the records that are about that person, and downloads them as a subject access bundle.
Processors: the supplier, and the sub-processors in the security overview, section "Sub-processors".

Step 5: Identify and assess risks

Risk	Likelihood	Severity
An applicant sees another applicant's case	Remote	Significant
Another council's staff see this council's records	Remote	Significant
The register shows a phone number or email address	Remote	Significant
The whole register is copied in bulk, profiling named people and their addresses	Possible	Significant
A photo taken on a visit shows a tenant's face or belongings	Possible	Minimal to significant
A note, representation, reply or letter names a tenant, occupier or other third party, who is then left out of a subject access search or released in another person's bundle	Probable	Significant
An exported CSV file, full export or subject access bundle is left on a shared drive	Possible	Significant
An officer account is used by someone else	Possible	Significant
Data is lost through a failure at the host	Remote	Severe
Data is kept longer than needed	Probable	Minimal
Data is processed outside the UK, in Ireland, the United States, Singapore and Hungary, without a transfer mechanism UK law allows	Possible	Significant

The likelihood and severity scores are suggestions. The council scores them for its own scheme.

Step 6: Measures to reduce risk

Risk	Measure	Status
Applicant sees another case	Each applicant account sees only its own applications; tests check this	In the product
Another council sees this council's records	Every record belongs to one council; the server reads and writes only the signed-in person's council's records; tests check this with a second, made-up council	In the product
Register shows contact details	The register shows a fixed list of fields and withholds phone and email; tests check this	In the product
Register copied in bulk	The register's CSV download is off for a new scheme; the council switches it on only if it chooses. A search must be a full postcode, a street name of at least 4 letters, or a licence reference. One address can make up to 30 searches a minute; after that the register answers "Too many searches". Each server counts its own searches, so with more than one server the limit applies on each. Tests check this	In the product
Photos show tenants	Officer guidance to photograph the property, not people; photos stay inside the case	Council guidance needed
Third parties named in free text	The person search reads the text of notes, visit notes, representations, replies, letters and target notes, and says where each name was found; the team leader ticks the records that go into a bundle; the audit log lists the records included; tests check this. Officer guidance to name third parties only where needed, and to review each bundle before release	In the product. Council guidance needed
Exports left on a drive	CSV files, the full export zip and subject access bundles are made only by signed-in team leaders; each download is in the audit log; the council's own file rules apply	Council process
Account misuse	Access by role; every action is in the case history; sign-ins, CSV exports, full exports, imports, set-up changes, case views, file views, person searches and subject access bundles are in the audit log	In the product. Officers will sign in with the council's own accounts, with multi-factor authentication enforced by the council's provider; a team leader turns a leaver's sign-in off, ending their sessions at once. No council has set up its accounts yet
Loss at the host	Daily backups with a tested restore	Planned
International transfer	Each sub-processor's own terms name a transfer mechanism for data from the UK; Ireland is covered by UK adequacy; the security overview, section "Sub-processors", names each country and mechanism; the supplier tells the council before adding or replacing a sub-processor	Planned. Items marked "to be confirmed" there are checked before contract
Over-retention	Retention periods set per scheme; a team leader removes the personal details and files of records past them, keeping an anonymised row; each removal is in the audit log; tests check this	In the product

Step 7: Sign off and outcomes

Item	Name and date	Notes
Measures approved by
Residual risks approved by
DPO advice provided
Summary of DPO advice
DPO advice accepted or overruled by
This DPIA will be kept under review by

Record of data held

Draft, 30 October 2026.

Version draft-2026-10-30. What changed

Every item the product stores, from its data model. "Who sees it" names roles in the product: the officer (any officer in the council's team, team leaders included), the applicant (the account that made the application), and the public (the register).

Applications, licences and the records on them follow each scheme's retention periods, which a team leader sets in the product in line with the council's retention schedule: by default 6 years after a licence ends, and 2 years after an application is refused or withdrawn. Past its period, a team leader removes a record's personal details and uploaded files on confirmation, and an anonymised row stays (see the section "Anonymised records"). The other periods below are proposals; the council sets its own.

Applicant accounts

Field	Who sees it	Why	Proposed retention
Kind (landlord or agent), name, organisation	Applicant, officer	To know who applied	Until every application and licence on the account has passed its retention period, then removed
Email address, phone number	Applicant, officer	To contact the applicant about the case	As above
Postal address	Applicant, officer	Correspondence and the application form	As above

Properties

Field	Who sees it	Why	Proposed retention
Address and UPRN	Applicant, officer, public (when licensed)	To identify the property and check it is in the area	The scheme's period after the last case or licence on it, then cut to the postcode district
Description, type, age, storeys, rooms, amenities, occupants, households, gas supply	Applicant, officer	Prescribed particulars; to set conditions	As above
HMO particulars (sleeping rooms, flats, shared amenities, section 257)	Applicant, officer	Prescribed particulars for an HMO	As above
Address check result and reason	Officer	To confirm the property is in the designated area	As above

Applications

Field	Who sees it	Why	Proposed retention
Proposed licence holder, manager, person in control: name, address, email, phone	Applicant, officer	Prescribed particulars	The scheme's period: after the licence ends if granted, or after a refusal or withdrawal
Interested persons: name and address	Applicant, officer	They must be served with notices	As above
Relevant persons (owner, freeholder, mortgage lender, leaseholder): name, address for service, email if given	Applicant, officer	They must be served with notices	As above
Service record on each notice and licence: each person served, the method chosen and the address used	Officer	To evidence service	As above
Fit and proper declaration and details	Applicant, officer	Part of the fit and proper test	As above
Other licences held	Applicant, officer	Part of the fit and proper test	As above
Declaration (signed by, signed on, signed by the holder, renewal signed by)	Applicant, officer	Record of the applicant's declaration	As above
Stage, dates, assigned officer, proposed decision, refusal reasons, decided by	Applicant (stage and dates), officer	To run and evidence the decision	As above
Draft conditions	Applicant, officer	Statutory consultation on the draft licence	As above
Representations (from, received, summary, response, logged by)	Officer	Statutory consultation on the draft licence	As above
Claimed discounts	Applicant, officer	To work out the fee	As above

Certificates and files

Field	Who sees it	Why	Proposed retention
Certificate kind, issue date, expiry date	Applicant, officer	Gas, electrical, fire safety and other evidence	As the case, then removed
Uploaded file (name, type, size, content)	Applicant, officer	The evidence itself	As above; the file is deleted

Payments

Field	Who sees it	Why	Proposed retention
Part (A or B), amount, status, requested on, paid on	Applicant, officer	To show which fee is paid	6 years after the financial year, or as the council's finance rules set

No card details are held. In the product today, fee payments are simulated.

Licences and variations

Field	Who sees it	Why	Proposed retention
Holder and manager: name and address	Applicant, officer, public	The register requires them	The scheme's period after the licence ends (by default 6 years)
Holder and manager: email and phone	Applicant, officer	Contact	As above
Conditions, granted, start and end dates, status, revocation date	Applicant, officer, public	The licence itself and the register	As above
Proposed revocation and revocation (reason, dates, whether the holder agreed, who proposed and recorded it)	Applicant, officer	To record the council's decision to revoke	As above
Tribunal matters (reference, dates, summaries)	Officer	To record appeals	As above
Variations (kind, new holder or manager, conditions, dates, reason, who proposed and made it)	Applicant, officer	To record changes after grant	As above

Case records

Field	Who sees it	Why	Proposed retention
Letters and notices issued (title, body, date, issued by)	Applicant, officer	The record of what was served	As the case
Notes and photos (author, time, text, up to 4 photos)	Officer	Evidence from checks and visits	As the case
Visits (officer, date, time)	Officer	Planning inspections	As the case
Case history (who did what, when, stage moves)	Officer	The record of the case	As the case
Audit log (person, action, record or scheme, time, IP address, browser, and the action's details). A person search or subject access bundle keeps the search as typed. That can be a name, email address or postal address. A person search's "matches" is the number of records found. A bundle keeps how many records and files it holds, the references of the records included and how many found were left out. A refused council sign-in keeps the tenant and account id of the council account that was refused. A refused access keeps the page or download asked for	Team leader, auditor	To show who did and saw what	2 years unless the council sets another period on the retention screen; then removed on a team leader's confirmation, leaving one event that records the removal. Erasing a record's personal details leaves the audit log as it is, search terms included

Anonymised records

What stays of a case or licence once its personal details are removed under the scheme's retention period.

Field	Who sees it	Why	Proposed retention
Reference, scheme, licence type, stage, dates, fee amounts, postcode district, HMO particulars, conditions, who removed it and when	Team leader	Statistics on the scheme	Life of the scheme

Council and officers

Field	Who sees it	Why	Proposed retention
Officer name, email, role, and the ids of the council account they first signed in with (tenant and account id)	Officers see the name, email and role. The ids are in the full export a team leader downloads	Sign-in and access by role	While the officer has access, then 1 year. The ids go when a team leader turns the officer's sign-in back on
Council name	Officers, applicants, public	To show whose scheme it is	Life of the contract
Scheme set-up: name, type, designation dates, area addresses, fee schedule, conditions, letter templates, payment page link	Officer; public (scheme name and area)	To run the scheme	Life of the scheme, then 6 years
Area import report (rows accepted, rows rejected with their text and reason)	Officer	To check the designated area was loaded correctly	Life of the scheme
Target list (UPRNs, imported on, imported by)	Officer	To find properties that should be licensed	Life of the scheme

Website buyers and enquiries

These are held by the supplier for its own business, not for the council's scheme. Once set up, each stored enquiry or order is also sent by email (through Resend) to the supplier's own inbox.

Field	Who sees it	Why	Proposed retention
Enquiries from the contact form: request type, name, email, council, scheme, start date, current system, message, page sent from, time stored	The supplier	To reply	2 years
Buyer accounts: name, email, council, created at	The buyer, the supplier	To sign in and manage orders	While active, then 6 years
Sign-in links: email, purpose, name and council (for sign-up), applicant account and council (for an applicant), page to open next, created, expires, used	The supplier	To sign in	Single use; each link expires after 30 minutes. An expired link, used or not, is deleted when the next buyer or applicant asks for a link
Sessions: account, created, expires	The supplier	To keep the buyer signed in	30 days, or until sign-out. An expired session is deleted when its cookie is next sent, or when the next buyer session starts
Product sessions: officer or applicant account, council, how they signed in, created, last request, a one-time notice after a team leader changes an officer's sign-in	The supplier	To keep a person signed in	Until sign-out, 30 minutes without use or 12 hours after sign-in. An ended session is deleted when its cookie is next sent, or when the next session of its kind starts: the next council or emailed-link sign-in for a live session, the next demo sign-in for a demo session
Council sign-in requests: council, state, nonce, PKCE verifier	The supplier	To finish a council sign-in	Deleted when used. An unused request ends after 10 minutes and is deleted when the next council sign-in starts
Orders: plan, account, council, scheme, start date, name, email, notes, payment method, purchase order number, status, price before VAT, VAT, total, version of the agreements read, created at	The buyer, the supplier	To supply and invoice	6 years

Sign-in links and session ids are stored only as SHA-256 hashes.

Cookies

Four cookies, each httpOnly, and Secure on the live site. The cookies page lists them.

lp_session: keeps a buyer signed in, for up to 30 days.
lp_demo: keeps each visitor's copy of the demo data apart, for the browser session.
lp_app_session: a random id for the session in the product or the demo. The session ends after 30 minutes without use, or 12 hours after sign-in.
lp_sign_in_state: ties a council sign-in to the browser that started it, for 10 minutes.

Data flow

Draft, 30 October 2026.

Version draft-2026-10-30. What changed

How personal data moves through the product. All traffic between a browser and the product uses HTTPS.

1. Applicant

The applicant signs in by a link emailed to the address on their account. Links will be emailed once email sending is switched on; the demo signs in as a fictional user.
They enter the property, the people involved and the fit and proper declaration, and upload certificates.
They pay the fee on the council's own payment page, which the scheme links to. The product records only whether each part is paid; in the demo, payment is simulated.
They see their own applications and licences, and the letters served on them.

2. Officer

The officer signs in with the council's own account (once the council has set this up) and sees the case list. Every officer sees the cases of every scheme the council runs, and no other council's.
They check the application, request information, add notes, photos and visits, and issue the draft licence.
They log representations, record the decision and issue the licence.
Every step is written to the case history with who did it and when.

3. Public register

A granted licence appears on the public register from its start date.
The register shows the licence holder's and manager's names and addresses, the property address, the licence dates and conditions.
It does not show phone numbers or email addresses.
When a licence ends, or a revocation takes effect, it leaves the register. A proposed revocation leaves the licence on the register.
The register can also be offered as a CSV file of every entry. This is off for a new scheme until the council switches it on in the scheme's set-up.

4. Exports

A signed-in team leader downloads CSV files of licences granted, cases received, or licences and cases changed, for the dates they choose. A change is a licence granted, varied, revoked or expired, or a case refused or withdrawn. The council's back-office system is expected to load the changed records once a day, for the day before.
The register's CSV download is the council's choice for each scheme. It is off for a new scheme; once the council switches it on, anyone can download that scheme's register.
The case and licence files are shaped for import into the council's own systems, such as Uniform or APP. The council's systems team maps the columns once.
A team leader can download the full export: one zip file with every record of the council as JSON, the audit log and every uploaded file. It also holds schema.json and fields.csv, which describe every table and field (the full export format document in this pack).
A team leader can search for a person by name, email address or postal address, or by where the text of notes, visit notes, representations, replies, letters and target notes mentions them, tick the records that go in, and download a subject access bundle: one zip file with those records, as JSON and as a page to read, and the files on those cases.
Each case or licence CSV file a team leader downloads, each full export, each person search and each subject access bundle is written to the audit log with who did it and when. A person search or bundle also keeps the search as typed.
Once downloaded, the file is under the council's own controls.

5. Outside the product

Email: sign-in links and notices are planned to go through Resend. Today the product queues notices to applicants and sends none.
Payments: applicants pay licence fees on the council's own payment page; card details never reach the product.
Hosting: the application runs on Vercel, in Dublin, Ireland (Vercel region dub1). Its database and files will be held with Supabase, in EU (Ireland).
Outside the UK: data is processed in Ireland, the United States, Singapore and Hungary. Vercel processes data in Ireland (the application's server code, in Vercel's dub1 region in Dublin) and the United States (Vercel's primary processing facilities). Transfer mechanism: the ICO's UK transfer terms, which Vercel's data processing addendum says are deemed entered into for transfers from the UK; it calls them the UK IDTA and sets them out as the addendum to the EU standard contractual clauses, so which of the two ICO documents applies is to be confirmed. Still to be confirmed: the countries of Vercel's own sub-processors, which its published list did not show when read. Supabase processes data in Ireland (the database and files, stored and primarily processed in the region chosen), Singapore (Supabase Pte. Ltd., the contracting company, and support), the United States (support, hosting and monitoring sub-processors) and Hungary (a feature flag sub-processor). Transfer mechanism: the UK Addendum to the EU standard contractual clauses, which Supabase's data processing agreement makes part of it. Resend processes data in the United States (account data, email metadata and logs, and Resend's sub-processors). Transfer mechanism: the UK Addendum to the EU standard contractual clauses, under Resend's data processing addendum, which also says Resend complies with the UK Extension to the EU-US Data Privacy Framework. Still to be confirmed: the sending region, which is chosen when the sending domain is added (Ireland is one of the choices). For plan orders, Stripe processes data in the United States (Stripe, LLC). Transfer mechanism: the UK-US Data Privacy Framework, which its data transfers addendum says its US company takes part in, or, failing that, the UK International Data Transfer Addendum in the same addendum. Still to be confirmed: the countries of its affiliates and sub-processors outside the United States.

The security overview, section "Sub-processors", lists each company involved.

Security overview

Draft, 31 October 2026.

Version draft-2026-10-31. What changed

What is built, and what is planned. Plans are written as plans. The product is in development and is not yet offered for live data.

Hosting

The application runs on Vercel. Its server code runs in Dublin, Ireland (Vercel region dub1), next to the database, as set in the product's Vercel configuration.
Live data will be held in EU (Ireland): the PostgreSQL database and uploaded files, with Supabase.
The product has its own database schema and its own file bucket. No other product reads them.
The preview site holds demo data only, in memory.

Sub-processors

Each sub-processor below will be confirmed, with its data processing terms, before contract.

For the supplier's own business

These handle the website's enquiries, buyer accounts and plan orders. They hold no council scheme data. The record of data held, section "Website buyers and enquiries", lists what they hold.

Vercel hosts the website, including its contact form and buy pages.
Supabase will store enquiries, buyer accounts and plan orders in EU (Ireland), once the website's database is connected. Until then the preview keeps them in memory.
Stripe takes card payment for plan orders made on the website, once the supplier's Stripe account is connected. For card plan orders, Stripe holds the card details and the supplier keeps only the order and its status. Until then a card order is stored and no payment is taken.
Resend will send buyers their sign-in links, and send the supplier a copy of each enquiry and order, once it is switched on.

Planned for council scheme data

None is in use yet, because the product holds demo data only. The supplier plans to use these from the first council. The draft data processing agreement names each one.

Vercel: runs the application.
Supabase: the PostgreSQL database and uploaded files, in EU (Ireland).
Resend: sign-in links and notices to applicants and officers.

Where they process data

Countries outside the UK, and the transfer mechanism each provider's own terms name for data from the UK. Ireland and Hungary are EEA states, which UK law treats as adequate (Data Protection Act 2018, Schedule 21, paragraphs 4 and 5). Each line links to the provider's own documents, read on 28 October 2026. Anything they do not state is marked "to be confirmed".

Vercel processes data in Ireland (the application's server code, in Vercel's dub1 region in Dublin) and the United States (Vercel's primary processing facilities). Transfer mechanism: the ICO's UK transfer terms, which Vercel's data processing addendum says are deemed entered into for transfers from the UK; it calls them the UK IDTA and sets them out as the addendum to the EU standard contractual clauses, so which of the two ICO documents applies is to be confirmed. Still to be confirmed: the countries of Vercel's own sub-processors, which its published list did not show when read. Sources: data processing addendum, region list, function regions.
Supabase processes data in Ireland (the database and files, stored and primarily processed in the region chosen), Singapore (Supabase Pte. Ltd., the contracting company, and support), the United States (support, hosting and monitoring sub-processors) and Hungary (a feature flag sub-processor). Transfer mechanism: the UK Addendum to the EU standard contractual clauses, which Supabase's data processing agreement makes part of it. Sources: data processing agreement, sub-processor list, regions.
Resend processes data in the United States (account data, email metadata and logs, and Resend's sub-processors). Transfer mechanism: the UK Addendum to the EU standard contractual clauses, under Resend's data processing addendum, which also says Resend complies with the UK Extension to the EU-US Data Privacy Framework. Still to be confirmed: the sending region, which is chosen when the sending domain is added (Ireland is one of the choices). Sources: data processing addendum, sub-processors, sending regions.
For plan orders, Stripe processes data in the United States (Stripe, LLC). Transfer mechanism: the UK-US Data Privacy Framework, which its data transfers addendum says its US company takes part in, or, failing that, the UK International Data Transfer Addendum in the same addendum. Still to be confirmed: the countries of its affiliates and sub-processors outside the United States. Sources: data processing agreement, data transfers addendum, service providers.

Licence fees are not taken by the product. Applicants pay on the council's own payment page.

Encryption

In transit: HTTPS for every page and request.
At rest: Supabase encrypts the database and file storage.

Backups

Daily database backups are planned from the first council, on a paid Supabase plan, held in EU (Ireland).
Uploaded files are not part of the database backup. A nightly copy of the file bucket to a second bucket in EU (Ireland) is planned from the first council.
A restore of the database and of the files will be tested before the first council goes live, and every 6 months after.

Continuity

These are proposed figures. They apply from the first council going live, and the product agreement states the same ones.

Availability target: 99.5% of each calendar month, not counting planned maintenance.
Recovery point: 24 hours. After a failure, at most the last 24 hours of changes could be lost.
Recovery time: 8 hours. The service is planned to be back within 8 hours of a failure being found.
Database backup: every 24 hours, kept for 7 days.
File backup: every 24 hours, kept for 7 days.

Uploaded files

Applicants upload certificates as PDF, JPEG or PNG files. Officers add visit photos as JPEG, PNG or WebP pictures. Team leaders import CSV files.
Each upload is checked by its contents, not only its name or declared type. The first bytes must match the type: a file named as a PDF that holds a web page is refused. A CSV import must read as text. Tests check this.
Photos and image certificates have their metadata removed before they are kept: camera details, dates, comments and the GPS position. The picture itself is unchanged. Tests check this on the stored file.
HEIC and HEIF photos are not taken. A phone camera on the visit page gives a JPEG instead.
Each file is 4 MB or smaller, and the visit photos on one note are 4 MB or smaller in total.
Malware scanning of uploads is planned before the first council goes live. The storage layer already runs a scanning step before every file is saved, and a file it refuses is not kept. Until a scanner is connected, that step accepts every file.

Access by role

Five roles: team leader, officer, auditor, applicant, and the public.
A team leader sets up schemes (including whether the register offers a CSV download and where the council's privacy notice and accessibility statement are), assigns cases to officers and switches on automatic allocation, serves notices of proposed grant and grants licences on many cases at once from the case list, imports licences, target lists and payment confirmations, exports cases and licences as CSV files and every record as one zip file, produces a scheme's renewal reminder letters, reads the audit log, sets each scheme's retention periods and removes the personal details of records past them, sets the audit log's retention period and removes events past it, and finds the records about a person for a subject access request. A team leader can also do everything an officer can.
An officer works cases, takes a case that is not assigned to anyone, records a fee paid on the council's payment page, plans and records inspection visits, searches the public register, follows each scheme's dashboard, works a scheme's target list and downloads it as a CSV file, sees the licences due for renewal and reads the notifications queued for applicants.
An auditor, for example from internal audit or information governance, reads the audit log and downloads it as a CSV file, and nothing else: every other page and download in the product answers "Page not found". An auditor holds no cases. Tests check this.
Every officer sees the cases of every scheme their own council runs. Each action is checked on the server against one permissions table, not only hidden in the menus. Tests check this.
Each council's records are kept apart. Every officer, applicant account, case, licence, uploaded file, history line and audit event names its council. Every read and write on the server goes through one council's view of the database, so another council's case, licence, file, export or import reads as not found and cannot be changed. Tests check this with a second, made-up council, on the in-memory store and on PostgreSQL.
In the PostgreSQL version, the database checks this too. Row-level security on each table that names its council lets the application's role read and write only the rows of the council a request names. Records that hang off a case, scheme or licence (certificates, payments, letters, notes, visits and the like) have no council column, and rely on the application's check alone. Row-level security applies when a request names a council. With no council named, as for sign-in and the website's buyer records, every row is open. The application's role can name a council itself, so row-level security guards against a slip in the application's own council check, not against someone who has taken over the application's database connection. Tests check that a request for one council reads none of another council's cases.
An applicant sees only their own applications, licences and letters. Tests check this.
The public sees only the register, which withholds phone numbers and email addresses. Tests check this.
A team leader can turn an officer's sign-in off on the Team page, for example when they leave. Their sessions end at once, and they cannot sign in until it is turned back on. Tests check this.
A team leader adds officers by name, work email and role, changes roles and removes officers on the Team page. A removed officer's sign-in is off and their sessions end; their record is kept so the case history and audit log still name them. A council can have more than one team leader, and the last team leader whose sign-in is on cannot be removed, turned off or given another role. Tests check this.

Sign-in and sessions

Officers will sign in with the council's own accounts through OpenID Connect: Microsoft Entra ID first, or another provider that supports the authorisation code flow with PKCE and signs ID tokens with RS256. It is used only once a council's provider is set up; no council has set this up yet.
Multi-factor authentication is enforced by the council's provider, under the council's own policies. The product holds no officer passwords.
The product checks each ID token's signature against the provider's published keys, and its issuer, audience, expiry and nonce. The person must be an officer of the council whose provider issued the token. Tests check each refusal against a local test provider, including a token from another council's tenant.
The first sign-in links the officer to the provider's ids for that account: the tenant and the account's object id (or subject id). A later token with the officer's email address but another account is refused and written to the audit log.
At the first sign-in, the product finds the officer by the address in the token. For Microsoft Entra ID that is the account's sign-in name (`preferred_username`, or `upn`). Entra's `email` claim is used only when Entra says it checked the domain (`xms_edov`). A guest account in the council's tenant is refused unless the council allows guests. A guest is known by the `acct` claim, by `#EXT#` in the sign-in name, or by an `idp` claim that names another tenant or provider. Each of these refusals is written to the audit log as "Refused a sign-in".
Every Microsoft Entra ID host counts as Entra, in the public, US Government and China clouds. The issuer's host must match one of them exactly.
Each council lists the email domains its officers' work addresses may be at. Adding an officer, or changing an officer's address, outside them is refused. Tests check this on every store and on the Team page.
Sign-in links, the council sign-in's return address and payment return pages use the product's configured web address, or a preview build's own address, whatever host the request names.
Applicants sign in by an emailed link. It works once, for 30 minutes, and only its SHA-256 hash is stored. Links will be emailed once email sending is switched on.
A session is a random id in a cookie marked Secure, HttpOnly and SameSite=Lax; only its SHA-256 hash is stored. It ends after 30 minutes without use, or 12 hours after sign-in, whichever comes first. Signing out deletes it on the server.
The demo signs in as a made-up person picked from a list. That session opens only the visitor's own copy of the made-up data. A cookie set by hand gives no access. Tests check this.
Supplier staff access to council data will be limited to named people, for support, and logged.

Setting up officer sign-in

Council IT registers the product as an application in the council's Microsoft Entra ID tenant.

Add the product's sign-in return address as a web redirect URI. It ends in `/app/sign-in/council/callback`.
Under "Token configuration", add two optional claims to the ID token: `acct` (the account type) and `xms_edov` (whether Entra checked the email's domain). Entra does not send either one unless asked.
Give the product the tenant's issuer and the application (client) id.

Without `acct`, a guest is still known by `#EXT#` in the sign-in name or by the `idp` claim. Without `xms_edov`, the `email` claim is never used, so officers are found by their sign-in name alone.

Audit log

The product keeps an audit log of who did and saw what. Each event records the person, the action, the case, file or scheme, the time, and the request's IP address and browser where the request gives them.
The IP address is the one the hosting platform records, not one the browser sends. The product reads `x-vercel-forwarded-for` (set by Vercel, which overwrites any value the browser sent), then `x-real-ip`, then the last address in `x-forwarded-for` (the one the platform's proxy added). Earlier addresses in `x-forwarded-for` come from the browser and are not used. The register search limit counts searches against the same address. Tests check this with a sent `x-forwarded-for`.
Events are written for sign-in, sign-out, each CSV export (with its layout, filters and row count), each confirmed import, each change to a scheme's set-up, each time an officer views a case, each time a stored file is opened, each full export, each person search and subject access bundle, each record whose personal details are removed under its retention period, each time a team leader turns an officer's sign-in off or on, and each time a team leader adds or removes an officer, changes a role, sets away dates or reassigns an officer's open cases.
A signed-in officer or auditor whose role may not open a page, download or action is answered "Page not found", and a "Refused access" event records the person, the page or download asked for, the time and the IP address. Tests check this.
The log is append-only, apart from its retention period. The storage layer adds and reads events, has no way to change one, and removes events only when they are past the council's audit retention period. In the PostgreSQL version, the table refuses every update, and every delete except the one the retention removal makes. Tests check both. The table's trigger guards against a mistake in the application's code, not against someone with direct access to the database.
Each event holds a hash (SHA-256) of the council's event before it, so the events form a chain. "Check the audit log" on the audit page works out every hash again and names the first event that does not match. A changed event, or one taken out of the middle, shows there, even when the change was made directly in the database. The full export carries the newest hash. Tests check this on PostgreSQL, with an event changed by the database's superuser.
What the chain does not cover. Someone with direct access to the database could change an event and write every later hash again. Events taken off the newest end show only against a newest hash kept somewhere else, such as an earlier full export. Events taken off the oldest end are what the retention removal does, so the check does not flag them. Events written before the chain began have no hash, and the check counts them apart. If the database owner cleared the hashes on the oldest events, those events would look the same as events written before the chain began.
In the PostgreSQL version, the application connects as its own database role, not as the database owner. That role cannot switch off the audit log's trigger, change a table or turn off row-level security. Tests check this. The database owner still can, and the supplier holds its password.
Team leaders read the log on an audit page, filtered by person, record and action, and can download it as a CSV file. The download is itself written to the log. Officers cannot open the page. Tests check this.
The log is kept per council for the council's audit retention period: 2 years unless a team leader sets another, in whole years. The retention screen lists the events past it. On a team leader's confirmation they are removed, newer events stay, and one event records how many were removed, the first and last, and who removed them. Tests check this.

Case history

Every change to a case is also written to its history: who, what, and when.
The product adds history lines and has no screen to edit them. A case's history is removed only with its other personal details, once the case passes its retention period and a team leader confirms.
Officers see the history on each case.

Development

Code is kept in version control. Every change runs type checks, unit tests and browser tests before it is committed.
Dependency versions are locked in a lockfile.
An independent penetration test is planned before the first council goes live. None has been done yet.

Incidents

The supplier will tell the council without undue delay, and within 24 hours, of a personal data breach that affects its data, so the council can meet its own duty to report.
A written incident response plan will be in place before the first council goes live.

Product accessibility statement

Draft, 31 October 2026.

Version draft-2026-10-31. What changed

This statement covers the product at /app (applicant and officer screens) and the public register. It follows the GOV.UK model accessibility statement. The website has its own statement.

Using the product

You should be able to:

change colours, contrast levels and fonts in your browser
zoom in up to 400% without the text spilling off the screen
use the product with just a keyboard
use most of it with a screen reader

How accessible the product is

Some parts may not be fully accessible:

it has had automated accessibility tests only, with no independent audit
it has not been tested with screen readers or speech recognition software
uploaded documents, such as certificates, are the applicant's own files and may not be accessible
letters are produced as web pages to print and as PDF files; the PDF files are not tagged for screen readers, and the printed form has not been tested

Feedback and contact information

For this information in another format, or to report a problem, use the form on the website's contact page and say the message is about accessibility. Give the page and what went wrong.

The supplier replies within 5 working days. The council running the scheme will also have its own contact route.

Enforcement procedure

The Equality and Human Rights Commission (EHRC) enforces the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. If you are not happy with the response to a complaint, contact the Equality Advisory and Support Service (EASS).

Technical information about the product's accessibility

The council running the scheme is a public sector body, so the regulations apply to the service it offers through the product. The supplier builds the product to help the council meet them.

Compliance status

The product is partially compliant with the Web Content Accessibility Guidelines version 2.2 AA standard, because it has not been fully tested against it.

Non-accessible content

Not yet fully tested

Automated checks against WCAG 2.2 A and AA run on every applicant and officer screen, at desktop and phone widths, in every test run. The application and the grant of a licence are also run with the keyboard alone. These checks find only some kinds of problem, so there may be others.

Content outside the supplier's control

Documents uploaded by applicants, and text that officers write into letters and conditions.

What is planned

An independent accessibility audit before the first council goes live.
Testing with screen readers and speech recognition software.
An update to this statement after each audit.

Preparation of this accessibility statement

This statement was prepared on 21 October 2026 and last reviewed on 31 October 2026. It is based on automated tests and keyboard-only runs by the supplier.

Supplier questionnaire: draft answers

Draft, 31 October 2026.

Version draft-2026-10-31. What changed

Draft answers to questions councils often ask before buying software. Where something is planned, it says so.

Company and certification

Question	Answer
What certifications does the supplier hold?	None held yet.
Is the product on a public sector framework?	No.
Which councils use the product?	None yet. The product is in development.
Has the product been independently assessed?	No.

Hosting and data location

Question	Answer
Where is data hosted?	Live data will be held in EU (Ireland), with Supabase for the database and files. The application runs on Vercel, in Dublin, Ireland (Vercel region dub1).
Is any data stored or processed outside the UK?	Yes, in Ireland, the United States, Singapore and Hungary. Live data will be held in EU (Ireland). The preview holds demo data only. Vercel processes data in Ireland (the application's server code, in Vercel's dub1 region in Dublin) and the United States (Vercel's primary processing facilities). Transfer mechanism: the ICO's UK transfer terms, which Vercel's data processing addendum says are deemed entered into for transfers from the UK; it calls them the UK IDTA and sets them out as the addendum to the EU standard contractual clauses, so which of the two ICO documents applies is to be confirmed. Still to be confirmed: the countries of Vercel's own sub-processors, which its published list did not show when read. Supabase processes data in Ireland (the database and files, stored and primarily processed in the region chosen), Singapore (Supabase Pte. Ltd., the contracting company, and support), the United States (support, hosting and monitoring sub-processors) and Hungary (a feature flag sub-processor). Transfer mechanism: the UK Addendum to the EU standard contractual clauses, which Supabase's data processing agreement makes part of it. Resend processes data in the United States (account data, email metadata and logs, and Resend's sub-processors). Transfer mechanism: the UK Addendum to the EU standard contractual clauses, under Resend's data processing addendum, which also says Resend complies with the UK Extension to the EU-US Data Privacy Framework. Still to be confirmed: the sending region, which is chosen when the sending domain is added (Ireland is one of the choices). For plan orders, Stripe processes data in the United States (Stripe, LLC). Transfer mechanism: the UK-US Data Privacy Framework, which its data transfers addendum says its US company takes part in, or, failing that, the UK International Data Transfer Addendum in the same addendum. Still to be confirmed: the countries of its affiliates and sub-processors outside the United States. Ireland and Hungary are EEA states, which UK law treats as adequate (Data Protection Act 2018, Schedule 21, paragraphs 4 and 5). The security overview, section "Sub-processors", lists each sub-processor.
Is the service multi-tenant?	Yes. Every record belongs to one council, and the server reads and writes only the signed-in person's council's records. Tests check this with a second, made-up council.

Security

Question	Answer
Is data encrypted in transit?	Yes, HTTPS.
Is data encrypted at rest?	Yes, once live. Supabase encrypts the database and file storage.
How are backups made?	Daily database backups and a nightly copy of uploaded files are planned from the first council, held in EU (Ireland) and kept for 7 days. The security overview, section "Continuity", gives the proposed recovery point and recovery time.
Has a penetration test been done?	No. One is planned before the first council goes live.
Is there an audit log?	Yes. An append-only log records sign-in and sign-out, exports, imports, scheme set-up changes, case views, file views, person searches, subject access bundles and each record whose personal details are removed under its retention period, with who, what, when and the request's IP address. Team leaders can filter it and download it as CSV. Each event holds a hash of the one before it, and a check on the audit page names the first event that no longer matches. Each case also has its own history.
Is single sign-on supported?	Officers will sign in with the council's own accounts through OpenID Connect, Microsoft Entra ID first. No council has set this up yet. Applicants sign in by an emailed link.
How is an officer matched at their first sign-in?	By the account's sign-in name in Microsoft Entra ID (`preferred_username`, or `upn`). Entra's `email` claim is used only when Entra has checked its domain. Guest accounts are refused unless the council allows them. Council IT adds the optional claims `acct` and `xms_edov` to the ID token in the app registration. The officer's address must be at one of the council's email domains. The first sign-in then links the officer to the account's tenant and object ids.
Is multi-factor authentication enforced?	By the council's own identity provider, under its own policies. The product holds no officer passwords.
How long does a session last?	It ends after 30 minutes without use, or 12 hours after sign-in. The session cookie is Secure and HttpOnly.
Can access be removed the day someone leaves?	Yes. A team leader turns the officer's sign-in off, and their sessions end at once.
How is access controlled?	By role: team leader, officer, auditor, applicant and public, each seeing only their part. An auditor reads the audit log only. Only a team leader sets up schemes, assigns cases, decides cases in bulk, imports and exports records, produces renewal letters, reads the audit log, applies retention periods and answers subject access requests. The server checks each action.

Data protection

Question	Answer
Who is the controller?	The council. The supplier is a processor.
Is there a data processing agreement?	Yes, in draft, at /agreements/data-processing. A buyer ticks that they have read it before ordering. A solicitor will review it before the first contract.
Who are the sub-processors?	Planned for council scheme data: Vercel (application hosting), Supabase (database and files, in EU (Ireland)) and Resend (sign-in links and notices). Stripe takes card payment for plan orders bought on the website and holds no council scheme data. The list will be confirmed before contract. The security overview, section "Sub-processors", has the detail.
How fast are breaches reported?	Without undue delay, and within 24 hours of the supplier knowing.
Can data be exported at the end of the contract?	Yes. A team leader can download the full export at any time: one zip file holding every record of the council as JSON, one file per table, with the audit log and every uploaded file. It loads into an empty copy of the product through a supplier-run import, and each table comes back with the same number of records; tests check this. Each export also holds schema.json, a JSON Schema for every table, and fields.csv, which says what each field means, so another system can read it without the supplier. The full export format document in this pack gives the same, with the steps for reading an export. Each scheme's cases and licences also export as CSV files in two layouts, and the audit log as a CSV file. A file of the licences and cases changed is meant to be loaded once a day, for the day before. The draft data processing agreement sets out deletion of the council's data at the end of the contract.
How are retention periods applied?	Each scheme has two periods, set by a team leader in whole years: after a licence ends, and after an application is refused or withdrawn (6 and 2 years unless changed). A team leader's screen lists the records past their period. On confirmation it removes their personal details and uploaded files and keeps an anonymised row: scheme, licence type, stage, dates and postcode district. Each removal is in the audit log. The audit log is kept for 2 years unless the council sets another period; events past it are removed the same way, leaving one event that records the removal.
Can you help with subject access requests?	Yes. A team leader searches by name, email address or postal address across applicant accounts, applications, licences and the people named on them, and the text of notes, visit notes, representations, replies, letters and target notes. Each match says where the name was found. The team leader ticks the records that go in and downloads a subject access bundle: a zip file with those records, as JSON and as a page to read, and the files on those cases. Each search and download is in the audit log, the download with the records included.
Is there a DPIA?	This pack holds a draft for the council to adapt.

Accessibility

Question	Answer
Does the product meet WCAG 2.2 AA?	Partially. Automated checks pass; no independent audit has been done. See the accessibility statement in this pack.

Support and continuity

Question	Answer
What support is offered?	Email support on weekdays, 9:00 to 17:00, with a first reply within one working day, as the draft product agreement states.
What if the supplier stops trading?	A team leader can download the full export at any time: every record of the council, the audit log and every uploaded file, in one zip file. Its README.txt, schema.json and fields.csv say how another system reads it.

Full export format

Draft, 31 October 2026.

Version draft-2026-10-31. What changed

A team leader downloads the full export from the product as one zip file. This document describes what is in it, so another system can read it without the supplier. It is written from the product's own record types by a script, and the same descriptions are in the zip as schema.json (a JSON Schema for every table) and fields.csv (the field dictionary).

Reading the export

Unzip the file with any zip tool. Each entry is stored or deflated, the two standard zip methods.
Read manifest.json. It names the council, says when the export was made and by whom, gives the number of records in each table, and lists every file with its id, name, type, size in bytes and CRC-32 checksum.
Read each tables/<name>.json. Each is one JSON array, one object per record, in UTF-8. Its number of records matches the manifest's count for that table.
Check each table against schema.json. Its properties.<name> is the JSON Schema (draft 2020-12) for tables/<name>.json, and $defs holds the shapes the tables share. Any JSON Schema validator reads it.
Read fields.csv for what each field means. It has one row per field: the shape, the field, its type, whether every record has it, and a description.
Join the tables by id. A field such as caseId, applicationId, schemeId, licenceId or accountId holds the id of a record in another table. A case is a record in tables/applications.json.
Open an uploaded file at files/<id>, where the id is the one a record's file field gives (file.id, or photos[].id on a note). Check its size and checksum against the manifest.
Check the audit log if needed. In tables/auditEvents.json each event's hash is the SHA-256, in hex, of its prevHash, a new line, and its other fields as JSON with keys in alphabetical order. Each prevHash is the hash of the event before it, and manifest.json's auditHeadHash is the newest hash.
Read the values as written. Money is in whole pence. A date is a calendar date in UK time, written YYYY-MM-DD. A timestamp is an ISO timestamp in UTC. A field that is not required can be left out of a record.

Tables

File	Shape of each record	What a record is
tables/councils.json	Council	A council that runs licensing schemes in the product. A full export holds the one council it was made for.
tables/schemes.json	Scheme	A licensing scheme: one designation (selective or additional) over an area, with its fees, conditions and letters.
tables/areaAddresses.json	AreaAddress	One address in a scheme's designated area (the area is held as a list of UPRNs). An address is in the area exactly when a record with its UPRN exists for the scheme, so look one up by schemeId and uprn, not by id. The record id is the bare UPRN or "schemeId:uprn"; the second lets two schemes cover the same house. A UPRN-only import has empty address fields.
tables/officers.json	Officer	A member of the council's licensing team: a team leader, an officer or an auditor.
tables/accounts.json	ApplicantAccount	A landlord's or letting agent's account on the council's applicant portal.
tables/properties.json	Property	A property an applicant account has applied for, in one scheme.
tables/applications.json	Application	An application for a licence: a case. Its id is the case reference.
tables/certificates.json	Certificate	A gas safety record, electrical installation condition report or energy performance certificate given with an application. Current on a date on or before expiresOn.
tables/payments.json	Payment	A payment of Part A or Part B. Simulated when the demo payment page recorded it (no money taken); otherwise an officer recorded it, one at a time or from a CSV of the council's payment confirmations.
tables/licences.json	Licence	A licence the council granted, or one imported from its earlier records.
tables/variations.json	Variation	A change to a licence: a new holder, a new manager or new conditions.
tables/documents.json	GeneratedDocument	A letter generated from a scheme template and recorded on a case. Nothing is sent.
tables/notes.json	Note	A note on a case, with any photos taken on a visit.
tables/representations.json	CaseRepresentation	A representation kept as a record of its own, with the case it was made on.
tables/replyDocuments.json	ReplyDocument	A document the applicant sent with a reply to a request for information (a tenancy agreement, a floor plan), with what they say it is. One record each, linked to the case. The seen field is set when an officer opens it and records that they have read it.
tables/targets.json	Target	One address on a scheme's target list, as a record the licensing team works: who follows it up, what they found, and their notes. The id is <scheme id>-T<UPRN>, so a scheme holds one record per UPRN. An application sent to the council for the UPRN closes the target; that is worked out when the list is read, so the dashboard's gap count and the target list always agree.
tables/visits.json	Visit	An inspection visit on a case, for one officer on a day at a time. Booked, moved and cancelled from the case page. A cancelled visit stays on the case with its history. The booking fields are optional, so a visit made before visits could be moved or cancelled reads as booked.
tables/history.json	HistoryEntry	One line in a case history: who did what, when. Every stage move leaves one.
tables/notifications.json	Notification	A message to the applicant about a letter an officer issued, queued in the no-send outbox. It is kept so an officer can see what would go out; nothing is emailed, posted or sent.
tables/auditEvents.json	AuditEvent	One line of the audit log: who did what, when, and from where.

Fields

Each shape has a table of its fields. Required "yes" means every record has the field, though it can be null where its type says so; "no" means a record can leave it out. A field whose type names another shape holds an object of that shape.

Council

A council that runs licensing schemes in the product. A full export holds the one council it was made for.

Field	Type	Required	Description
id	text	yes	The council's id. Every record of the council names it as councilId.
name	text	yes	The council's name as letters and pages show it.
referenceCode	text	yes	The letters that start the council's case and licence references, such as "NB" for "NB-S-000123". Two to four capital letters, and no two councils share one: every store refuses a clash.
officerSignIn	CouncilSignIn	no	The council's own identity provider for officers. Left out means officers cannot sign in outside the demo.
sessionPolicy	object	no	How long a session lasts. Left out means 30 minutes idle and 12 hours in all.
sessionPolicy.idleMinutes	number	yes	Minutes without activity after which a session ends.
sessionPolicy.absoluteHours	number	yes	Hours after sign-in after which a session ends, however active.
auditRetentionYears	number	no	How many whole years the council keeps its audit log. Left out means 2 years. A team leader sets it on the retention screen; events past it are listed there and removed on confirmation.
allowedEmailDomains	list of text	no	The email domains an officer's work address may be at, such as "northbridge.example.gov.uk", in lower case. Adding an officer, or changing an officer's address, outside them is refused. Left out or empty means any domain.
allowGuestSignIn	true or false	no	True when a guest account in the council's Microsoft Entra tenant may sign in as an officer. A guest is known by the token's acct claim (1), by #EXT# in the sign-in name, or by an idp claim other than the issuer. Left out means guests are refused.

Scheme

A licensing scheme: one designation (selective or additional) over an area, with its fees, conditions and letters.

Field	Type	Required	Description
id	text	yes	The scheme's id. Records under the scheme name it as schemeId.
councilId	text	yes	The council that runs the scheme.
name	text	yes	The scheme's name, as the pages show it.
type	one of "additional", "selective"	yes	"selective" for a selective licensing scheme, "additional" for an additional HMO licensing scheme.
grounds	list of one of "anti-social-behaviour", "crime", "deprivation", "hmo-management", "housing-conditions", "low-housing-demand", "migration"	yes	The grounds the council relied on; checked against the scheme type.
designationMadeOn	date	yes	The day the council made the designation.
designationRoute	one of "confirmed", "general-approval"	no	Whether the designation needed confirming by the Secretary of State or came in under a general approval. The officer records which applies. Left out means a general approval.
registerHolderAddress	one of "as-given", "correspondence"	no	Regulation 11(1)(a): which address the register shows for the licence holder. The law does not say, so the council chooses. Left out means "as-given".
confirmedOn	date, or null	no	The confirmation date, on the confirmed route.
designationStartsOn	date	yes	No earlier than three months after the designation is made or confirmed.
applicationsOpenOn	date	yes	May be before the designation start date, so landlords can apply ahead of it.
endsOn	date	yes	No more than five years after the start date.
predictedApplications	number	yes	How many applications the council expects over the scheme, as given on set-up.
fees	FeeSchedule	yes	The scheme's fees.
conditions	list of Condition	yes	The licence conditions every licence of the scheme starts with, mandatory ones included.
letterTemplates	list of LetterTemplate	yes	The scheme's letters, one per kind.
paymentPageUrl	text	yes	Where "Pay Part A" and "Pay Part B" go. The council's own payment page in real use; a demo page here.
renewalPeriodDays	number	yes	How many days before a licence ends renewal opens: from that day the licence is on the renewals list.
renewalReminderDays	list of number	no	The council's dates for renewal reminder letters, as days before a licence ends, such as [90, 28]. Each is no more than renewalPeriodDays. Left out on older records, which read as renewalPeriodDays and 28.
licenceTermMonths	number	yes	Default licence length in months (never over five years).
status	one of "open", "setting-up"	yes	"setting-up" until a team leader opens the scheme to applications, then "open".
areaImport	AreaImportReport	no	The last designated-area import during set-up: how many rows went in and each row left out, with its reason.
areaReplacePending	object	no	A replacement of the designated area that would take open cases out of it, held until a team leader confirms or cancels it. Nothing changes in the area until then.
areaReplacePending.rows	list of object	yes	The addresses the new area would hold.
areaReplacePending.rows[].uprn	text	yes	The address's UPRN.
areaReplacePending.rows[].address	PostalAddress	yes	The address as imported.
areaReplacePending.rejected	list of object	yes	The rows of the import that were left out, with the reason for each.
areaReplacePending.rejected[].row	number	yes	The row's number in the file.
areaReplacePending.rejected[].text	text	yes	The row as it was in the file.
areaReplacePending.rejected[].reason	text	yes	Why it was left out.
areaReplacePending.leaving	list of object	yes	The open cases whose address the new area would leave out.
areaReplacePending.leaving[].caseId	text	yes	The case, by id.
areaReplacePending.leaving[].uprn	text	yes	The case's UPRN.
targetList	TargetList	no	The council's target list, UPRNs in the area it expects to need a licence (from its own records or a data supplier). The dashboard lists those with no application yet. Nothing predicts which properties are unlicensed.
autoAllocate	true or false	no	When on, each new submission is assigned to the next active officer in turn. Off by default; left out means off. A team leader switches it on the scheme dashboard.
lastAllocatedOfficerId	text, or null	no	The officer the last new submission went to, so the next one goes to the officer after them.
registerCsv	true or false	no	Whether the public register offers the whole register as a CSV download. The register page is always on; the bulk file is the council's choice. Off for a new scheme; left out means off.
privacyNoticeUrl	text	no	The council's privacy notice for the scheme, an https address. Empty or left out means none given.
accessibilityStatementUrl	text	no	The council's own accessibility statement, an https address. Empty or left out means none given.
returnAddress	text	no	The licensing team's postal address for a signed paper declaration, as typed on the notices step, one line per address line. Council data, not personal data. Empty or left out means none given.
representationsEmail	text	no	The council's email address for representations on a notice, as typed on the notices step. Council data, not personal data. Empty or left out means none given; notices then name the postal address or the council.
retention	RetentionPeriods	no	How long the scheme's records are kept, in whole years. Left out means the defaults: 6 years after a licence ends, and 2 years after an application is refused or withdrawn.

AreaAddress

One address in a scheme's designated area (the area is held as a list of UPRNs). An address is in the area exactly when a record with its UPRN exists for the scheme, so look one up by schemeId and uprn, not by id. The record id is the bare UPRN or "schemeId:uprn"; the second lets two schemes cover the same house. A UPRN-only import has empty address fields.

Field	Type	Required	Description
id	text	yes	The record's id: the UPRN, or the scheme's id, ":" and the UPRN.
schemeId	text	yes	The scheme whose area holds the address.
uprn	text	yes	The address's UPRN.
address	PostalAddress	yes	The postal address; its fields are empty when only the UPRN was imported.

Officer

A member of the council's licensing team: a team leader, an officer or an auditor.

Field	Type	Required	Description
id	text	yes	The officer's id, such as "OFF-04". Records the officer made name it.
councilId	text	yes	The council the officer works for. Every read and write they make is kept to it.
name	text	yes	The officer's name.
email	text	yes	The officer's work email address.
role	one of "auditor", "officer", "team-leader"	yes	An auditor reads and downloads the audit log only; they hold no cases.
active	true or false	no	False once the officer has left the team or is away, so no case is allocated to them. Left out means active.
removedAt	timestamp	no	When a team leader removed the officer from the team. The record is kept, so case history and the audit log still name them; they are inactive, their sign-in is off and they leave every "Assign to" list.
awayFrom	date	no	The first day the officer is away, included. Automatic allocation passes them by; sign-in stays on.
awayTo	date	no	The last day the officer is away, included.
signInOffAt	timestamp	no	When a team leader turned the officer's sign-in off. Their sessions end at once and they cannot sign in.
signInIdentity	OfficerIdentity	no	The council identity provider account the officer first signed in with: the tenant (Entra's tid, else the issuer) and the account's stable id (Entra's oid, else sub). A later sign-in must name the same account.

ApplicantAccount

A landlord's or letting agent's account on the council's applicant portal.

Field	Type	Required	Description
id	text	yes	The account's id. Properties, applications and licences name it as accountId.
councilId	text	yes	The council whose portal the account was opened on. An account applies to that council's schemes only.
kind	one of "agent", "landlord"	yes	Whether the account is a landlord's or a letting agent's.
name	text	yes	The person who signs in.
organisation	text	no	A letting agent's trading name.
email	text	yes	The email address the account signs in with.
phone	text	yes	A phone number for the account.
address	PostalAddress	yes	The account's postal address.
erased	Erasure	no	Set once every record on the account has passed its retention period and its details were removed.

Property

A property an applicant account has applied for, in one scheme.

Field	Type	Required	Description
id	text	yes	The property's id. Applications and licences name it as propertyId.
accountId	text	yes	The applicant account that added it.
schemeId	text	yes	The scheme it is in.
uprn	text, or null	yes	Null when the address was typed in by hand and has no UPRN: an officer decides.
address	PostalAddress	yes	The property's postal address.
description	text	yes	The short description the register shows, such as "Two-storey terraced house".
hmo	HmoParticulars	no	Set for additional (HMO) scheme properties.
addressCheck	one of "added-to-area", "matched", "outside-scheme", "to-be-checked"	yes	An address not found in the area waits for an officer.
outsideReason	text	no	Why the officer recorded the address as outside the scheme.
details	PropertyDetails	no	The Schedule 2 paragraph 2(1)(c) to (g) answers given on an application made in the product.
erased	Erasure	no	Set once the property's address was cut to its postcode district under the retention period.

Application

An application for a licence: a case. Its id is the case reference.

Field	Type	Required	Description
id	text	yes	The stable reference, such as "NB-S-000123".
councilId	text	yes	The council the application is made to, the same as its scheme's.
schemeId	text	yes	The scheme it is made under.
accountId	text	yes	The applicant account that made it.
propertyId	text	yes	The property it is for.
stage	one of "awaiting-payment", "draft", "draft-licence-issued", "granted", "information-requested", "refused", "representations-open", "submitted", "withdrawn"	yes	Where the case stands.
renewalOf	text, or null	yes	The licence this application renews, if it is a renewal (a renewal asks for less).
licenceHolder	Person	yes	The proposed licence holder.
manager	Person, or null	yes	The manager of the house, or null when there is none.
interestedPersons	list of Person	yes	Other people with an interest the applicant names.
fitAndProper	FitAndProperDeclaration, or null	yes	The fit and proper person answers, or null until given.
createdOn	date	yes	The day the application was started.
submittedOn	date, or null	yes	The day it was sent to the council, or null while a draft.
pricedOn	date	no	The day the application left draft, by Part A paid on the demo payment page or by being sent to the council's payment page. Its fee line is the one for this day, so the price stays as sent. Left out on a draft and on records from before which keep the line for the day they were started.
assignedOfficerId	text, or null	yes	The officer the case is assigned to, or null.
informationReplyBy	date, or null	yes	Reply-by date of an open request for information.
proposedDecision	one of "grant", "refuse", or null	yes	What the notice proposes, once one is served.
noticeServedOn	date, or null	yes	The date the (last) notice was served.
representationsCloseOn	date, or null	yes	The last day representations may be made; at least 14 days after service.
decidedOn	date, or null	yes	The decision date.
refusalReasons	list of text	yes	The council's reasons, on a refusal. Empty otherwise.
withdrawnOn	date, or null	yes	The day the case was withdrawn or closed without a licence, or null.
licenceId	text, or null	yes	The licence issued on grant.
personInControl	Person, or null	no	Schedule 2 para 2(1)(a)(iv): the person having control of the house, when not the licence holder.
otherLicences	text	no	Schedule 2 para 2(1)(e): other licences, as the applicant describes them, or "None".
declaration	object, or null	no	Schedule 2 para 4: the signed declaration. Regulation 7(4): when the applicant proposes someone else as licence holder, the proposed licence holder signs too.
declaration.signedBy	text	yes	The name the applicant signed with.
declaration.signedOn	date	yes	The day they signed.
declaration.holderSignedBy	text	no	The name the proposed licence holder signed with, when they are not the applicant.
declaration.renewalSignedBy	text	no	On a renewal: the name signed to confirm the earlier answers still stand.
declaration.renewalChanges	text	no	On a renewal: what the applicant says has changed since the licence was granted.
declaration.byPost	PostedDeclaration	no	Set when the declaration was signed on paper and received by post.
enteredBy	EnteredBy	no	Set when an officer entered the application on the applicant's behalf.
claimedDiscounts	list of text	no	The discounts the applicant claims, by id. The council checks each claim.
feeDiscounts	list of Discount	no	The scheme's discounts as they stood when the application was started, so a discount changed later applies only to applications started after the change. Left out on older records, which read the scheme's discounts now.
discountChecks	list of DiscountCheck	no	The council's check of each discount claimed, one per discount id. A rejected one is added to Part B.
stepsSaved	list of text	no	The form steps the applicant has saved, so a draft resumes where it was left.
draftConditions	list of Condition, or null	no	The draft licence's conditions for this property, once an officer has edited them. Until then the scheme's conditions apply. Mandatory conditions are always the scheme's own, locked.
representations	list of Representation	no	Representations logged before each one became a record of its own in the representations collection, kept on the application. The case page reads both.
decidedBy	text, or null	no	The officer who recorded the decision.
source	one of "imported"	no	"imported" for a granted case made from a licence imported from the council's previous records.
relevantPersons	list of RelevantPerson	no	The owner, freeholder, mortgage lender and leaseholder, as many as the applicant names. Left out means none.
erased	Erasure	no	Set once the case passed its retention period and its personal details were removed.
awaitingPost	AwaitingPost, or null	no	Set while a notice or licence served by post on this case waits for the officer to record the day it was posted. While a notice waits, the case has no service date and no closing date.
noticePostedOn	date, or null	no	The day the last notice was posted, when it went by post; its date of service (noticeServedOn) is later.
copiedFrom	text	no	The earlier application on the same account the licence holder, manager and interested persons were copied from when this one was started. Left out when nothing was copied.
copiedSteps	list of one of "holder", "manager", "people"	no	The steps that copy put something into ("holder" always; "manager" and "people" when the earlier application had them), recorded when this one was started, so the "Copied from" markers do not change when the earlier application is later changed or erased. Left out when nothing was copied.
closure	CaseClosure	no	How an officer closed the case without a licence. The stage is "withdrawn" for each kind, so every list, count, export and retention rule that treats a withdrawn case as closed treats these the same; the kind says which it was. Left out on a case closed before closures had kinds, which reads as withdrawn.
withdrawalRequest	WithdrawalRequest	no	The applicant asked to withdraw from their application page. An officer confirms it on the case.

Certificate

A gas safety record, electrical installation condition report or energy performance certificate given with an application. Current on a date on or before expiresOn.

Field	Type	Required	Description
id	text	yes	The record's id: the case reference, "-" and the kind.
applicationId	text	yes	The case it was given for.
kind	one of "eicr", "epc", "gas"	yes	"gas" for a gas safety record, "eicr" for an electrical installation condition report, "epc" for an energy performance certificate.
issuedOn	date	yes	The check, inspection or EPC register date.
expiresOn	date	yes	The last day it is current.
file	FileRef	yes	The uploaded file.
uploadedOn	date	no	The day the file was uploaded. Records kept before uploads were dated have none.
seen	Seen	no	An officer opened this file and recorded that it matches the dates given. A new file or new dates clear it, as the record is written again without it.

Payment

A payment of Part A or Part B. Simulated when the demo payment page recorded it (no money taken); otherwise an officer recorded it, one at a time or from a CSV of the council's payment confirmations.

Field	Type	Required	Description
id	text	yes	The record's id: the case reference, "-" and the part.
applicationId	text	yes	The case it is for.
part	one of "A", "B"	yes	Which part of the fee it is.
amount	number	yes	The amount due, in pence.
status	one of "paid", "requested"	yes	Whether it has been paid.
requestedOn	date	yes	The day it was asked for.
paidOn	date, or null	yes	The day it was paid, or null.
simulated	true or false	yes	True when the demo payment page recorded it and no money was taken.
recordedVia	one of "import", "officer"	no	How a paid payment was recorded. Left out on payments made on the demo payment page.
recordedBy	text	no	The officer who recorded it.
receipt	text	no	The council's own receipt or transaction reference, when given.

Licence

A licence the council granted, or one imported from its earlier records.

Field	Type	Required	Description
id	text	yes	The stable reference the register shows, such as "NB-S-L-0201".
councilId	text	yes	The council that granted the licence, the same as its scheme's.
schemeId	text	yes	The scheme it is granted under.
applicationId	text, or null	yes	Null for a licence imported from the council's previous system.
propertyId	text	yes	The property it licenses.
accountId	text	yes	The applicant account it belongs to.
holder	Person	yes	The licence holder.
manager	Person, or null	yes	The manager of the house, or null when there is none.
conditions	list of Condition	yes	The licence's conditions.
grantedOn	date	yes	The day it was granted.
startsOn	date	yes	On the register from this day. Cannot be before the scheme start date.
endsOn	date	yes	On the register up to and including this day. At most five years on.
status	one of "granted", "revoked"	yes	"revoked" once the council revokes it.
revocationEffectiveOn	date, or null	yes	Off the register from this day.
revocation	object	no	The officer who recorded the revocation, the day they recorded it, and the council's reason.
revocation.reason	text	yes	The council's reason.
revocation.by	text	yes	The officer who recorded it, by id.
revocation.recordedOn	date	yes	The day it was recorded.
revocation.proposedOn	date	no	The day the revocation was proposed, when it was proposed first.
revocation.agreedWithHolder	true or false	no	True when the licence holder agreed to the revocation, so it took effect on the day it was made.
revocation.appealPeriodEnds	date, or null	no	The last day an appeal could be made; null when the licence holder agreed.
revocation.appeal	RevocationAppeal	no	An appeal against the revocation to the tribunal, as the council recorded it.
revocationProposal	RevocationProposal	no	A revocation proposed and not yet decided. The notice of proposed revocation is served with a representations period of at least 14 days after service; the licence stays in force and on the register meanwhile.
tribunal	list of TribunalMatter	no	Regulation 11(1)(g) and (h): any matter about this licence referred to a tribunal, in summary.
source	one of "imported"	no	"imported" for a licence imported from the council's previous records.
particulars	object	no	Regulation 11(1)(d) and 11(2): the register particulars this licence was granted on, when they differ from the property record's. Set on the grant of a renewal from the renewal's answers; otherwise the register reads the property.
particulars.description	text	yes	The short description the register shows.
particulars.hmo	HmoParticulars	no	The HMO particulars, for an HMO licence.
erased	Erasure	no	Set once the licence passed its retention period and its personal details were removed.

Variation

A change to a licence: a new holder, a new manager or new conditions.

Field	Type	Required	Description
id	text	yes	The variation's id: the licence reference, "-V" and a number.
licenceId	text	yes	The licence it changes.
kind	one of "conditions", "licence-holder", "manager"	yes	What it changes.
holder	Person	no	The new holder, on a change of licence holder.
manager	Person	no	The new manager, on a change of manager.
conditions	list of Condition	no	The new conditions, on a change of conditions.
agreedWithHolder	true or false	yes	True when the licence holder agreed to it, so no notice is needed.
proposedOn	date	yes	The day it was proposed.
effectiveOn	date, or null	yes	The day it takes effect; until then the register shows the old details.
status	one of "made", "proposed", "withdrawn"	yes	Where the variation stands.
reason	text	no	Why the council proposes it, in a sentence.
noticeServedOn	date, or null	no	The day the notice of proposed variation was served.
representationsCloseOn	date, or null	no	The last day for representations on the notice of proposed variation.
madeOn	date, or null	no	The day the decision to vary was made.
appealPeriodEnds	date, or null	no	The last day an appeal can be made; null when the holder agreed.
proposedBy	text	no	The officer who proposed it, by id.
madeBy	text, or null	no	The officer who made it, by id, or null until it is made.

GeneratedDocument

A letter generated from a scheme template and recorded on a case. Nothing is sent.

Field	Type	Required	Description
id	text	yes	The letter's id, such as "DOC-000123".
caseId	text	yes	The case it is recorded on.
kind	one of "grant-notice", "licence", "notice-of-intention", "refusal-decision", "refusal-notice", "renewal-reminder", "request-for-information", "revocation-notice", "revocation-proposal", "variation-notice", "variation-proposal"	yes	Which letter it is.
title	text	yes	The letter's title.
body	text	yes	The letter's text, filled in from the case.
issuedOn	date	yes	The day it was issued.
issuedBy	text	yes	The officer who issued it, by id.
licenceId	text	no	The licence a renewal reminder or variation letter is about.
dueOn	date	no	A renewal reminder: the council's reminder date it was produced for.
variationId	text	no	A variation letter: the variation it records.
servedOn	list of ServiceRecord	no	A notice or licence: each person it was served on and how, as the officer recorded it. Nothing is sent.
postStatus	one of "posted", "ready"	no	A notice or licence with a postal method in its service record is "ready" until an officer records the day it was posted, then "posted". Left out on letters with no postal service and on every letter issued before posting was recorded, which count as served on the day they were issued.
postedOn	date	no	The day the letter was posted, as the officer recorded it.
postedBy	text	no	The officer who recorded the day it was posted, by id.
batch	text	no	The bulk decision the letter was issued in, so the letters of one bulk step download as one PDF.
encloses	list of text	no	Letters sent with this one, such as the proposed licence with a notice of proposed grant, by id.
closingDateAt	list of number	no	A notice that gives a closing date: where the date sits in the text, as character offsets, so printing it for another posting date changes only the date. Empty when the council's template gives no closing date.

Note

A note on a case, with any photos taken on a visit.

Field	Type	Required	Description
id	text	yes	The note's id: the case reference, "-N" and a number.
caseId	text	yes	The case it is on.
authorId	text	yes	The officer who wrote it, by id.
at	timestamp	yes	When it was written, as an ISO timestamp.
text	text	yes	The note's text.
photos	list of FileRef	yes	Photos added with it. Each file's bytes are at files/<id> in a full export.
visitId	text	no	The visit the note was added from, when it was added on a visit.
outcome	one of "cancelled", "inspected-breaches", "inspected-no-issues", "no-access"	no	What happened on the visit. Every note added from a visit since outcomes were recorded has one; an older visit note with none is read as an inspection.
breachedConditions	list of object	no	On "inspected-breaches", the licence conditions found breached, with their text as it was on the day.
breachedConditions[].id	text	yes	The condition's id on the licence.
breachedConditions[].text	text	yes	The condition's text on the day.
followUpBy	date	no	On "inspected-breaches", the day the breaches are to be followed up by.

CaseRepresentation

A representation kept as a record of its own, with the case it was made on.

Field	Type	Required	Description
caseId	text	yes	The case it was made on.
id	text	yes	The representation's id.
from	text	yes	Who made it, such as the applicant, a tenant or a mortgage lender.
receivedOn	date	yes	The day the council received it.
summary	text	yes	What they said, in summary.
response	text, or null	yes	The council's response, once given.
respondedOn	date, or null	yes	The day the council responded, or null.
loggedBy	text	yes	The officer who logged it, or the applicant's account when they made it online.
online	true or false	no	True when the applicant made it from their application page.

ReplyDocument

A document the applicant sent with a reply to a request for information (a tenancy agreement, a floor plan), with what they say it is. One record each, linked to the case. The seen field is set when an officer opens it and records that they have read it.

Field	Type	Required	Description
id	text	yes	Such as "NB-S-000005-RD1".
caseId	text	yes	The case it was sent on.
description	text	yes	What the applicant says the document is.
file	FileRef	yes	The uploaded file.
sentBy	text	yes	The applicant account that sent it.
sentAt	timestamp	yes	When it was sent, as an ISO timestamp.
seen	Seen	no	Set when an officer records that they have read it.

Target

One address on a scheme's target list, as a record the licensing team works: who follows it up, what they found, and their notes. The id is <scheme id>-T<UPRN>, so a scheme holds one record per UPRN. An application sent to the council for the UPRN closes the target; that is worked out when the list is read, so the dashboard's gap count and the target list always agree.

Field	Type	Required	Description
id	text	yes	The record's id: the scheme's id, "-T" and the UPRN.
schemeId	text	yes	The scheme whose target list holds the address.
uprn	text	yes	The address's UPRN.
status	one of "let-no-application", "no-licence-needed", "open", "referred-for-enforcement"	yes	"open" until an officer records what the team found: the address needs no licence, it is let with no application made, or it has been referred for enforcement.
officerId	text, or null	yes	The officer following it up, or null.
reason	one of "not-let", "other", "out-of-scope", "owner-occupied", or null	yes	Set with "no-licence-needed".
reasonNote	text	yes	Why, in the officer's words; needed for "other", optional for the rest.
notes	text	yes	The team's working notes on the address. Free text.
addedOn	date	yes	The day the address first came onto the list.
history	list of TargetHistoryEntry	yes	Each change to the record, oldest first.
followUpOn	date	no	The day the team means to follow the address up next. Left out means none set.

Visit

An inspection visit on a case, for one officer on a day at a time. Booked, moved and cancelled from the case page. A cancelled visit stays on the case with its history. The booking fields are optional, so a visit made before visits could be moved or cancelled reads as booked.

Field	Type	Required	Description
id	text	yes	The visit's id.
officerId	text	yes	The officer making the visit.
caseId	text	yes	The case it is for.
date	date	yes	The day of the visit.
time	text	yes	24-hour time, such as "09:30".
status	one of "cancelled"	no	"cancelled" once cancelled; absent while booked.
bookedBy	text	no	The officer who booked it, by id.
bookedAt	timestamp	no	When it was booked, as an ISO timestamp.
movedBy	text	no	The officer who last moved it, by id.
movedAt	timestamp	no	When it was last moved, as an ISO timestamp.
cancelledBy	text	no	The officer who cancelled it, by id.
cancelledAt	timestamp	no	When it was cancelled, as an ISO timestamp.
cancelReason	text	no	The reason given for cancelling, if any.

HistoryEntry

One line in a case history: who did what, when. Every stage move leaves one.

Field	Type	Required	Description
id	text	yes	The line's id, such as "H-000123".
councilId	text	yes	The council the case belongs to.
caseId	text	yes	The case it is on.
at	timestamp	yes	When it happened, as an ISO timestamp.
actorId	text	yes	An officer id, an applicant account id, or "system".
action	text	yes	What happened, in words, such as "Licence granted".
fromStage	one of "awaiting-payment", "draft", "draft-licence-issued", "granted", "information-requested", "refused", "representations-open", "submitted", "withdrawn"	no	The stage the case moved from, on a stage move.
toStage	one of "awaiting-payment", "draft", "draft-licence-issued", "granted", "information-requested", "refused", "representations-open", "submitted", "withdrawn"	no	The stage the case moved to, on a stage move.
noteId	text	no	A note the entry records, such as one added on a visit, so the history can show it with its photos.
service	list of ServiceRecord	no	The people a notice or licence was served on, and how, so the history can list them.

Notification

A message to the applicant about a letter an officer issued, queued in the no-send outbox. It is kept so an officer can see what would go out; nothing is emailed, posted or sent.

Field	Type	Required	Description
id	text	yes	The message's id.
caseId	text	yes	The case it is about.
kind	one of "declaration-request", "grant-notice", "licence", "notice-of-intention", "part-b-request", "refusal", "refusal-decision", "refusal-notice", "renewal-reminder", "request-for-information", "revocation-notice", "revocation-proposal", "variation-notice", "variation-proposal"	yes	What it tells the applicant about.
to	text	yes	The applicant's email address.
accountId	text, or null	yes	The applicant account it is for, when the case has one.
subject	text	yes	The message's subject line.
text	text	yes	The message's text.
documentId	text	no	The letter on the case it is about, if any.
queuedAt	timestamp	yes	When it was queued, as an ISO timestamp.
queuedBy	text	yes	The officer whose action queued it.
status	one of "queued"	yes	Always "queued": the outbox sends nothing.

AuditEvent

One line of the audit log: who did what, when, and from where.

Field	Type	Required	Description
id	text	yes	Such as "AUD-000001", in the order events were written.
at	timestamp	yes	When it was written, as an ISO timestamp.
prevHash	text	no	The hash of the council's event before this one, empty for the council's first. Left out on events written before the chain began.
hash	text	no	SHA-256, in hex, of prevHash, a new line, and this event's other fields as JSON with keys in alphabetical order. Left out on events written before the chain began.
councilId	text	yes	The council of the person who acted. Each council reads only its own events.
actorId	text	yes	An officer id or an applicant account id.
actorName	text	yes	The person's name when the event was written, so the log reads the same if they leave.
action	one of "access-refused", "application-entered", "audit-download", "audit-retention-erase", "audit-retention-set", "case-assign", "case-close", "case-grant", "case-notice", "case-view", "case-visit", "cases-reassigned", "council-sign-in-refused", "declaration-posted", "discount-check", "document-seen", "export", "file-view", "full-export", "import", "letter-download", "letters-posted", "letters-reprinted", "licence-revoke", "licence-revoke-appeal", "licence-revoke-proposal", "licence-revoke-withdrawn", "officer-added", "officer-away", "officer-removed", "officer-role-changed", "officer-sign-in-off", "officer-sign-in-on", "part-a-by-phone", "payment-record", "person-search", "reply-reminder", "representation-submitted", "retention-erase", "scheme-setup", "sign-in", "sign-in-refused", "sign-out", "subject-access", "target-assign", "target-update", "withdrawal-request"	yes	What was done.
recordId	text	no	The case, file or other record the event is about, when there is one.
schemeId	text	no	The scheme the event is about, when there is one.
details	object of text values	no	What else the event records, such as an export's layout and row count.
ip	text	no	The address the request came from, when the request says.
userAgent	text	no	The browser's user agent, when the request says.

CouncilSignIn

An OpenID Connect provider, such as the council's Microsoft Entra ID tenant. The client secret, where the provider needs one, is never stored here: it comes from an environment variable.

Field	Type	Required	Description
provider	one of "entra", "oidc"	yes	"entra" for Microsoft Entra ID, "oidc" for any other OpenID Connect provider.
issuer	text	yes	The issuer exactly as the provider's ID tokens give it, such as "https://login.microsoftonline.com/<tenant id>/v2.0".
clientId	text	yes	The application (client) id registered with the provider.

Discount

A discount a scheme offers on Part A of its fee, such as one for applying before the scheme starts.

Field	Type	Required	Description
id	text	yes	The discount's id, unique within the scheme, such as "DISC-EARLY". Applications name it in claimedDiscounts.
label	text	yes	What the discount is for, as the application form shows it.
amount	number	yes	Taken off Part A, in pence.
endsOn	date, or null	no	The last day the discount can be claimed. Left out or null means it has no end date.

FeeLine

One line of a scheme's fee table, such as "Standard HMO fee: £500 plus £50 per bedroom above 5" or a late rate for applications sent from the designation start date. Money is in whole pence.

Field	Type	Required	Description
id	text	yes	The line's id, unique within the scheme.
label	text	yes	The line's name, as the fee table shows it, such as "Standard HMO fee".
partA	number	yes	Part A on this line, paid with the application, in pence.
partB	number	yes	Part B on this line, paid on grant, in pence.
perUnit	object, or null	no	Added to Part A for each unit over the number the line already covers, counted from the property answers. Left out or null means none.
perUnit.amount	number	yes	The amount added for each unit, in pence.
perUnit.unit	one of "bedrooms", "households", "occupants"	yes	What is counted.
perUnit.above	number	yes	How many units the fee already covers; only units above this number are charged.
startsOn	date, or null	no	The first day an application can be started on this line. Left out or null means no first day.
endsOn	date, or null	no	The last day an application can be started on this line. Left out or null means no last day.

FeeSchedule

A two-part fee: Part A with the application, Part B only on grant. Part A plus Part B is the fee. A scheme can give a table of fee lines; partA and partB are then the first (standard) line's, so older code and records keep working. Left out or empty lines reads as one line from partA and partB.

Field	Type	Required	Description
partA	number	yes	Part A of the standard fee, paid with the application, in pence.
partB	number	yes	Part B of the standard fee, paid only when a licence is granted, in pence.
discounts	list of Discount	yes	The discounts the scheme offers on Part A.
lines	list of FeeLine	no	The scheme's fee table, when it has more than the standard line.

Condition

A licence condition: one the law requires, or one the council adds.

Field	Type	Required	Description
id	text	yes	The condition's id, unique within the scheme, such as "COND-L1".
text	text	yes	The condition as the licence states it.
mandatory	true or false	yes	Schedule 4 mandatory conditions are locked: an officer cannot edit or drop them.

LetterTemplate

A letter the product fills in from a case. Merge fields are a field name in double curly brackets, such as the case reference.

Field	Type	Required	Description
kind	one of "grant-notice", "licence", "notice-of-intention", "refusal-decision", "refusal-notice", "renewal-reminder", "request-for-information", "revocation-notice", "revocation-proposal", "variation-notice", "variation-proposal"	yes	Which letter it is.
title	text	yes	The letter's title.
body	text	yes	The letter's text, with its merge fields.

AreaImportReport

What one import of a designated area did: how many rows went in, and each row left out with its reason.

Field	Type	Required	Description
accepted	number	yes	How many rows went in.
rejected	list of object	yes	Each row left out.
rejected[].row	number	yes	The row's number in the file.
rejected[].text	text	yes	The row as it was in the file.
rejected[].reason	text	yes	Why it was left out.

PostalAddress

A postal address as the forms and the register show it.

Field	Type	Required	Description
line1	text	yes	The first line, such as the house number and street. Empty when only a UPRN was imported.
line2	text	no	A second line, when there is one.
town	text	yes	The town or city.
postcode	text	yes	The postcode, such as "NB1 2AB".

TargetList

A scheme's target list, as last imported. Importing again replaces the list; the target records of UPRNs still on it are kept.

Field	Type	Required	Description
uprns	list of text	yes	The UPRNs on the list.
importedOn	date	yes	The day the list was imported.
importedBy	text	yes	The officer who imported it, by id.

RetentionPeriods

A scheme's retention periods, in whole years.

Field	Type	Required	Description
licenceYears	number	yes	Years after a licence ends (or its revocation takes effect).
closedYears	number	yes	Years after an application is refused or withdrawn.

OfficerIdentity

The identity provider account an officer signs in with.

Field	Type	Required	Description
tenant	text	yes	The tenant: Entra's tenant id, or the issuer for another provider.
subject	text	yes	The account's stable id at the provider: Entra's object id, or the subject for another provider.
boundAt	timestamp	yes	When the first council sign-in recorded it.

Erasure

Set on a record once its personal details were removed under the scheme's retention period. What is left is the anonymised statistical row: scheme, licence type, stage, dates and the postcode district.

Field	Type	Required	Description
on	date	yes	The day the details were removed.
by	text	yes	The team leader who confirmed it.

SharedAmenity

One kind of amenity an HMO's households share, and how many there are.

Field	Type	Required	Description
kind	one of "bathroom", "kitchen", "toilet", "wash-hand-basin"	yes	The amenity.
count	number	yes	How many of it the house has.

HmoParticulars

The regulation 11(2) particulars an HMO licence shows on the register.

Field	Type	Required	Description
storeys	number	yes	The number of storeys.
sleepingRooms	number	yes	The number of rooms used for sleeping.
livingRooms	number	yes	The number of living rooms.
selfContainedFlats	number	yes	The number of self-contained flats.
nonSelfContainedFlats	number	yes	The number of flats that are not self-contained.
sharedAmenities	list of SharedAmenity	yes	The amenities the households share.
maxOccupants	number	yes	The most people the house may hold.
maxHouseholds	number	yes	The most households the house may hold.
section257	true or false	yes	A section 257 HMO shows only storeys and self-contained flats.

PropertyDetails

What the application form asks about the house (SI 2006/373 Schedule 2 paragraph 2(1)(c) to (g)). Counts are null until the applicant answers.

Field	Type	Required	Description
type	text	yes	Para 2(1)(d): the type of house, such as "Terraced house".
builtAround	text	yes	Para 2(1)(c): the approximate age of the original construction, as the applicant gives it, such as "1900".
storeys	number, or null	yes	Para 2(1)(f): the number of storeys.
bedrooms	number, or null	yes	The number of bedrooms.
livingRooms	number, or null	yes	The number of living rooms.
kitchens	number, or null	yes	The number of kitchens.
bathrooms	number, or null	yes	The number of bathrooms.
toilets	number, or null	yes	The number of toilets.
maxOccupants	number, or null	yes	The most people the applicant proposes the house holds.
maxHouseholds	number, or null	yes	The most households the applicant proposes the house holds.
gasSupplied	true or false, or null	yes	A gas safety record is asked for only where gas is supplied. Null until answered.

Person

A named person on an application or licence: the proposed licence holder, the manager or an interested person.

Field	Type	Required	Description
name	text	yes	Their name, or an organisation's name.
address	PostalAddress	yes	Their postal address.
email	text	no	Their email address, when given.
phone	text	no	Their phone number, when given.

FitAndProperDeclaration

The Schedule 2 paragraph 3 answers. The officer weighs them; the product never decides.

Field	Type	Required	Description
banningOrder	true or false	yes	A banning order in force blocks a grant to that person.
otherMatters	true or false	yes	Any other declared matter (offences, discrimination, housing law breaches) for the officer to weigh.
convictions	true or false	no	Schedule 2 para 3(a): unspent convictions. Kept separately on applications made in the product.
discrimination	true or false	no	Schedule 2 para 3(b): a finding of unlawful discrimination.
housingLaw	true or false	no	Schedule 2 para 3(c): a housing, public health, environmental health or landlord and tenant law contravention.
details	text	no	The applicant's own account of any matter declared.
declaredOn	date	yes	The day the answers were given.

PostedDeclaration

The applicant's signed paper declaration, received by post and recorded by an officer.

Field	Type	Required	Description
receivedOn	date	yes	The day the council received it.
recordedBy	text	yes	The officer who recorded it, by id.
recordedAt	timestamp	yes	When the officer recorded it, as an ISO timestamp.

EnteredBy

An application an officer entered for the applicant, who gave their details by phone or at the council's office. The applicant still signs the declaration themselves (regulation 7(3)).

Field	Type	Required	Description
officerId	text	yes	The officer who entered it.
at	timestamp	yes	When they started it, as an ISO timestamp.
applicant	object	yes	The applicant as the officer took their details: a name, and an email address or a postal address.
applicant.name	text	yes	The applicant's name.
applicant.email	text	no	Their email address, when they gave one.
applicant.address	PostalAddress	no	Their postal address, when they gave one.
letterAt	timestamp	no	When the officer finished and the letter with the signing steps was queued, as an ISO timestamp.

DiscountCheck

An officer's check of one discount claimed.

Field	Type	Required	Description
discountId	text	yes	The discount checked, by its id in the scheme.
outcome	one of "accepted", "rejected"	yes	Whether the council accepted the claim.
amount	number	yes	The discount taken off Part A when it was claimed, in pence: what a rejection adds to Part B.
by	text	yes	The officer who checked it, by id.
on	date	yes	The day it was checked.

Representation

One representation made on a notice of proposed decision, and what the council made of it.

Field	Type	Required	Description
id	text	yes	The representation's id.
from	text	yes	Who made it, such as the applicant, a tenant or a mortgage lender.
receivedOn	date	yes	The day the council received it.
summary	text	yes	What they said, in summary.
response	text, or null	yes	The council's response, once given.
respondedOn	date, or null	yes	The day the council responded, or null.
loggedBy	text	yes	The officer who logged it, or the applicant's account when they made it online.
online	true or false	no	True when the applicant made it from their application page.

RelevantPerson

One relevant person, with a name and an address for service. An email address is optional.

Field	Type	Required	Description
role	one of "freeholder", "leaseholder", "mortgage-lender", "owner"	yes	Their interest in the property.
name	text	yes	Their name.
address	PostalAddress	yes	Their address for service.
email	text	no	Their email address, when given.

AwaitingPost

What a case waits on until its letters are recorded as posted.

Field	Type	Required	Description
issuedOn	date	yes	The day the letters were issued; the posting date cannot be earlier.
notice	one of "proposed-grant", "proposed-modifications", "proposed-refusal", "proposed-revocation"	no	The notice of proposed decision waiting, which sets the representations period; left out for a licence or a decision notice. "proposed-revocation" sets the period on the licence's proposed revocation.
printedClosingOn	date	no	The closing date the notice gives: worked out from the planned posting date once the letters are printed to post, and as if posted on the day issued until then.
plannedPostOn	date	no	The day the letters were last printed to be posted on. Posting can be recorded on that day or earlier; left out until they are printed, when the day issued stands in for it.
documentIds	list of text	yes	The letters waiting, by id.

CaseClosure

An officer's closure of a case without a licence, with the reason and any refund the council recorded.

Field	Type	Required	Description
kind	one of "no-licence-needed", "temporary-exemption", "withdrawn"	yes	How the case was closed.
reason	text	yes	The officer's reason, in their words.
on	date	yes	The day the case was closed.
by	text	yes	The officer who closed it.
refund	object	no	A refund of fees the council made or will make, in pence, with its own reference. Recorded only: no money moves.
refund.amount	number	yes	The refund, in pence.
refund.reference	text	no	The council's own reference for it, when given.
exemption	object	no	A temporary exemption notice (Housing Act 2004 sections 62 and 86): the day it was served and its last day in force, at most three months on. Until that last day the UPRN is out of the target list gap.
exemption.startsOn	date	yes	The day the notice was served.
exemption.endsOn	date	yes	Its last day in force.

WithdrawalRequest

The applicant's request to withdraw, as they made it.

Field	Type	Required	Description
at	timestamp	yes	When they asked, as an ISO timestamp.
by	text	yes	The applicant account that asked.
reason	text	no	Their reason, if they gave one.

FileRef

A file kept through the storage adapter. The bytes are held separately (Storage.saveFile).

Field	Type	Required	Description
id	text	yes	The file's id. In a full export its bytes are at files/<id>.
name	text	yes	The file's name as uploaded.
type	text	yes	Its media type, such as "application/pdf".
size	number	yes	Its size in bytes.

Seen

An officer's record that they opened a file and read it.

Field	Type	Required	Description
by	text	yes	The officer, by id.
at	timestamp	yes	When, as an ISO timestamp.

RevocationAppeal

An appeal against a revocation, as the council recorded it (Housing Act 2004 Schedule 5 paragraph 35). While it is made and not decided the licence stays in force and on the register. Once decided, the revocation takes effect on the day the council recorded, or the licence stays in force when the revocation was quashed.

Field	Type	Required	Description
madeOn	date	yes	The day the appeal was made.
recordedBy	text	yes	The officer who recorded the appeal, by id.
recordedOn	date	yes	The day the appeal was recorded.
outcome	one of "confirmed", "quashed", "withdrawn"	no	How the appeal ended; absent while it waits for a decision.
decidedOn	date	no	The day the tribunal decided the appeal, or the day it was withdrawn; absent while it waits.
decisionRecordedBy	text	no	The officer who recorded how the appeal ended, by id; absent while it waits.
decisionRecordedOn	date	no	The day the officer recorded how the appeal ended; absent while it waits.

RevocationProposal

A proposed revocation of a licence, waiting for the council's decision.

Field	Type	Required	Description
reason	text	yes	The council's reason.
agreedWithHolder	true or false	yes	True when the licence holder has agreed to the revocation, so it takes effect on the day it is made.
proposedOn	date	yes	The day it was proposed.
proposedBy	text	yes	The officer who proposed it, by id.
noticeServedOn	date, or null	yes	The date of service of the notice; null while the notice waits to be posted.
representationsCloseOn	date, or null	yes	The last day for representations; null while the notice waits to be posted.
printedClosingOn	date	yes	The closing date the notice gives, worked out as if served on the day it was issued, or from the planned posting date once printed to post.

TribunalMatter

A licensing matter referred to the First-tier Tribunal or the Upper Tribunal, and its decision once made.

Field	Type	Required	Description
tribunal	one of "first-tier", "upper"	yes	Which tribunal.
reference	text	yes	The reference number the tribunal gave the case.
referredOn	date	yes	The day the matter was referred.
summary	text	yes	What was referred, in a sentence.
decision	object, or null	yes	The tribunal's decision, or null until it is made.
decision.decidedOn	date	yes	The day the tribunal decided.
decision.summary	text	yes	What it decided, in a sentence.

ServiceRecord

One recipient of a notice or licence, and how the officer recorded it was served.

Field	Type	Required	Description
role	text	yes	Who they are on the case, such as "Applicant" or "Mortgage lender".
name	text	yes	Their name.
serviceAddress	text	yes	The address for service, on one line, or the email address when served by email.
method	one of "by-hand", "email", "first-class-post", "left-at-address", "recorded-delivery", "second-class-post"	yes	How it was served.

TargetHistoryEntry

One change to a target record, as its history lists it.

Field	Type	Required	Description
at	timestamp	yes	When, as an ISO timestamp.
by	text	yes	The officer who made the change.
text	text	yes	What changed, in words.

Document control

Each document and agreement has one version and a last changed date. The header date is the latest of them.

Data protection impact assessment
Version
draft-2026-10-30
Last changed
30 October 2026
Changes
- 30 October 2026: The bulk copying risk names the register search limit and the shortest street search.
- 30 October 2026: Tenants and occupiers added to the scope, with a risk for people named in free text.
- 28 October 2026: Where data is processed and the transfer mechanisms added.
- 27 October 2026: The council's privacy notice before a scheme opens added.
Record of data held
Version
draft-2026-10-30
Last changed
30 October 2026
Changes
- 30 October 2026: Person search covers notes and other free text.
- 30 October 2026: Decision notices for grant, refusal and revocation added.
- 28 October 2026: Refused access in the audit log, and its retention period, added.
Data flow
Version
draft-2026-10-30
Last changed
30 October 2026
Changes
- 30 October 2026: Subject access: choosing which matches go into the bundle.
- 30 October 2026: Decision notices and the full export format added.
- 28 October 2026: The changed-records export for the back office added.
Security overview
Version
draft-2026-10-31
Last changed
31 October 2026
Changes
- 31 October 2026: Every Entra host, more ways to know a guest, and the optional claims to add when setting up sign-in.
- 31 October 2026: Which header the IP address in the audit log comes from.
- 31 October 2026: The audit log's hash chain, the application's own database role and row-level security added.
- 30 October 2026: Officer sign-in claims and allowed email domains added.
- 30 October 2026: Proposed continuity figures added.
- 28 October 2026: Where data is processed and the transfer mechanisms added.
Product accessibility statement
Version
draft-2026-10-31
Last changed
31 October 2026
Changes
- 31 October 2026: How to contact the supplier about accessibility, and the reply time.
- 24 October 2026: Letters added to what may not be fully accessible.
- 22 October 2026: Checks run on every applicant and officer screen, at desktop and phone widths.
- 21 October 2026: First draft.
Supplier questionnaire: draft answers
Version
draft-2026-10-31
Last changed
31 October 2026
Changes
- 31 October 2026: The first sign-in answer names the optional claims council IT adds.
- 31 October 2026: The audit log answer describes the hash chain check.
- 30 October 2026: Officer sign-in, subject access, the full export and continuity answers updated.
- 28 October 2026: Changed-records export, transfers and audit retention answers added.
Full export format
Version
draft-2026-10-31
Last changed
31 October 2026
Changes
- 31 October 2026: allowGuestSignIn says how a guest is known.
- 31 October 2026: Audit events carry a hash chain; a reading step says how to check it. A revoked licence records any appeal against the revocation. Audit events record letters printed again for a new posting date.
- 30 October 2026: First draft, written from the product's own record types.
Product agreement
Version
draft-2026-10-31
Last changed
31 October 2026
Changes
- 31 October 2026: Section 7: the council can end the agreement over an unresolved sub-processor objection.
- 30 October 2026: Section 5: proposed availability and recovery figures.
- 25 October 2026: First draft.
Data processing agreement
Version
draft-2026-10-31
Last changed
31 October 2026
Changes
- 31 October 2026: Section 6: what a breach notice contains. Section 7: the right to end the agreement over an unresolved objection. Section 9: deletion within 30 days, confirmed in writing.
- 28 October 2026: Section 7: sub-processors, where data is processed and the transfer mechanisms.
- 25 October 2026: First draft.