Nothing is broken yet.
Most code reviews come back saying the code is fine. Fine is not a measurement. Fine is what everyone said about the last platform too, right up until the first weekend it had to carry real traffic.
We read it four ways: the way an attacker will, the way the next developer will, the way a regulator will when somebody files a deletion request, and the way your CFO will when the invoice marked "unexpected" arrives.
What is a production-readiness audit, really?
It isn’t a code review and it isn’t a penetration test. A code review asks whether the code is tidy. A pen test asks whether one door is locked. A questionnaire records what you say your system does with personal data; an audit checks whether the code agrees with you.
It asks the only question that matters once your name is on the deployment: can this system be run, changed and defended by people who did not write it? Defended now includes defended to a regulator.
A data privacy audit is the same exercise pointed at personal data.
Policies are written in prose. Systems are written in code. That gap is where enforcement notices come from, and it is visible in the repository. So we trace the data, not the documentation:
- whether a withdrawn consent stops the processing, or only hides the checkbox,
- retention and deletion as implemented rather than promised, traced end to end: what deletes, what archives, and what survives in backups, logs and a vendor's bucket,
- special-category data in logs and event payloads, where nobody declared it,
- for registered data brokers: the DROP cycle, hashing and status reporting.
Every finding, security or privacy, carries a file, a line, a severity and the steps to reproduce it. Every audit ends with a maintenance figure in person-days per month, because “it works” and “it is affordable to keep working” are two different findings and only one shows up in a demo. The regulation-by-regulation version of that list, written for people who have to plan around it, is our compliance checklist.
An audit that comes back as opinions with no line numbers is a second opinion with better formatting. That goes for privacy findings too.
What’s under the hood
We read code the way auditors read ledgers.
No vibes. Line numbers.
Security findings with severity and CVSS
Dependency and supply-chain risk (SBOM)
Authorisation and tenant isolation
Input validation and injection surface
CI/CD pipeline and release safety
Architecture, coupling and blast radius
Infrastructure, secrets management, deploy path
Documentation and the cost of onboarding one developer
Exposed secrets, keys and credentials
Authentication and session handling
GDPR exposure, including special-category data
CCPA, CPRA, the Delete Act and DROP deletion requests, and the state patchwork behind them
Consent capture versus consent enforcement in code
Retention and deletion, as implemented rather than as documented
Processors, sub-processors and where the data actually goes
Test coverage and the gaps it hides
Static analysis, linting and type safety
Database schema, indexing and query cost
Observability - logs, metrics, alerting
Maintenance load, in person-days per month
Why Sanddev?
Your code is read by people who built the things it depends on
We measured the thing nobody measures
We've been the vendor on the other side of this report
We have built the consent layer, not just read it
You choose who does the repairs
Technical due diligence before a funding round
Stop guessing. Start measuring.
How a software audit runs, from scope to re-test
If it's going to production and your name is on it, you're our people
Not sure you're in that list? Send the repository anyway. We'll tell you if there's nothing worth charging you for.
What it costs, before you ask 🪙
Between €890 and €14,000, depending on how much code there is and what it handles. A Readiness Check on a repository under roughly 250 files starts at €890. A full audit runs from €2,400 for a single product to €8,000 and up for multi-repository or regulated systems. Technical due diligence for a funding round or acquisition is €9,000–14,000.
Repository size first, then what the system touches. Payment flows, health or biometric data, multi-tenant architecture and a history of several different vendors all add verification work, because each finding has to be reproduced before it reaches your report. We look at the repository and tell you the band before you commit – that conversation is free.
Usually not, and we’d rather say so now. The Check is a sample: it will find the obvious exposures and tell you whether a full audit is justified. If you’re processing payments or special-category data under GDPR, a shallow pass that comes back clean is worth less than nothing, because it gives you a document that says “fine” without the evidence behind it. For those systems we’ll quote a full audit or decline the work
No, and anyone telling you otherwise is selling something. We are engineers, not lawyers. What we produce is a description of what your code actually does with personal data, with file and line numbers attached, which is the input a DPIA needs and almost never gets. Your DPO or counsel decides what it means in law. We have found that the hard part was never the legal interpretation; it was establishing the facts.
That is one of the first things we check, because it is where the gap usually is. Consent tends to be captured correctly and enforced inconsistently: the banner writes a record, and two or three services downstream never read it. Nobody notices, because nothing breaks. It is a code question, it has a file and a line, and it is answerable in an afternoon.
Automated scanning plus manual review by a senior engineer, every finding reproduced by a second person, and one written report: findings with file, line, severity and reproduction steps; an effort estimate against each; a prioritised order of work; and your maintenance load in person-days per month. One call to walk your team through it is included. No upsell meeting disguised as a readout.
It’s quoted from the report itself, as a fixed scope, so you’re comparing a real number against the cost of doing nothing. You have two options and they’re priced differently: we carry out the repairs, or one of our senior engineers supervises your own developers doing it – reviewing architecture decisions and pull requests while your team writes the code. The second is cheaper and keeps the knowledge in your building.
Because we already know the codebase. The expensive part of an audit is the first read; re-running it against a known system and documenting what moved is a fraction of that. Most clients take the re-test because a fixed finding with no evidence of the fix is just a different kind of assumption.
You get a delivery date when we scope, before you sign, and we hold it. Audits are scheduled work, not a queue — we tell you honestly when we can start rather than starting late and finishing in a hurry.
Read access to the repository, a rough file count, and ten minutes on a call to hear what worries you. Not documentation — if the documentation were good enough to brief us, you probably wouldn’t need the audit.
Then the report says so, in writing, with the evidence – which is exactly what you need in front of a board, an investor or an insurer. It happens. The cleanest codebase we assessed this year had one low-severity finding. It also had the heaviest maintenance bill on our books, which is the kind of thing an audit is for.