The PCI compliance gap hiding in your council's payment channels

Often organisations assume their PCI DSS compliance is settled once the highest level of accreditation has been achieved somewhere in the organisation. In practice, PCI DSS compliance for local government is rarely a single achievement. It is a standard that has to hold consistently across every channel a council takes card payments through, and gaps tend to build up quietly in the channels nobody is looking at closely.


Why one accredited system does not mean the whole council is covered


A council might process council tax payments through a fully PCI Level 1 accredited system, while a separate leisure centre booking platform, a parking permit portal added later, or a call centre process built up informally over several years, sit outside that same level of scrutiny. Each of these channels handles card data. Each of them is, technically, within scope of the same compliance obligation. But because they were built, procured, or adopted at different times by different departments, they are rarely assessed as a single, consistent picture.


This is how compliance gaps can actually form in most councils. Not through negligence, but through growth. A new payment channel gets added to meet a specific service need, and the security review that should accompany it gets deprioritised, delayed, or simply missed, because nobody owns the full picture across departments.


Where these gaps typically hide


In our work with local authorities, the same patterns come up repeatedly as the places where compliance quietly slips.


  • Payment channels added incrementally over time by different departments, without a consistent security review across all of them
  • Staff taking card details over the phone and entering them manually into a payments system, which can expose card data outside any secure, encrypted environment and brings the entire organisation into scope for PCI DSS, not just the team handling the call
  • Not securing payment receipts that may contain sensitive data
  • Unsecured payment details a customer may send over, such as a screenshot or a photograph of a card
  • Staff not fully understanding what compliance actually requires, or assuming it is already covered, something that often only comes to light during a formal PCI assessment


Where phone payments are involved, the process of taking the call and the process of entering card details into a payment system need to be kept properly segregated. If the same environment that handles the call also has unrestricted access to enter and store card data, that link is often enough to bring systems that would otherwise sit outside PCI DSS back into scope.


A related and increasingly common gap is the assumption that a third-party supplier's own PCI compliance covers the council as well. Councils typically rely on several suppliers across a single payment journey, a payment provider, a contact centre platform, an income management system, and often an outsourced service on top. It is easy for this to become "our supplier is PCI compliant, therefore we are," but that is not how the standard works. The council remains responsible for its own PCI DSS obligations regardless of what any individual supplier holds. Every interface between systems, and every business process that touches card data along the way, still needs to be considered in its own right. Shared responsibility is one of the most commonly misunderstood parts of PCI DSS, and it is rarely tested until an assessment, or an incident, forces the question.


Any one of these can undermine an otherwise well-managed compliance programme, because PCI DSS assesses the full chain of custody for card data, not just the primary payment system a council points to when asked about compliance.



The scale of the problem


This is not a theoretical risk. UK Finance's 2026 Annual Fraud Report recorded £1.28 billion in payment fraud losses across the UK in 2025, with remote purchase card fraud, the category that covers stolen card details used online, by phone, or by mail order, rising 13% to £423.5 million. Councils sit directly in this category through their online and phone payment channels.


The cost of a breach itself is significant too. Ponemon Institute research for IBM put the average cost of a UK data breach at £3.29 million in 2025, and separately found that public sector organisations took an average of 202 days to identify that a breach had even occurred. That detection gap matters here specifically: a compliance gap sitting quietly in an overlooked payment channel is exactly the kind of issue that goes unnoticed for months rather than days.


Why this matters more for councils than most organisations


Councils handle a wider range of payment types across a wider range of channels than most organisations of comparable size, often supported by legacy systems that were never designed to talk to one another. Each additional channel is another point where card data can be exposed if it is not properly managed, and each additional department is another team that may not realise their local process carries compliance risk for the organisation as a whole. For councils managing income across multiple departments, this is rarely a single team's problem to solve alone.


Public accountability raises the stakes further. A council that experiences a payment data breach faces scrutiny many private organisations do not, including local media coverage, resident complaints, and formal reporting obligations to the Information Commissioner's Office. The financial exposure is also real: non-compliance can result in increased transaction fees from card schemes, remediation costs, and in serious cases, the loss of the ability to accept card payments at all until compliance is restored.



The added risk for councils forming new unitary authorities


Local Government Reorganisation adds a further layer to this. Across England, two-tier county and district councils are being replaced by new unitary authorities, with decisions already confirmed for a large number of areas and most new councils set to formally launch on Vesting Day in April 2028, with Surrey a year ahead of that timeline. Each predecessor council brings its own payment systems, its own suppliers, and its own PCI accreditation status into the new organisation, often accumulated over many years and rarely built with a merger in mind.


This creates a compressed version of the same problem this article has been describing, but on a much shorter timescale. Instead of gaps forming gradually as one council adds channels over several years, a new unitary authority can inherit several councils' worth of channels, suppliers, and accreditation gaps all at once, at the exact moment its finance and IT teams are already stretched by the wider transition. Councils approaching reorganisation would do well to treat payment channel and supplier consolidation as its own workstream, rather than something to be resolved informally once the new authority is already live.

 


Closing the gap without a department-by-department audit


The most reliable way to close these gaps is to reduce the number of places where card data is taken, and the number of places it can go once it has been, rather than trying to audit every department's payment process individually and hope nothing has been missed since. This is also where it helps to audit your processes before an official audit does it for you. Adelante's professional services team can help you carry out a review of your current payment processes to understand where the cracks and gaps might sit, and whether there is scope to streamline or simplify what is already in place, well before that picture is tested by an assessor.


A centralised income management platform brings payment channels, whether online, by phone, or in person, into a single PCI Level 1 accredited environment, removing the need for manual handling or duplicate storage of card details anywhere in the organisation. Compliance becomes a property of how payments are collected, rather than something to be assembled and defended separately at every audit cycle.


Adelante's SmartPay platform is built to this standard, currently supporting 38 local authorities and 2 universities, processing over 3.9 million transactions annually within a PCI Level 1 accredited environment. For finance and IT teams, this means new payment channels can be brought into the same accredited environment as they are added, rather than starting a fresh compliance project each time.


Next step


If your council's payment channels have grown organically across departments over several years, or are about to be brought together with others through local government reorganisation, it is worth understanding where the current gaps sit before the next audit, near-miss, or resident complaint finds them first.


Book a SmartPay demonstration to see how a single accredited platform closes these gaps across every channel your council uses to take payments.




Woman working at a desk on a computer with a large monitor showing spreadsheets in an office

Why manual reconciliation is costing council finance teams more than they realise

By Ned Lowe • July 27, 2026
Manual council income reconciliation costs far more than most finance teams recognise, particularly around month end, when transaction volumes are highest and reporting deadlines are closest together. Ask a council finance team how long reconciliation actually takes each month, and the answer is rarely a precise figure. It is usually something closer to “however long it needs to,” because the process tends to expand to fill whatever time is available. Where the time actually goes Reconciliation is often assumed to be a single task, but it is really several tasks stacked together. Bank statements are exported and reviewed line by line against income records. Payments are matched manually, one at a time, even though the majority of them are routine and unremarkable. Genuine exceptions, the handful of transactions that actually need investigation, are buried within a much larger volume of transactions that simply need confirming. This matters because the effort involved in reconciling a straightforward, correctly allocated payment is, in a manual process, almost identical to the effort involved in reconciling one that needs closer attention. Every transaction gets the same level of manual handling, regardless of whether it needs it. The risk sitting behind the time cost The time cost is the most visible problem, but it is not the only one. When reconciliation is manual and high-volume, errors, missed payments, and unusual transactions become harder to identify, simply because they are one line among many being reviewed at speed. A duplicate payment, a missed allocation, or an irregular transaction pattern can sit unnoticed for longer than it should, particularly during the periods when reconciliation is most rushed.  For councils managing income across multiple bank accounts and multiple services, this risk compounds. Each additional account is another full manual review, and each additional service is another set of transaction patterns that finance staff need to hold in mind while working through the detail. What automated matching actually changes The shift from manual to automated reconciliation is not about removing finance team oversight. It is about applying that oversight only where it is genuinely needed. Automated matching clears allocated payments in a single step, whether that is a straightforward one-to-one match or the more complex one-to-many, many-to-one, and many-to-many matching that real-world reconciliation regularly requires. What remains for the finance team to review is the smaller set of genuine exceptions, the transactions that actually warrant a closer look, rather than the full transaction volume. This changes reconciliation from a task defined by volume to one defined by exception. A month with ten thousand transactions and a month with one thousand transactions require a similar amount of finance team attention, because the review effort scales with the number of exceptions, not the number of transactions. What this looks like for a council finance team in practice ● A rolling balance is maintained per bank account, so finance teams can track position without a full manual reconciliation each time ● Reconciliation extends across every bank account a council holds, filtered by payment date or posted date as needed ● Notes can be added and items archived without affecting overall totals, keeping a clear working record without disrupting the wider reconciliation ● Standard reports are available and can be copied and tailored to a council’s own reporting process, rather than requiring a reporting structure to be built from scratch Why this does not require a new system One of the more common assumptions about reconciliation improvements is that they require replacing existing systems or migrating data, which is often reason enough for the improvement to be deprioritised. Bank Reconciliation , as a SmartPay module, works directly within the SmartPay income records already in place, using the same secure access finance teams already have. There is no new system to learn and no migration project to plan around, which means the time saved on reconciliation is not offset by a lengthy implementation process to get there. Next step If reconciliation is currently taking longer than it should, particularly at month end, or if visibility across multiple bank accounts has become harder to maintain as transaction volumes have grown, it is worth seeing how automated matching changes that balance in practice. Contact the SmartPay team to Arrange a short demonstration of the Bank Reconciliation module, using examples relevant to your own reconciliation process.
a man is standing in front of a van holding a cell phone .

How to successfully introduce new technology into your franchise business

February 20, 2024
Introducing new technology into a business with a mobile workforce requires more than just installing software. Here's Adelante's guide to implementing new software