Your application works. That's not the same as secure.
Most security problems don't announce themselves. A broken feature throws an error and someone fixes it. A missing authorization check does nothing at all — the application behaves perfectly, and continues behaving perfectly right up until someone requests data that isn't theirs.
That's why security weaknesses survive to production, and why they're usually found by an outsider rather than by the team that built the system.
A security audit reads the application the way that outsider would: authentication, access control, APIs, data handling, configuration, dependencies and the business workflows that can be abused without breaking a single rule in the code.
What an audit actually answers
Not a list of vulnerabilities. A set of answers you can act on.
Can one user reach another user's data?
Are permissions enforced where they can't be bypassed, or only in the interface?
Are APIs authorised per request, or only at the door?
Where does sensitive data live, and who can reach it?
Are secrets and credentials handled properly, or committed somewhere?
Which dependencies carry known vulnerabilities?
Would you know if something had been exploited?
Which of these needs fixing this week, and which can wait a quarter?
The last question matters as much as the rest. A long vulnerability list is not an engineering plan.
What we examine
Area | What we look for |
Authentication | Login, password handling, reset and verification flows, MFA, tokens, OAuth, session expiry, bypass paths |
Authorization | Roles, permissions, resource ownership, tenant isolation, admin functions, and whether checks live server-side |
API security | Per-request authorisation, object-level access, endpoint exposure, rate limiting, response data, error messages |
Data protection | Where sensitive data is stored and transmitted, what's exposed beyond its intended scope, retention and access |
Input handling | Validation, sanitisation, encoding, injection paths, file uploads and anything reaching a query unescaped |
Business logic | Workflow abuse — bypassing limits, replaying one-time actions, manipulating pricing or entitlements |
Secrets & configuration | Keys, environment variables, CORS, security headers, debug settings, production configuration |
Dependencies | Known vulnerabilities, unmaintained packages, unnecessary components, supply-chain exposure |
Cryptography | Appropriate algorithms, key handling, and where encryption is assumed but absent |
Logging & visibility | Whether security-relevant events are recorded, and whether anyone would see them |
Cloud & deployment | Application-facing infrastructure controls, environment separation, access boundaries |
AI components | Where applicable — prompt handling, model access, RAG sources, agent permissions, tool boundaries |
Scope is set by your architecture and your data, not by a checklist applied to everything.
Business logic is where most audits stop short
Automated tooling finds known vulnerability classes. It cannot find a workflow that behaves exactly as written and can still be abused.
A discount code that can be applied twice
An invitation flow that grants more access than intended
A usage limit enforced in the interface and not in the API
An approval step reachable out of sequence
A subscription entitlement checked once and never re-checked
A refund that returns money without revoking access
None of these are bugs. All of them cost money. They're found by reading the application with an adversarial eye, which is the part that requires a person.
Multi-tenant applications need more than a scan
If you run SaaS, the highest-consequence question is a single one: can one customer reach another customer's data?
We test it specifically rather than inferring it from configuration:
Tenant isolation at the data layer, not just in queries
Role enforcement across owner, admin and member
API requests manipulated to reference another organisation's resources
File and document access across account boundaries
Invitation and onboarding flows used out of sequence
Billing and entitlement checks enforced server-side
Administrative endpoints reachable by ordinary accounts
A leak across tenants is the one finding that ends customer relationships rather than causing inconvenience.
Security audit, vulnerability scan, or penetration test?
These get used interchangeably and they aren't the same thing.
What it does | When it's the right choice | |
Security audit | Reviews controls, architecture and implementation across the application | You want to know where you stand and what to fix first |
Vulnerability scan | Identifies known vulnerability signatures, largely automated | You need continuous coverage of known issues |
Penetration test | Attempts to exploit weaknesses from outside | A customer or regulator requires one, or you want proof of exploitability |
Code security review | Examines source for security weaknesses | A specific component needs deep scrutiny |
Architecture review | Evaluates security design and trust boundaries | You're changing structure, not just code |
Compliance assessment | Measures against a named framework | You're pursuing SOC 2, ISO 27001 or similar |
An audit can include elements of the others. It should never be presented as a penetration test, and we won't describe ours that way.
Why people call us
The situation | What it usually means |
"We don't know if we're secure." | Nothing is failing, no one has complained, and nobody can answer the question. An audit turns that into a document. |
"An enterprise customer sent a security questionnaire." | The deal is blocked. You need findings and a remediation record, not assurances. |
"We built it very fast." | Security controls applied inconsistently across different parts of the application. Normal, and worth finding before it's load-bearing. |
"Our developer says it's fine." | They're probably right about most of it. An independent read is worth having before a launch or a customer commitment. |
"We have a list of vulnerabilities and no plan." | A scan produced volume without priority. What's needed is sequence. |
"We inherited this codebase." | You're now accountable for decisions you didn't make and can't see. |
"Something feels wrong." | Unexplained traffic, strange records, a support ticket that doesn't add up. Usually worth checking properly. |
"It's been running for years." | Age isn't maturity. Dependencies, integrations and infrastructure all changed underneath it. |
How it runs
Step | What happens | |
01 | Scope | One call to understand what the application does, what data it holds, and what you're preparing for. Scope and fixed price agreed from that. |
02 | Read | An engineer reviews the application across the agreed areas — code, configuration and running behaviour. |
03 | Test | Access control and business logic tested from unprivileged accounts, not assumed from settings. |
04 | Rank | Findings ordered by consequence: exploitable now, risky, hygiene. |
05 | Report | Executive summary, technical findings with evidence, and remediation guidance for each. |
06 | Handoff | A call with your engineers to walk through the findings and the sequence. |
07 | Remediate | Optional. We fix what we found, or your team does, and we retest either way. |
Where it fits your requirements, assessments can be structured against the OWASP Application Security Verification Standard, which defines verifiable requirements across authentication, session management, access control, validation, cryptography, data protection, APIs and configuration.
What you receive
Deliverable | What it's for |
Executive summary | A non-technical account of where the application stands. Shareable with a board, an investor or a customer. |
Technical findings | Each one with the affected component, the impact, evidence, severity and the fix. |
Risk register | Findings as a tracked list your team can work through and close. |
Architecture observations | Structural weaknesses, not just implementation ones. |
Remediation plan | A sequence, not a backlog. What to do first and why. |
Security checklist | Repeatable checks so the same class of problem doesn't return. |
Engineering handoff | A working session with your developers. |
Retest | Optional verification that agreed findings are closed. |
When to audit
Trigger | Why now |
Before production launch | Cheaper to find than to discover. |
Before enterprise onboarding | Security review is part of procurement, and unpreparedness costs the deal. |
After rapid development | Fast delivery leaves controls unevenly applied. |
After architectural change | New auth system, new API, new cloud environment — the boundaries moved. |
After an incident | Establish what was affected and what else is exposed. |
Before or during fundraising | Technical due diligence covers this. Better to have seen it first. |
After acquiring a codebase | Inherited risk is still risk. |
Before compliance work | Technical gaps found early are cheaper than gaps found by an assessor. |
When nothing has been reviewed in a while | Dependencies and integrations age even when your code doesn't. |
Who we work with
Startup founders preparing to launch or sell upmarket
SaaS companies with multi-tenant data
product teams before a major release
engineering teams wanting an external perspective
CTOs who need an objective risk picture
agencies assessing applications built for clients
enterprises reviewing internally or externally developed software
teams shipping AI features alongside conventional software.
What we won't do
Call an audit a penetration test.
They're different assessments. If you need a pentest for a customer or a regulator, we'll say so and help define the scope.
Issue a compliance certification.
We can find and fix the technical gaps that stand between you and SOC 2 or ISO 27001. The certification itself requires an authorised assessor.
Hand you a scanner report.
Automated tooling is part of the work, not the deliverable. Anything we report, we can show you.
Inflate severity.
A finding ranked critical should be one that a person could exploit today. Padding the top tier makes the whole report useless.
Questions
Question | Answer |
Is this a penetration test? | No. An audit reviews controls, architecture and implementation. A pentest attempts exploitation from outside. Both are useful; they answer different questions. |
Do you follow OWASP? | Where it fits. ASVS provides a verifiable structure for web application security requirements and we use it as a basis when the application suits it. |
Can you audit a SaaS product? | Yes, and tenant isolation is usually the first thing we test. |
Can you audit an AI-built application? | Yes. If it was built with Lovable, Bolt, Replit, Cursor or similar, our AI app security audit is a closer fit and a faster engagement. |
Can you audit applications with AI features? | Yes — prompt handling, model access, retrieval sources, agent permissions and tool boundaries, alongside the conventional application surface. |
Do you fix what you find? | If you want. Remediation can run as a continuation of the audit or be handed to your team with the report. |
Can you retest afterwards? | Yes. Verification of agreed findings is scoped as a follow-up. |
Will you produce something for a customer's security questionnaire? | Yes — a shareable summary plus the remediation record showing what was found and closed. |
What does it cost? | Fixed price, scoped from the application. Size, stack, number of components and depth all move it, so we quote after understanding the system rather than before. |
Who reads our code? | One senior engineer. It is never used for training, and access is removed after delivery. Mutual NDA before anything is shared. |
We think we've been breached. | Tell us immediately — that's a different and faster process, and the first hours matter most. |
Find out where you stand
Tell us what the application does and what you're preparing for. We'll define the right scope, quote a fixed price, and start.
Scoped in one call. Fixed price before any work starts.
Related
AI app security audit · Codebase audit · Production readiness · Codebase takeover