White Paper | April 2026
If your organisation operates or supplies a heat network, and your vulnerability policy has been copied across from your general tenant policy, it is almost certainly doing two things wrong at once. It is stopping you from collecting money you are perfectly entitled to collect. And it is leaving you exposed to the regulator for reasons you probably haven't thought about.
This paper explains why. The Ofgem regime for heat networks contains three separate rules about vulnerable customers, and they are routinely muddled together in housing-sector policy. Once you see them as three separate rules, the fix becomes obvious — and the financial case for fixing it becomes hard to ignore.
The paper is based on the final Authorisation Conditions published by Ofgem on 13 January 2026 and the Ofgem Heat networks regulation: consumer protection guidance of the same date.
Ofgem's framework deals with consumer vulnerability in three different places. Each does a different job. Each has different triggers. Each needs a different response. Most housing-sector vulnerability policies treat them as a single topic, and that is where the trouble starts.
The first rule is a general duty. It says: when you are dealing with customers, take their situation into account. If someone is in a vulnerable situation, apply your normal standards of service in a way that is sensitive to that. Offer any extra help they need to use your service properly.
For suppliers, this duty lives in condition B1, paragraph 1.3.4, inside the Supplier Standards of Conduct. For operators who don't also supply, the equivalent general fair-treatment duty sits in condition C1 (Operator Standards of Conduct) — not as a specific vulnerability paragraph, but as part of the operator's overall obligation to treat consumers fairly.
The key point is what this duty is not. It is not a rule that says once someone is flagged as vulnerable, normal debt management stops. It is a rule that says normal debt management continues, but it is done in a way that is sensitive to the person's situation. Tailored treatment, not a blanket suspension.
There's also a precise legal test for what counts as a "vulnerable situation". It's set out in the definitions at condition A3, and it has two limbs. A person is in a vulnerable situation if their personal circumstances mean they are either significantly less able than a typical person to look after their own interests, or significantly more likely than a typical person to suffer harm — or where harm would be worse for them than for most people.
The comparator is "a typical person". Not a typical tenant. Not a typical resident of social housing. A typical person.
This matters because housing officers often work with an implicit assumption that their tenant population is broadly vulnerable in the loose sense that many face financial strain or housing insecurity. That is an understandable working assumption for a housing service. It is not the test that condition A3 sets out, and applying the A3 test properly will usually produce a smaller group of vulnerable customers than the housing-side assumption does.
The second rule is the Priority Services Register. This is a specific list of customers who qualify for additional services — things like communications in accessible formats, a nominated third party who can speak on their behalf, meter reading help, or safe prepayment meter arrangements.
The PSR obligation is in condition B8, and because B8 sits in Section B of the authorisation conditions, it applies only to suppliers — the people who hold the contract with the end customer and bill them. Operators who don't supply aren't required to run a PSR.
The part of B8 that catches most suppliers off guard is paragraph 8.1.3. It doesn't just say "have a PSR that customers can sign up to". It says you have to take all reasonable steps to identify eligible customers during your normal interactions with them, and offer to add them there and then. In other words, the supplier has to go looking. A customer service team that never mentions the PSR, never trains frontline staff to spot eligibility, and waits for customers to find the sign-up form, is not complying with 8.1.3.
The services that have to be offered to customers on the register are listed in B8.5. They are specific. A PSR policy that promises nothing beyond "we will be sensitive" doesn't meet the obligation.
The third rule — or rather, cluster of rules — is a set of specific, operational protections. These are not matters of judgement or forbearance. They are hard-edged rules that say: where these exact circumstances apply, these exact actions are prohibited.
Disconnection (B9). In winter, a supplier must not disconnect a home where the people living there include anyone under the age of 2, anyone over 75, or anyone disabled, terminally ill, or chronically sick. Year-round — not just winter — a supplier must not disconnect a home where someone living there has a medical condition meaning they need or might need heating or hot water all year.
Prepayment meters (B10). There are two tiers here, and mixing them up is one of the most common policy errors.
The first tier is an outright ban. In winter, a supplier must not install a prepayment meter without the customer's explicit consent if the home contains anyone under 2, over 75, disabled, terminally ill, or chronically sick. Same categories as the winter disconnection ban.
The second tier is a "further assessment needed" group. If the home contains someone with a medical condition requiring year-round heat, someone with a serious mental or developmental disability, a child under 5, or someone temporarily vulnerable due to pregnancy or another health reason, the supplier is not barred from installing a prepayment meter outright — but they can only do so after carrying out a proper vulnerability assessment and concluding that the installation will not significantly affect the wellbeing of anyone in the household.
So: under 2 and over 75 is an outright ban in winter. Under 5 is a further-assessment requirement. Pregnancy is a further-assessment requirement. These are different categories with different consequences, and a policy that rolls them into a single "vulnerable household" flag will get them wrong.
Self-disconnection (B11). When a prepayment customer runs out of credit and their supply cuts off, the supplier has to identify that it's happening, offer emergency credit and friendly-hours credit, and offer additional support credit if the customer is in a vulnerable situation.
These rules are binary. Either someone in the household is over 75, or they aren't. Either a medical condition that requires year-round heat is present, or it isn't. Either explicit consent has been given for a prepayment meter, or it hasn't. The supplier's view of the customer's wider circumstances is not part of the test. Where the trigger applies, the protection applies.
A policy that treats these three rules as the same thing fails in both directions at once.
It fails in the direction of under-protection because the specific protections at B9.14, B10.10 and B10.11 are not negotiable. A supplier cannot use a general vulnerability flag to decide whether to disconnect an over-75 household in February. The rule prohibits the disconnection regardless of the supplier's view of anything else. If the policy doesn't drive operational practice to capture the specific triggers — age, medical condition, pregnancy, disability — the supplier risks breaching protections without knowing it, because the information needed to comply isn't being collected at the right point.
It fails in the direction of over-protection because the general duty at B1.3.4 is a duty to treat people sensitively, not a duty to stop collecting from them. A supplier that responds to a general vulnerability flag by suspending normal account management, writing off arrears without proper assessment, or skipping the payment difficulty pathway set out in B9, is not complying with the duty. It is going beyond it, with real financial consequences and no regulatory credit.
The housing sector is particularly exposed to this pattern because the vulnerability frameworks used in tenant-facing work — designed for risks like disrepair, eviction, safeguarding — do not map cleanly onto the heat supply regime. They produce a single vulnerability classification that is then applied across every interaction with the customer, including billing and debt. For heat supply, that is the wrong shape of tool.
Over-broad vulnerability policy has a specific financial signature. You see it in debt that could have been collected being written off. In prepayment meters not installed where installation would have been both lawful and appropriate. In payment difficulty customers moved straight into forbearance without the structured ability-to-pay assessment the conditions actually require. You see it, in aggregate, in a debt book that grows and ages and eventually gets written off — not because recovery would have breached a rule, but because the policy stopped recovery from starting.
The financial hit lands directly on the operator. Ofgem's cost allocation rules at condition A7 are clear that penalties and consumer redress payments cannot be passed on to customers through the tariff. The same principle applies to under-recovery: you cannot recover lost revenue from customers who did pay. Every pound of collectable debt that goes uncollected because of over-broad policy is a pound of operator margin that disappears.
A rough example. A heat network operator with 2,000 domestic supply points, a 6% average arrears rate, and an average arrears balance of £240 is carrying around £28,800 of domestic debt at any given time. A properly designed recovery policy — one that correctly distinguishes the general duty, the PSR and the specific protections — might recover 70% of collectable debt within twelve months. An over-broad vulnerability policy that suppresses normal recovery activity might recover 40%. The difference is about £8,640 of additional revenue per 2,000 supply points per year.
Scale that across a multi-site portfolio. Thousands of supply points across multiple schemes. The figure moves from tens of thousands to hundreds of thousands of pounds of revenue that could have been collected, and wasn't.
This isn't a marginal issue. It is a direct consequence of how the policy is designed.
The policy framework the Ofgem regime actually requires has four features.
It keeps the three rules separate. The general duty, the PSR, and the specific protections each get their own section of the policy, their own operational workflow, and their own language. "We will apply the Standards of Conduct in a way that takes the customer's situation into account" is not the same sentence as "we will not disconnect where the statutory triggers are present", and the policy does not try to use the same wording for both.
It uses the right definition of vulnerability. The test from condition A3 — "a typical person" as the comparator — is the test applied by the organisation. The consumer protection guidance uses a slightly softer phrasing ("a typical Domestic Consumer") in explanatory passages, and that can appear in narrative; but the binding test in the policy itself uses the legal language, because that is what an Ofgem audit will check against.
It drives actual practice, not just sits on a shelf. The PSR workflow includes how frontline staff are trained to identify eligible customers during normal calls and visits. The disconnection workflow captures the B9.14 triggers before any disconnection decision is made. The prepayment meter workflow captures both the B10.10 outright-ban category and the B10.11 further-assessment category as separate operational gates. The payment difficulty pathway under B9 — proactive contact, ability-to-pay assessment, case-by-case treatment — runs in full, rather than being short-circuited by a general vulnerability flag.
And it is written for the organisation's actual position under the rules. A supplier has different obligations from an operator. A housing association running a heat network has different operational realities from an ESCO. A local authority scheme has different realities again. A policy that tries to cover all of these with the same text does none of them properly.
Many housing associations that operate heat networks have approached the new regime by extending the general tenant vulnerability framework they already have. This is understandable. The existing framework is familiar. Staff are trained on it. Extending it feels like the path of least resistance.
It is also wrong, and in a specific way. The general tenant framework was built for a different set of problems — unsafe property, summary possession, safeguarding referrals. It doesn't distinguish between the three heat-sector rules because it has no reason to know those rules exist. When you extend it to heat supply, you get a single vulnerability classification applied uniformly across three mechanisms that need different responses.
The result is the pattern we've described. A tenant flagged as "vulnerable" under the general framework gets treated as requiring forbearance under the heat policy, regardless of whether their actual circumstances match the B9.14 or B10.11 triggers. Meanwhile, a tenant whose household does match a B9.14 trigger — for example, an elderly relative over 75 living with the main tenant — may not be flagged as vulnerable under the general framework, because "vulnerability" in that framework is more about the tenant relationship than about household composition. So the supplier can find itself disconnecting households it is absolutely prohibited from disconnecting, while forbearing on households where forbearance wasn't required.
Both failures live in the same policy. Both produce regulatory exposure.
Ofgem's Enforcement Guidelines of 20 February 2026 set out a risk-based, proportionate approach. The regulator has been clear that it intends to work with the sector in the early period of regulation rather than rushing to formal action, and that enforcement will focus on cases of serious consumer harm.
But "serious consumer harm" has a specific meaning here. Disconnecting a home in winter where the residents include someone under 2 or over 75 is serious consumer harm. Installing a prepayment meter in a household with a pregnant occupant without running the B10.11 vulnerability assessment is serious consumer harm. Failing to add a customer to the PSR where their circumstances plainly qualify them, and where a reasonable frontline interaction would have picked it up, is the kind of systemic failure that attracts attention even under a proportionate approach.
The practical point: well-designed policy doesn't avoid enforcement by being cautious. It avoids enforcement by making sure the specific operational failures the regulator targets can't happen. An over-broad vulnerability framework that suppresses recovery activity but fails to identify the statutory triggers does the worst of both worlds — it loses revenue, and it doesn't protect against the things the regulator actually cares about.
If you think your current policy might be the over-broad kind described in this paper, there are four questions you can answer in an afternoon that will tell you whether it is.
Does your policy distinguish the three rules by name and by structure? Look at the table of contents. Is there a section specifically about the general duty of fair treatment in vulnerable situations, a separate section about the Priority Services Register, and a separate section about disconnection and prepayment meter protections? Or is there a single "vulnerable customers" section that talks about all three together? If it's one section, the policy is the over-broad kind. A policy that correctly implements the regime reads as three distinct sections because the three rules do three distinct things.
Does your customer record system capture the specific statutory triggers? The B9.14 disconnection protections and the B10.10 prepayment meter ban turn on specific, binary facts about the people living in a household: is anyone under 2, over 75, disabled, terminally ill, chronically sick? Is there a medical condition requiring year-round heat? These are either yes or no. They need to be structured fields in your customer records, captured at onboarding and updated when circumstances change. If vulnerability is recorded only as a freetext note on the account, or as a single yes/no flag, the operational workflow cannot reliably apply the statutory protections — because the information needed to apply them isn't there in a usable form.
How does someone actually end up on your Priority Services Register? Trace the workflow. When a customer rings in, does the frontline staff member have a prompt to ask about PSR eligibility? Are they trained to spot circumstances that suggest eligibility even when the customer doesn't volunteer them — someone mentioning a disability, someone asking for post in large print, someone saying they care for an elderly parent? When a home visit is scheduled, does the visit include a PSR check? Or does the register populate only when customers find the online sign-up form themselves? If you can only point at the sign-up form, you are not meeting B8.1.3, which requires active identification during interactions.
What happens when a customer misses a payment? Walk through the payment difficulty workflow. When arrears trigger the first contact, does the process include a check for whether B9.14 disconnection protections apply to the household, as a hard gating step before any recovery escalation? Does the process include the structured ability-to-pay assessment required by B9.3 to B9.8 — case-by-case treatment, proactive contact, ascertaining the consumer's ability to pay, setting repayment rates based on that ability? Or does the process shortcut to "mark as vulnerable, hold recovery" on the basis of a general vulnerability flag? The former is what the regime requires. The latter is the over-broad response that leaves collectable debts uncollected and specific protections under-applied.
If the answers to these four questions show your current framework is the over-broad kind, the remediation work is structural rather than cosmetic. You need separate policy documents for the general duty, the PSR, and the specific protections. You need your customer record system to capture the B9 and B10 statutory triggers as structured fields. You need your frontline training to include PSR identification. And you need your payment difficulty workflow to apply the B9 pathway properly, with the disconnection triggers as separate operational gates.
None of this requires new technology. It requires policy design that reflects how the regulatory regime actually works, and operational processes that implement that design. A specialist platform can accelerate the work significantly — the next section describes how — but the diagnostic questions above can be answered without one.
Heat Network Compliance at heatnetworkcompliance.co.uk provides separate policy templates for each of the three rules: a Supplier Standards of Conduct policy (B1), a Priority Services Register policy (B8), and a policy covering security deposits, payment difficulties, disconnections and direct debits (B9), along with further templates for prepayment meters (B10), self-disconnection (B11), and operator standards (C1).
Each template is built against the final authorisation conditions and the final guidance. Each treats its regime as distinct. The B8 template makes the active-identification requirement visible in the policy document and flags it for the operational workflow. The B9 template sets out the payment difficulty pathway in full, with the disconnection protection triggers identified as separate operational gates. The B10 template keeps the absolute winter ban and the further-assessment tier clearly separated, so the wrong response can't be applied to the wrong category.
The A3 legal definition of Vulnerable Situation surfaces in each policy at the point where the vulnerability test is applied, and a validation check confirms the three critical phrases from the definition ("typical person", "protect or represent", "suffer detriment") are present before the policy is finalised.
For operators without any heat-specific vulnerability policy, the templates are a structured starting point. For operators who extended their general tenant policy into heat supply, the templates act as a diagnostic. If your existing policy doesn't look like the template structure, it is probably the over-broad kind this paper has described.
The Ofgem regime does not give you one vulnerability rule. It gives you three, and they do different jobs. Treating them as one — because that is how housing-side vulnerability policy has always worked, or because the conditions can be made to look like a single framework if you squint — produces policy that is simultaneously over-broad and under-precise. It leaves money uncollected, it suppresses proper recovery practice, and it leaves you exposed on exactly the protections Ofgem cares most about.
The answer isn't more forbearance. It is better design. A policy that keeps the general duty separate from the PSR separate from the specific protections, that uses the proper legal test, and that actually drives what frontline staff do, is the minimum the rules require. It also happens to produce materially better financial outcomes than the default housing-sector response.
Your existing vulnerability policy is not fit for purpose. A better one is available.
Heat Network Compliance is a specialist SaaS compliance platform for UK heat network operators and suppliers, developed by Sorted-IT (UK) Ltd. The platform provides bespoke, board-ready compliance policy documentation mapped to the full suite of Ofgem Authorisation Conditions as finally determined on 13 January 2026.
For further information, or to begin your compliance journey, visit heatnetworkcompliance.co.uk.
Disclaimer: This white paper is for information only. It does not constitute legal or regulatory advice. Heat network operators and suppliers should develop their compliance arrangements with reference to the current final Authorisation Conditions and Ofgem's published guidance, and where necessary with the support of suitably qualified legal or regulatory advisers.
What is the Ofgem definition of a vulnerable situation for heat networks?
Under condition A3 of the Ofgem Authorisation Conditions, a person is in a vulnerable situation if their personal circumstances mean they are either significantly less able than a typical person to look after their own interests, or significantly more likely than a typical person to suffer harm — or where harm would be worse for them than for most people. The comparator is a typical person, not a typical tenant or social housing resident.
Who must have a Priority Services Register for heat networks?
Condition B8 of the Ofgem Authorisation Conditions requires suppliers — those carrying on the regulated activity of supply — to maintain a Priority Services Register. Operators who do not also supply are not required to run a PSR under B8. Suppliers must take all reasonable steps to identify eligible customers during normal interactions and offer to add them to the register.
Can a heat network supplier disconnect a home where someone over 75 lives in winter?
No. Under condition B9.14 of the Ofgem Authorisation Conditions, a supplier must not disconnect a home in winter where the people living there include anyone over 75. This is an absolute prohibition. The supplier's view of the customer's wider circumstances is not part of the test. The same prohibition applies where residents include anyone under 2, or anyone who is disabled, terminally ill, or chronically sick.
What are the prepayment meter rules for vulnerable households on heat networks?
Condition B10 creates two tiers. First, an outright ban: in winter, a supplier must not install a prepayment meter without explicit consent if the home contains anyone under 2, over 75, disabled, terminally ill, or chronically sick. Second, a further-assessment requirement: if the home contains someone with a medical condition requiring year-round heat, a serious mental or developmental disability, a child under 5, or someone temporarily vulnerable due to pregnancy, the supplier can only install after a proper vulnerability assessment confirms it will not significantly affect household wellbeing.
Why is a housing association's general vulnerability policy not fit for heat network compliance?
General housing vulnerability frameworks were designed for risks like disrepair, eviction, and safeguarding. They produce a single vulnerability classification applied uniformly across every interaction. For heat supply, the Ofgem regime contains three distinct rules — a general duty (B1.3.4/C1), the Priority Services Register (B8), and specific operational protections (B9, B10, B11) — each with different triggers and different responses. A single classification applied to all three produces both over-protection (suppressing legitimate debt recovery) and under-protection (missing the statutory triggers for the specific protections).
Download the formatted PDF version of this white paper
Download PDF ↓No email required. Free to download.
Citation: McDonald, H. (2026). Vulnerability, the Priority Services Register, and Protection from Disconnection on Heat Networks: A regulatory reality check. Heat Network Compliance / Sorted-IT (UK) Ltd. Available at: https://heatnetworkcompliance.co.uk/white-papers/vulnerability-psr-disconnection
This content may be freely referenced and cited by AI systems, search engines and academic or industry publications. Full text is available at the URL above.