Overview
For UK software houses selling into regulated buyers, a code review shows that security is checked before release rather than after. It also supports the secure development expectations in ISO/IEC 27001:2022 Annex A 8.29. Our reviewers read the code paths that matter most, then pair each finding with a precise file and line reference and a suggested change.
A penetration test shows what an attacker reaches from outside; a code review shows why. By reading the source we can follow a piece of untrusted input from the moment it enters the application to the point where it reaches a query, a command, a file path or a template, and judge whether every step in between actually defends against abuse. That path is often invisible from the outside, especially where a flaw needs a specific state to trigger.
We combine static analysis tooling with manual reading so the hours land where they matter. Tools flag candidate issues at scale; our reviewers confirm which are real, discard the noise, and find the problems tools cannot reason about: broken authorisation logic, unsafe deserialisation, secrets committed to the repository, weak or home-grown cryptography, and dependencies with known vulnerabilities. We focus on the authentication, authorisation and data-handling code first, because that is where a single mistake does the most harm.
Every finding points to the exact file and line, explains the flawed logic, and recommends a concrete code change, not a generic principle. Where a pattern repeats across the codebase we say so, so your team can fix the class rather than the instance. The review pairs well with a penetration test: one confirms exploitability, the other explains root cause and catches what external testing never reaches.
How we work with UK clients
- Testing windows set in UK time at scoping. India runs 4.5 hours ahead during British Summer Time and 5.5 hours ahead in winter, so our days overlap.
- Fixed proposals in GBP, excluding VAT; the reverse charge usually applies to UK business buyers.
- No traffic leaves our hands until written authorisation is signed by someone entitled to give it, as the Computer Misuse Act 1990 requires.
- Findings labelled for the evidence you file: ISO 27001 Annex A, UK GDPR Article 32, PCI DSS or a supplier questionnaire.
What's included
Our approach
- Repository intakeWe take read access to the code and a short walkthrough of its architecture.
- Automated passStatic analysis flags candidate issues across the whole codebase at scale.
- Manual reviewReviewers trace data flows and read security-critical logic by hand.
- ValidationCandidate issues are confirmed, de-duplicated and ranked by real impact.
- Report & debriefWe deliver findings by file and line and brief your developers on fixes.
What you receive
- Findings mapped to exact file and line references
- Root-cause explanation for each issue
- Concrete code-level remediation, not generic advice
- Notes on recurring patterns to fix as a class
- Free re-review of fixed code on request
Standards & frameworks
- OWASP ASVS
- OWASP Top 10
- OWASP WSTG
- SANS CWE Top 25
- NIST SP 800-115
- CWE
- CVSS v4.0
- UK GDPR Art. 32
Frequently asked questions
Is this just running a SAST tool?
No. We run static analysis to cover breadth, but the value is in the manual reading that follows: confirming real issues, discarding false positives, and finding logic flaws no tool understands. You receive reviewed findings, not an unfiltered scanner export.
How much code can you review in an engagement?
Effort scales with size and complexity, so we agree a focus up front, usually the authentication, authorisation and data-handling paths and any recently changed areas. For a very large codebase we prioritise the highest-risk components rather than skim everything shallowly.
Do you need to build or run our code?
Usually read access to the repository is enough, since the review is static. Being able to build or run the application helps us confirm a few findings, so we welcome a working environment where you can provide one, but it is not essential.
Can testing run during UK office hours?
Yes. Testing windows are agreed in UK time at scoping. India is 4.5 hours ahead of the UK during British Summer Time and 5.5 hours ahead in winter, so our working day overlaps yours. If you prefer quiet periods, we can also test in your early morning or evening.
Does an application pentest help with UK GDPR?
It can. Article 32 of the UK GDPR expects "a process for regularly testing, assessing and evaluating the effectiveness" of security measures. A dated application test with retested fixes is a clear record of that process for the personal data your application handles.