Readiness Audit
Sample report
This is an anonymised sample of a Purpledecks Readiness Audit. It shows the report format and the kind of findings a real audit contains. It is built from real findings across our engagements. The client, the product, the people and any identifying detail have been removed, and some detail has been generalised or combined for illustration. It is not a live client report, and the numbers here are representative. A real audit is scoped to your product.
The subject is a funded digital health company with a consumer mobile app and a cloud backend, handling special-category health data. A previous development team built the platform and has since handed it over. A funding round and a clinical pilot with a healthcare partner are both close. The company asked us to tell them, honestly, whether the software would survive that scrutiny, and what to fix first.
Where the platform stands.
The product works today at small scale. It is not ready for outside scrutiny. The reasons are not mainly about code quality. They are about control, security and data protection, and they are fixable.
Not ready for a raise or a clinical pilot in its current state. Six critical issues must be resolved first. The most serious are that the company cannot yet fully prove it owns and controls its own product, an internal admin tool is open to anyone who can reach it, and the groundwork for handling health data lawfully is missing. None of these is unusual for a product built and handed over by an outside team. All of them can be closed in weeks, not months.
The three things that matter most
What is genuinely solid
Not everything needs fixing. The database is well designed and documented, and can be kept under any future architecture. The app's front end is cleanly built. The real-time chat is the right tool for the job and works well. Authentication is solid and enforced in the right place. The foundations are sound. The problems sit around the edges, in control, security and the backend design, not in the core.
All findings, ranked by severity.
Every finding, with its area and the rough effort to fix it. The critical and high findings are written out in full below. Effort is a rough guide: Quick is hours to a day, Moderate a few days, Significant one to two weeks, Structural a larger piece of work.
Severity is carried by the label and the ordering, not colour alone.
Do you actually control your own product.
This is where the most serious findings sit, and it is the part a code review never reaches. A product can be well written and still not be yours to run. If the people who built it walked away, could you keep it running and ship a fix. Can you prove, to an investor or a partner, that you own every part of it.
Ownership and control register
Every part of the product, and who actually controls it today. This table is the heart of the audit. It is what lets you say, plainly and truthfully, that you own your own software, or shows you exactly where you do not yet.
Read this as a checklist to close. Every row marked at risk or critical is an owed action, and most are quick once someone is chasing them.
Release and control map
How a change reaches real users today, and where the gaps are.
Security and data handling.
The serious findings are concentrated in the internal admin tool and in how secrets and personal data are handled. The admin tool matters most, because it reaches the most sensitive data with the least protection.
The remaining security findings are in the register. In short: personal data is written to logs that are not protected by default (SE-03), there is a large backlog of known vulnerabilities concentrated in the admin tool (SE-04), and two smaller hardening items remain (SE-05, SE-06). None is as urgent as the two above, but the vulnerability backlog is real work and should be scheduled.
Architecture, code and the stack.
The code itself is not the problem. The front end is cleanly built and the data model is sound. The one significant technical finding is an architectural choice in the backend.
What is solid, and should be kept
- The database. Well designed, documented, and sensible. It can be kept as-is under any future architecture.
- The app front end. Cleanly structured, with a single tidy path to the backend. The app itself is not the problem.
- The real-time chat. The right tool for the job, and it works independently of the backend issues above.
- Authentication. Solid, and enforced in the right place.
Can it keep running.
Handling health data lawfully.
This platform processes special-category health data, which carries specific legal duties beyond ordinary data protection. This section flags where the software and its evidence fall short. It is not legal advice, and the historical exposure below in particular needs a solicitor. We build software to the standard that applies and work under your quality system. We are not a certification body, a notified body, or a legal or regulatory adviser, and we say where that line is.
Beyond these, there is no data retention policy and no incident response procedure to meet the 72-hour notification duty (RG-03). Both should be put in place before launch.
What we reviewed, and what we could not.
An honest audit is clear about the edges of what it saw. This is what the findings are based on, and where we had to note a limit or make an assumption. Where something could not be verified, it is flagged, not glossed over.
What to fix, and in what order.
A prioritised plan. The order is driven by risk, not effort. The first block is what must be true before any users or any pilot. It is deliberately short, because a small number of things carry most of the risk.
Must be done before a raise, a pilot, or real users.
- Rotate every hardcoded secret and remove the weak fallback (SE-02).
- Put authentication in front of the admin tool and take it off the public internet (SE-01).
- Move error monitoring to a company-owned account (OC-01).
- Confirm and secure ownership of the cloud account, domain, app store accounts and signing certificates (OC-02–04).
- Stand up a repeatable, company-owned build and release pipeline (OC-02).
- Take the historical exposure to a solicitor (RG-02).
- Put a DPIA and a documented lawful basis in place (RG-01).
- Stop writing personal data to unprotected logs (SE-03).
- Work through the critical dependency vulnerabilities, admin tool first (SE-04).
- Confirm database backups are on and test a restore; document media recovery (PC-01).
- Put a data retention policy and incident response procedure in place (RG-03).
- Add a proper development environment so changes are not tested in production (TH-03).
- Close the smaller security items (SE-05, SE-06) and revoke old team access (OC-05).
- Plan and begin moving the backend off the serverless-as-primary-engine pattern, keeping the sound parts intact (TH-01, TH-02).
- Write down system documentation and reduce key-person risk (PC-03).
- Put monitoring, alerting and cost visibility in place.
- Set up ongoing dependency management so the backlog does not rebuild.
The honest answers, ready to give.
The point of this audit is not the report. It is that you can walk into the raise or the partner conversation and answer straight. Here are the questions you will be asked, and the honest answers you can give once the plan is underway. Straight answers, backed by a plan, beat a polished pitch that falls apart under a follow-up.
Your options from here.
Take it to your own team.
The plan is written to be actioned by any competent engineering team. If you have people, they can run it.
Take it to another firm.
The findings and the effort estimates are yours. You are free to get the work done by anyone.
Have us do the remediation.
If you would like Purpledecks to carry out the fixes, we can. We would scope and price it separately, and tell you plainly if any part is better done by a specialist, a solicitor for the data protection question, for instance.
We priced and delivered this audit as a fixed engagement. Whether we do the fix work is a separate decision, and nothing in these findings depends on it. The severity of a finding is not affected by whether we can be the ones to fix it.
This is a sample. Get one for your product.
A Readiness Audit is a fixed engagement, from $15,000 or €13,000 in Ireland and the UK. It starts with a short scoping call.