A security audit is a broader assessment — including code review, configuration review, process review, and vulnerability identification across a wide scope. A penetration test (pen test) is a more targeted exercise focused on actively attempting to exploit vulnerabilities to demonstrate real attack paths — typically with a narrower scope and more depth on specific attack vectors. Security audits are appropriate for getting a comprehensive view of security posture; penetration tests are appropriate for validating that identified vulnerabilities are actually exploitable and understanding the real-world impact of a successful attack. We provide both, and they complement each other well.

The OWASP Top 10 is a list of the ten most critical web application security risk categories, maintained by the Open Web Application Security Project. It includes: Broken Access Control, Cryptographic Failures, Injection (SQL, NoSQL, command), Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and Server-Side Request Forgery (SSRF). Our security audits systematically cover all OWASP Top 10 categories, plus additional application-specific risks relevant to your technology stack and business context.

We rate vulnerabilities using a risk-based approach that considers both the likelihood of exploitation and the potential business impact: Critical — easily exploitable, significant business impact (direct data breach, financial loss, complete system compromise); High — exploitable with moderate effort, significant impact; Medium — exploitable under specific conditions, moderate impact; Low — difficult to exploit or limited impact; Informational — best practice concerns without direct exploitability. We use the CVSS (Common Vulnerability Scoring System) scoring as a baseline and adjust for your specific application context — a vulnerability that is severe for a financial application may be lower risk for an internal tool.

We recommend a structured remediation process: immediately assess Critical and High findings — determining whether any require immediate mitigation (taking a feature offline, blocking specific traffic) while fixes are developed; schedule remediation of all significant findings with accountable owners and deadlines; prioritise remediation by severity and exploitation likelihood; verify fixes — testing that the remediation actually addresses the vulnerability; and plan a follow-up assessment to confirm all findings are resolved. We provide remediation support — answering questions and reviewing proposed fixes — as part of our audit engagement.

For most applications, an annual security audit is a minimum — with additional audits triggered by: significant new functionality (new features may introduce new vulnerabilities); major infrastructure changes; after a security incident; before a significant data processing agreement or regulatory review; or when engaging with enterprise customers who require it. High-risk applications (financial, healthcare, high-value eCommerce) benefit from more frequent audits — semi-annual — or from a continuous security testing programme.

The information needed depends on the audit type and scope. For an authenticated audit (most comprehensive), we need: access to the application with test accounts at different privilege levels; the application URL(s) and any staging/test environment access; documentation of key functionality and user roles; and ideally access to the codebase for code review. For a black-box audit (simulating an external attacker with no privileged access), we only need the application URL. We work within your security and data handling requirements — we do not require access to production data and can conduct testing in isolated test environments.

Before any security testing begins, we execute a formal security testing authorisation agreement that: defines the scope of testing (what is in and out of scope); establishes the testing window (dates and times); grants explicit permission to conduct security testing (protecting both parties legally); specifies data handling requirements (how sensitive information encountered during testing will be handled); and defines the reporting obligations. This agreement ensures testing is conducted with full legal authorisation. We test only within the agreed scope and handle any sensitive data encountered according to the agreement.