CAPABILITY / AUDITS
Engineering audits that end in a test.
We audit applications, data access, AI features and infrastructure. You receive findings we have reproduced, a remediation plan in phases, and closure tests any team can rerun. Teams ask for an audit before a launch with real data, before a customer's security review, or before a major change. It is not a penetration test and it is not legal advice.
8 min read
Start with the Production-Readiness Audit.
- What it is. The full review of one system before launch: what blocks real data, in the order to fix it, with a closure test for every step and a retest at the end.
- When to ask for it. A launch with real customer data is scheduled, a customer has asked for a security review, or a first engineering hire or an investor wants to know what they are inheriting.
- What you receive. Classified findings, a phased remediation plan, closure tests and a retest against the original findings.
Focused audits.
When the question is narrower, a focused audit applies the same method, the same finding format and the same classification to one part of the system. You can order one on its own, or it can come out of a Production-Readiness Audit as a recommended next step.
Code and architecture
- Architecture and code behavior review. How the system actually works, function by function, and whether its design holds up in the cases your business depends on.
- Dependency, configuration and secrets review. Which third-party packages are actually reachable, which upgrades are safe, and whether keys or debug settings ship where they should not.
- Business rules and edge cases. The rules your product must never break, such as amounts, states and limits, tested at their boundaries, including inputs nobody expected.
- Library or single-component review. A focused review of one library, service or module, sized to that component.
Data and access
- Access control and tenant isolation review. Who can read or change which records, across users, roles and customers, including routes that bypass the interface.
- Data integrity and concurrency review. Whether records stay correct under retries, duplicate requests, partial failures and two people acting at once.
- Schema and data migration review. Whether a migration can run, be stopped and be rolled back without losing or corrupting data, before it touches production.
- Privacy input. Which privacy rules apply to your actual data flows, and the technical facts your privacy officer and advisors need, such as input for a Law 25 privacy impact assessment. No legal opinion.
Behaviour under load and failure
- End-to-end flow verification. The journeys that bring in revenue or carry risk, such as sign-up, payment, sign-off and export, tested from start to finish.
- Performance and load review. How the system behaves at expected load, at peaks and over long runs, where it breaks, and whether it recovers on its own.
- Backup, restore and incident readiness. Whether a backup has actually been restored, whether a bad release can be rolled back, and whether the team knows what to do in an incident.
- Security review of exposed entry points. Every way into your system that is actually reachable, tested for the threats that apply to it. Not a penetration test of the live system.
AI and infrastructure
- AI system audit. What data your AI features send out, what the model is allowed to do, how its output is checked, and how much model usage each feature runs up.
- Infrastructure and platform review. Edge, DNS and TLS, network, identity, compute, scheduled jobs and gateways: what each layer is responsible for, and whether that holds.
Before and after
- Pre-build baseline review. Before a new build or a major rewrite: the stack, the risks, the test plan and the conditions to start building, agreed in writing.
- Retest and independent closure. The closure tests from an earlier report, rerun against the original findings by an engineer who did not write the fix.
Scope is agreed before work starts. It is set per system, from a short review of one application to a review that includes a live cloud environment and dynamic tests authorized in writing. Not every audit applies to every system.
How we decide what is a finding.
We follow how the system actually behaves across code, configuration, data, identities and the services it calls before we call anything a finding. A control found elsewhere can reduce an apparent problem. A second route to the same data can turn a small detail into a real risk. We look for both.
Every finding states how far it was proven:
- Read in the code. The cause is visible in the code or configuration, and we show where.
- Reproduced in a test environment. We made it happen outside production, with steps your team can repeat.
- Confirmed in your environment. We observed it in the environment you authorized us to test.
What we could not demonstrate is listed as an open question, not as a finding. What we did not cover is listed and never counted as passed. When we find nothing, we say where we looked.
Example (illustrative)
Not covered: payment provider webhooks (no test credentials supplied). Not counted as passed.
What every audit delivers.
Every audit, full or focused, ends in the same documents:
- Findings register. Each finding with an ID, its classification, the evidence, the steps to reproduce it and a plain description of what it exposes.
- Summary for decision-makers. What blocks launch, what blocks which features and what can wait, written for a founder, a board or a customer conversation.
- Remediation plan. Ordered phases and steps, with their dependencies and a closure test for each step.
- Closure tests. Runnable checks where possible, otherwise documented manual procedures, written before any fix exists.
- Readout session. A walkthrough of the findings with your team, recorded if you wish.
- Retest report, when you ask for one after remediation. Each original finding marked closed, with the passing closure test, or still open.
Every finding receives one classification: Blocks launch, Blocks a feature or Debt.
The audit does not depend on who fixes it.
The report, with every finding and closure test, comes before any proposal from us to fix anything, and you can fix with any team. When we carry out the fix, a different engineer reruns the original closure tests, and the retest report says so on its first page.
This is a separation of roles inside one firm, not a third-party review.
What an audit is not.
- Not a penetration test. We review code, data rules and configuration and reproduce findings. We do not perform penetration testing.
- Not legal advice. We give you and your advisors the technical facts. Legal opinions stay with them.
- Not a verdict against a law or framework. We do not state that a system meets a law, a standard or a customer's requirements.
- A point-in-time check. The findings describe the code and environment we reviewed, on the dates we reviewed them.
BEFORE WE GET TO WORK
A few answers.
Which audit should we start with?
Usually the Production-Readiness Audit. If a launch, a customer security review or a first engineering hire is coming, it covers the whole system and tells you what blocks it, in order. If the question is already narrow, such as one AI feature or one large migration, a focused audit on that part is enough, and we will tell you so.
Can we order a single focused audit, for example only our AI feature?
Yes. A focused audit applies the same method, finding format and classification to that part only, so its results line up with any later audit. The scope is agreed in writing before work starts, and anything outside it is listed in the report as not covered.
Is a software audit the same as a penetration test?
No. We read the code, the data rules and the configuration, and reproduce findings in a non-production environment. A penetration test attacks the live system from outside. We do not perform penetration testing.
Do you need access to production or to customer data?
No, not by default. We work from read access to the code and schema, a non-production environment and synthetic records. A check in a live environment happens only when you ask for it and authorise it in writing.
Does an audit tell us whether we meet Law 25 or pass a customer's security review?
No. It gives you, your privacy officer and your advisors the technical facts: where personal information is, who can reach it and which gaps exist. Those decisions, and any legal opinion, remain with you and them.
Who can carry out the fixes after the audit?
Any competent team, including your own. The report and its closure tests come before any proposal from us to fix anything. If we carry out the fix, an engineer who did not write it runs the retest, and the retest report says so on its first page.
PRACTICAL GUIDES
Before you scope an audit.
How to check an AI-built app before launch ↗
WHAT IS COMING UP?
Tell us about the system and what is coming.
Tell us what the system does, what it is built on and what is coming: a launch, a customer review, a large migration or a new AI feature. We will reply with the questions we need answered to scope the audit, and say whether a full or a focused audit fits.