Our FAQ page gives the short version of how an audit works. This is the longer one - what actually happens at each stage, and why the same four stages end up being the baseline check every project goes through before we consider it launch-ready.
1. Scoping
Before any testing starts, we sit down with you to define exactly what's in scope: which domains, applications, environments, and systems we're allowed to test, what's explicitly out of bounds, and what “done” looks like for this engagement. This matters for two reasons - it keeps testing focused on the systems that actually matter to your business, and it means you know exactly what was (and wasn't) checked when the audit is over. An audit with a vague scope produces a report that's hard to trust.
2. Assessment
This is where we actually test the systems in scope, using a combination of automated scanning and manual review. Automated scanning surfaces known, catalogued issues quickly - outdated dependencies, missing security headers, exposed services, common misconfigurations. Manual review is where the deeper issues turn up: authentication and access-control logic that looks fine on the surface but breaks under a specific sequence of steps, business logic flaws that no scanner can recognize because they're specific to how your application actually works. We use established references such as the OWASP Top 10 as a starting checklist for common web application risks, then go beyond it based on what your specific systems actually do.
3. Reporting
You get a written report, not just a spreadsheet of tool output. Every finding is described in plain language, ranked by severity and by the realistic business impact if it were exploited, and includes enough detail for your team (or ours) to reproduce and understand it. We deliberately avoid reports that are just a wall of scanner findings with no prioritization - if everything is marked “critical,” nothing actually gets fixed first.
4. Remediation support
An audit that ends at the report is only half useful. We stay involved to help your team understand what needs fixing and in what order, and - depending on the engagement - can implement fixes directly rather than just describing them. The goal is a system that's actually more secure afterward, not just a document that says where the gaps were.
Why this is also our default, not just a service
These same four stages are what we mean when we say every website we build is “security-reviewed before launch.” It's not a separate marketing claim from the audit service described here - it's the same process, applied to our own work before we hand it over, at no extra cost. You can see the identical stages laid out on our cyber security audit page.