A term sheet is close, or an enterprise buyer has sent a vendor questionnaire, and someone asks for "your security documentation". You do not need a certificate at this stage. You need a document that says what was tested, how, what was found, what was fixed and what remains, on a date, written by someone who is not you. This post describes what that document contains and how our Full audit produces it. The scenario page Before an investor or security review covers the wider situation.
Why the reviewer will ask
Apiiro's analysis of repositories at Fortune 50 companies found AI-assisted developers produced three to four times more commits and ten times more security findings, with privilege escalation paths up 322% (Apiiro, 2025). Those findings came from Apiiro's own engine and Apiiro sells security tooling, so read them as a trend rather than a rate. A diligence reviewer who has seen that research will ask how you test. The document below is the answer, and every section of it is something you can check against your own app before anyone asks.
The six parts
Scope
Say which app, which version or commit, which environments, and which categories were tested. Name what was out of scope. A reviewer trusts a document that says "payments were not in scope" more than one that is silent about them. Our full audit covers secrets, data access, authentication, payments, AI features, reliability, performance, data integrity and deploy configuration, and the summary lists exactly that.
Method
Describe how the testing was done in enough detail that another tester could repeat it. For us that means: the bundle read, API calls as a stranger and as two unrelated users, table enumeration with the public key, admin route probing, webhook forgery and replay against a test account, injection payloads through every model entry point, and header and configuration review. Method is what separates a test report from an opinion.
Findings by severity
List every finding with a severity, the mechanism in one sentence, and the affected path. Critical and high first. A reviewer reads this section to judge two things: whether the flaws found are the ones they would expect in an app of this kind, and whether the severities are honest. A summary with zero findings on a first test invites more questions than one with a few, fixed.
Fixes verified on re-check
For each finding, state whether it was fixed and whether the tester confirmed the fix by re-running the original test on a date. "Fixed by the developer" and "fix verified by re-test" are different sentences, and reviewers know the difference. Our full audit includes a re-check within 30 days, so the summary you send can show verified fixes rather than promises. The pattern pages show what a re-check looks like for each finding; for example Row Level Security disabled on a table is re-checked by repeating the unfiltered read as a stranger.
Open items
List what remains, with the reason: accepted risk, scheduled for a date, or awaiting a dependency. An honest open-items list is what makes the fixed list credible.
Date and version
Every page of the document carries the test dates and the version tested. Findings describe what we observed on the version you gave us access to, on the date of testing. Changes after that date are not covered until re-checked. A summary from six months ago is a historical document, and saying so is better than letting the reviewer discover it.
What the document is not
It is not an attestation. We test against a defined checklist and report what we find. We do not guarantee that an app is free of vulnerabilities. We are not a certified penetration-testing firm and do not issue compliance attestations. We do not rebuild your app; fixes are yours or your developer's, and we re-check them.
Say the same in your document's first paragraph. Reviewers are used to test reports and they are used to attestations, and a report that pretends to be the other loses trust on page one. If a buyer needs a formal compliance report, our summary gives their consultant a starting inventory of what was tested and fixed, which shortens that process. The full list of limits is at What we cannot do.
How the full audit produces it
The Full audit costs $1,900 and takes 5 business days from access to report. It delivers the full findings report across all categories, a summary document written for an investor or enterprise security questionnaire, a prioritised fix roadmap, a 60-minute walkthrough call and a re-check after fixes within 30 days. The summary is the six-part document above, written for a reader who does not code. A synthetic example of the findings format is at Sample report. If the report does not contain at least one actionable finding, or you are not satisfied with its depth, tell us within 7 days of delivery and we refund the package in full.
If the review is in days rather than weeks, the Pre-launch check covers the five highest-yield categories in 48 hours and produces a shorter version of the same summary.
What to do this week
- Run the nine checks the scenario page lists before anyone asks: Before an investor or security review.
- Confirm secrets are out of the repository history, the first thing a reviewer's scanner finds: Secrets committed to the code repository.
- Check whether dependencies with known vulnerabilities are in your build: Dependencies with known vulnerabilities.