Security and governance for council data

Checked against the deployed code on 20 September 2026.

boroughlets.com/security

At a glance

Area	What is in place
Hosting	Amazon Web Services, London region (eu-west-2). Each council's household and casework data is held in its own environment, not shared with any other council. The catalogue of public listings is shared.
Access	Named accounts, created by an administrator. No self registration, and no public access to any data.
Authentication	Multi factor authentication is mandatory and cannot be turned off for an individual. Passwords are at least twelve characters, with upper case, lower case, numeric and special characters.
Authorisation	Two roles, caseworker and administrator. Administrator only functions are checked again in the back end, not merely hidden in the interface. Household records are visible to every signed in user of your council: the platform does not restrict a caseworker to their own cases.
Encryption	AES-256 at rest, TLS 1.2 or higher in transit. Call recordings use a key created for that purpose alone, with rotation switched on. The databases use keys AWS manages, so rotation there runs to AWS's schedule rather than ours.
Audit	An audit trail the platform can only add to: the only database permission any part of the system holds on it is "add an entry". It covers placements, bulk imports and credential reveals. It does not yet cover edits to household fields.
Retention	Deleting a household archives it: it leaves every caseworker view and an administrator can restore it. Permanent erasure is a manual procedure we carry out on your written instruction, not an automatic expiry. Property listings expire automatically after 90 days.
Supplier access	Three administrative functions in your environment can be reached from our support portal: user management, catalogue maintenance and the feedback inbox. The function that reads household records is not one of them. Set out in full below.
Alignment	Controls are mapped to the NCSC Cyber Essentials themes, UK GDPR security obligations and ISO 27001 principles. No certification is held yet; ask us for the current position.

Access and identity

Access is restricted to named, administrator provisioned accounts. There is no self registration and no public access to any data. Multi factor authentication uses a software token from any authenticator app and cannot be switched off for one user. A failed sign in does not reveal whether the account exists.

There are two roles. Caseworkers work on their council's caseload. Administrators additionally manage users, settings and the dashboard, and those functions are checked in the back end as well as hidden in the interface, so the check is not something a browser can be talked out of. Worth knowing before you plan around it: within a council, household records are visible to every signed in user. The platform does not confine a caseworker to their own cases.

What our own staff can reach

You should assume that the supplier of any hosted system can reach the data in it, and ask what stops that being casual. This is the section we would read first.

Your data sits in an AWS account that is yours in everything but the invoice. We operate a support portal from a separate account of our own. From it, a BoroughLets operator can reach exactly three functions inside your environment: user management, catalogue maintenance, and the feature and bug inbox. Those three are named one by one in the permission that grants the access. The function that reads and writes household records was deliberately left off that list, so there is no direct route from our portal into a household record.

That is a real boundary and it is not a complete one. User management can create a user and place them in the administrator group, and an administrator can see households. So an operator who set out to reach household data could give themselves an account that does. The honest description is that the route is longer and noisier than a direct one, not that it is closed.

What that route leaves behind today is an entry in your own account's logs carrying the email address of the person who did it. What it does not leave behind is an entry in the audit trail you can see inside the platform, and we have not yet switched on the account level record of administrative actions that an auditor would normally ask for. Both are in the list of gaps below.

Three undertakings we would rather give you in the contract than on a web page: we will not create an account in your environment except at your written request; every account that exists for us is a named individual and never a shared login; and you may ask at any time for a list of every account in your environment and who created it.

How AI is used, and its limits

The platform is a decision support tool for trained caseworkers, built around the Local Housing Allowance search and the placement record. It does not make automated decisions about people. AI assists with search and drafting; the caseworker makes every consequential decision.

A plain English search is read by the AI into filters, and then runs. The filters it derived come back with the results and are loaded into the search form, so the caseworker can see exactly how the request was read, change any part of it and search again. The filters are visible after the search, not before it.

Registering a household by describing them, in text or by voice, uses AI to fill in the form. Nothing is saved until the caseworker checks the details and presses Create. That is not a screen that could be skipped: the function that talks to the AI returns a proposal marked as incomplete, and it holds no permission to write to the household database at all. Called directly, it could not create a household.

Outbound calls are recorded. The announcement the platform plays at the start of a call is played to the caseworker, so today the family is told by the caseworker, who is instructed to say that the call is being recorded before the conversation begins. An automatic announcement to the called party is a build item, and we will not describe it as in place until you have heard it on a test call with you on the line.

An AI drafted call summary is a draft until a person signs it. Only the caseworker who made the call can confirm it. Once confirmed, an attempt to overwrite it is refused by a condition checked inside the database write itself rather than by application code, and any later edit is rejected. The AI's original wording is kept alongside the confirmed version, so a manager can see what was changed.

AI is not used to score, rank or assess applicants. Bedroom need and affordability are rule based and explainable from published rates, with no model involved.

Nothing the AI writes reaches a household record until a person signs it off.

This is not a setting that can be turned off. It is how the feature is built.

What goes to the AI, and what does not

Every AI call in the product goes to a model running as an AWS service in the London region, and the inputs and outputs are not used to train it. Here is precisely what each feature sends.

Feature	What is sent	What is not sent
Plain English property search	The words the caseworker typed. When a household is open: that household's name, its assessed bedroom need, its monthly affordability figure, its home borough, and the yes or no property requirements on its record (ground floor, wheelchair access, garden, parking, pets, and whether a house share is an option).	Date of birth, address, contact details, National Insurance or NHS number, benefit details, free text from the record, and any medical or safeguarding detail beyond the access requirements listed.
Registering a household by description	Everything the caseworker types or dictates in that conversation, which by design includes the family name, the main contact's details, the household composition and anything else mentioned, such as a medical need.	Nothing is withheld, because the caseworker is dictating the record itself. What the model cannot do is save it.
Call summary after a call	The transcript of the call and the household's name.	The recording never leaves your AWS account. Transcription and drafting both run on AWS services inside it, in London.

Two of those search requirements, ground floor and wheelchair access, tell the model something about a person's health, so we describe them as what they are rather than as non-identifying flags.

AWS's service terms commit, in section 50, that what is sent to the model service and what it returns are not used to train any model and are not shared with the model's provider, and that prompts are not kept after the call returns. That is a term of the service, not a checkbox we set and could unset. We hold no account with any AI company, so there is no route by which your data reaches one.

Audit and oversight

The audit trail is append only in the strongest sense available: the only permission any part of the platform holds on that table is "add an entry". There is no update and no delete, in the code or in the permissions that would allow one, so there is nothing for an administrator to switch off. The table cannot be dropped without deliberately removing a protection first, and it can be restored to any second in the previous thirty five days.

Three families of event are written to it today. Every step of a placement, from reserved to move in, with the person and the time. Every bulk import, including a rollback. And every occasion on which an administrator reveals a user's temporary credential, with the email address and the source address of whoever revealed it.

Edits to the fields of a household record are not written to it. The record carries the time it was last changed, and calls, emails, imports and placement steps each carry the person who performed them, but a field level history of who changed which field is not something we can give you today. It is the first item in what we do not do yet.

Separately from the audit trail, managers can see every confirmed call: who made it, to which household, how long it lasted and the summary they signed off. Imports are previewed against the existing caseload, validated row by row and confirmed before anything is written, and an import can be rolled back, which removes the records it created.

Retention and deletion

Household records are kept for as long as the council instructs. Deleting a household in the platform archives it: it disappears from every caseworker view, is stamped with who deleted it and when, and an administrator can restore it. It is not erased from the database by that action, and the household's call log and email history are deliberately kept, because they are the record of what the council did.

Permanent erasure, at the end of a contract or on your instruction, is a manual procedure we carry out and record. There is no automatic retention clock on household data, and we would rather tell you that than let you assume one is running. Property listings, which are public advertisements and not personal data, do expire automatically after 90 days.

Answering a request from a resident

A request from a data subject is answered by the council as controller. A household's details, its placements, its calls with their confirmed summaries, and its email history are all reachable from that household's page, which is where a caseworker would assemble the answer.

Two things to plan around. Audit entries are stored by month rather than under the household, so producing every audit entry relating to one household is a job we do for you inside your deadline rather than a button you press. And the platform has no export: there is no download for a single household and none for the whole caseload. A request is answered from the screen, or by asking us.

Controller, processor and everyone else involved

The council is the data controller. It decides why the data is held and what is done with it, and a resident exercises their rights against the council. BoroughLets is the processor and acts on the council's written instructions and on nothing else. We support your data protection impact assessment, and an information sharing agreement is signed before any live data is loaded.

A university partner is involved, and its role is easy to describe loosely, so here it is plainly. The platform was built inside a research collaboration with a university, and under the information sharing agreement for the pilot the university is a party to the processing rather than an observer of it. One named individual there holds access to the live environment, and that person is named in the agreement. Their role is platform administration, support and continuity, not casework. If you would rather that access did not exist, raise it before signing: it is a term of the agreement rather than a property of the software.

Amazon Web Services is our only sub-processor. It is named in the information sharing agreement, and everything it does happens in the London region: hosting, the databases, file storage, outbound email, the transcription of calls, and the model that drafts a summary or reads a plain English search. Two services outside AWS receive something, and neither receives anything about a household. A mapping service receives a property's address or coordinates so that a travel time can be worked out. The property listing sites receive search parameters: a borough, a bedroom count, a price ceiling. Nothing that identifies a family leaves your environment for either of them.

If we become aware of a personal data breach we will tell your data protection officer within 24 hours, in writing, with what we know at the time rather than waiting until we know everything. That commitment is in the information sharing agreement, and the 24 hours exists so that your own 72 hour duty to the Information Commissioner begins with two thirds of the clock still to run.

We do not yet hold a record of processing under Article 30 in our own name. What exists today is a data protection impact assessment pack, an information sharing agreement, a resident facing privacy notice, a security overview and this page. Our record of processing will be written from the agreement's schedules before the pilot handles live casework, and you are welcome to see the draft.

Continuity, and how a change reaches the live service

The platform runs on Amazon Web Services in the London region, on managed services that are spread across more than one availability zone by design. Call transcription and the drafting of call summaries use AWS services in the same region. Data is backed up continuously with point in time recovery.

One branch is the source of truth. Every change reaches it through a pull request that another person reviews. Each change is tested in our own environments before it reaches a council, and a named reviewer must approve every release into a council's environments. Every deployment is recorded against its commit, so the question "what exactly is running, and who approved it" has a dated answer rather than an assurance.

What we do not do yet

We would rather you found these here than in a penetration test.

A field level history of household edits. Placements, imports and credential reveals are written to the audit trail. A change to a household's fields is not.
An automatic recorded call announcement to the family. Today the announcement plays to the caseworker, so telling the family is a procedure we ask caseworkers to follow, not a control the system enforces.
An export. There is no download for a household and none for the caseload. Import exists. Export does not.
An automatic retention clock. Household records do not expire. Erasure is a manual procedure.
The account level record of administrative actions. Our logs record who invoked what, which is not the same thing, and the account level trail is not switched on.
A record of processing under Article 30 in our own name.
A certification. We map our controls to the Cyber Essentials themes and to ISO 27001 principles. We hold neither certificate, and a mapping is not a certificate.
Customer managed encryption keys on the databases. The call recording key is ours and rotates. The database keys are AWS's. If your policy requires otherwise, that is a configuration change rather than a redesign.

Ask us for the dated position on any of these and we will put it in writing.

Questions we are asked most

Can your staff read our households?

Not from our support portal directly: the function that reads household records is not one of the three it can reach. An operator could create themselves an account that can, which would appear in your own account's logs but not in the platform's audit trail. The full position is set out above.

What happens to our data if we leave?

We agree a date, you tell us in writing what to erase, we carry it out as a recorded manual procedure and confirm what was done. There is no automatic expiry and no self service export today, so if you need the data out, ask and we will produce it.

Does your AI train on our residents' data?

No. The model runs as an AWS service in London, and AWS's service terms commit that inputs and outputs are not used for training and are not shared with the model's provider. We hold no account with any AI company.

Is the platform itself accessible?

This website is tested and has an accessibility statement. The platform behind the login does not have one yet, and we would rather say so than imply otherwise. Accessibility of the platform is an active commitment for the pilot, not a completed piece of work.

Documents we can send you

We hold a security overview, a framework covering safety, ethics and governance, a data protection impact assessment pack, an information sharing agreement template, and a resident facing privacy notice. Ask and we will send whichever of those you need.

Security and governance for council housing data