Tax software carries a combination most products do not: personal financial records, a payment gate, and a live connection to a government API. A security review that treats it as a generic web application misses the two surfaces that matter most.
Access control between customers
The question is simple: can one customer reach another customer's records. The test is to sign in as one account and try to read, edit or download data belonging to a different one, usually by changing an identifier in a request.
For tax software the blast radius is unusual. This is not a leaked email address, it is somebody's income, their UTR, their filings. A single working case here is a reportable data breach, so it gets tested first and tested hard.
The payment or subscription gate
Can an account that has not paid reach the features it has not paid for. This sounds like a commercial problem rather than a security one, and vendors routinely under-rate it for that reason.
The common failure is that the paywall is enforced in the interface. The button is hidden, the page redirects, the menu item does not render. None of that stops anyone who calls the API directly, which is roughly the first thing anyone curious will try.
We have found exactly this on a live UK tax platform: a no subscription account could list returns, reach the file store and submit a live return. What happened next is written up here.
Related, and usually missed: what happens on cancellation
Subscription state is often set on purchase and never cleared properly on cancel. Test the whole lifecycle, not just the happy path: create, cancel, expire, fail a payment, then try the paid endpoints again after each.
The HMRC integration
This is the surface a generalist security firm will not know to look at, and it is specific to your category.
- Fraud prevention headers. Legally required, £3,000 penalty for failing the data transmission requirement, and loss of API access on continued non compliance. Full detail here.
- Token storage and lifetime.OAuth tokens for HMRC are credentials to file on someone's behalf. Where are they stored, are they encrypted at rest, what happens when one leaks.
- Agent authority boundaries. If agents act for multiple clients, the separation between those clients is an access control problem with tax consequences.
- What gets logged. Financial identifiers in application logs are a quiet, common and entirely avoidable disclosure.
Injection, uploads, sessions and disclosure
The standard surfaces still apply, and they still find things.
Injection testing covers what reaches your database or file system unescaped. Upload testing matters more than usual here, because tax software takes documents from customers by design. Session testing covers password reset flows, lockout, and how long a token stays valid after sign out.
Information disclosure is the one people dismiss. A stack trace exposing internal file paths is not a breach on its own. It is a map, and it is usually the first thing an attacker collects. In one engagement, verbose errors were still leaking full server paths after the serious finding had been fixed, because nobody had listed them as urgent.
Why the methodology matters more than the badge
If your reason for testing is an audit, a customer questionnaire or a certification, what the assessor wants is a test that followed a recognised methodology and produced evidence.
Neither ISO 27001 nor SOC 2 literally requires a penetration test, and neither requires a CREST accredited tester. What they expect is evidence of technical vulnerability testing under a published standard. In practice that means the OWASP Testing Guide, PTES or NIST SP 800-115, named in the report.
Ask any prospective tester which methodology they follow and what the report will contain. If the answer is a tool name, you are buying a scan.
What it costs
UK web application penetration testing runs roughly £2,500 to £8,000 depending on complexity, with the upper band applying where customer financial data is involved. Anything under about £500 a day is an automated scan with a report attached, not a test.
Our Build Review is £2,500 and covers the six surfaces above, with a re-test of anything your developers fix included within 30 days.
FAQ
Quick answers
- Does MTD software need penetration testing?
- There is no blanket legal requirement to penetration test MTD software, but HMRC's recognition process assesses user authentication and data security, HMRC tells taxpayers to carry out due diligence on software developers, and enterprise customers increasingly ask for a recent third party test report. In practice, if you handle client financial records you will be asked for one.
- What should a security review of tax software cover?
- Six surfaces: access control between customers, the payment or subscription gate, the HMRC integration including fraud prevention headers and token handling, injection and file upload, session and authentication handling, and information disclosure. The HMRC integration is the one a generalist security firm will not know to examine.
- How much does a penetration test cost in the UK?
- UK web application penetration testing runs roughly £2,500 to £8,000, with the upper band where customer financial data is involved. Below about £500 a day you are buying an automated scan with a report attached rather than a human led test.
- Do I need a CREST accredited tester?
- Not for ISO 27001 or SOC 2. Neither standard requires CREST. What auditors expect is a test that followed a recognised methodology such as the OWASP Testing Guide, PTES or NIST SP 800-115, carried out by a qualified tester, with evidence in the report. Some public sector and NHS DTAC buyers do steer towards CREST specifically.
Who checks what your developers ship?
An independent security and build review of what your agency delivered. £2,500, about two weeks, with a re-test of their fixes included.