Trust - 4 min read
How we keep your code and data secure
Handing a tool access to your source code and financial data is a real decision. How we connect to GitHub with scoped, short-lived access, how we separate each company's data, what we do and do not do with your code, and the insurance behind it.
Letting a tool read your source code and your cost data is not a small thing to ask, and you should not grant it lightly. This post sets out how we connect, how we keep each company's data separate, what we do and do not do with your code, and what stands behind all of it. If something here is a dealbreaker for your company, better to know now.
This describes our security approach. It is not a substitute for your own due diligence; ask us for specifics and we will answer them.
How we connect to your code
We connect through a per-company GitHub App installation, not by asking for your password or a personal access token. That matters for a few reasons:
- You choose the scope. The install is granted against the specific repositories you select, not your whole account. You can change or revoke it from GitHub at any time, on your side, without going through us.
- Access is short-lived. The App uses short-lived tokens rather than a long-standing key sitting in our systems. The standing secret is the installation grant you control, which you can withdraw.
- We read, we do not write. We need to read your history to find and substantiate R&D. We are not making changes to your repositories.
What we actually do with your code
We read your pull requests and their metadata (or your commit history, for repos that do not use pull requests) to surface candidate R&D and to tie eligible work to evidence. That is the job, and it is the limit of it. We are not training public models on your proprietary code, not sharing it with other customers, and not using it for anything beyond preparing your claim. Your code is an input to your substantiation, full stop.
Keeping each company's data separate
The tool is built around the idea that one company's code and claim data must never leak into another's. Tenant isolation, keeping each organisation's repositories, artefacts, experiments and figures walled off from every other tenant, is a first-class design concern, not an afterthought bolted on later. For accounting firms running claims across many client companies under one account, the same separation applies between their clients.
Financial data and payments
A claim involves cost figures, salaries and rates. We handle that data to compute your eligible expenditure, and we treat it with the same care as the code.
For payments, we use Stripe and its hosted checkout, which means card details go to Stripe, not through us. We are not storing your card numbers, which keeps the most sensitive payment data out of our systems entirely.
What stands behind it
Two things back the technical measures:
- Insurance. We carry professional indemnity and cyber cover, which is important precisely because we sit adjacent to source code and tax-relevant financial data.
- A narrow purpose. The strongest privacy protection is not wanting your data for anything else. Our business model is a flat fee for preparing a defensible claim. We have no secondary use for your code or your numbers, and no incentive to retain or exploit them beyond doing that job.
Your controls
You are not handing over a black box you cannot take back:
- Grant access to only the repositories you choose.
- Revoke the GitHub App install yourself, at any time, from GitHub.
- Ask us what we hold and how it is handled; we will give you specifics rather than platitudes.
Handing a tool access to your code should clear a high bar. If you have security questions this post does not answer, ask us directly. We would rather earn the trust than assume it.
This article describes our approach to security and is general information only. For specific assurances relevant to your company, contact us.