Security Assessments
Find it before someone else does.
An assessment answers a question an audit cannot: given what is actually exposed, what can somebody do with it? We test that under written authorisation, inside an agreed scope, and we show our work.
Severity is contextual. The same technical flaw can be a footnote in one system and a company-ending problem in another. We rate findings by what they reach in your environment, which means we have to understand the business before we rate anything.
The problem
A scanner output is not an assessment.
Automated tools find known patterns and produce long lists, most of it noise, none of it chained. What they cannot tell you is whether three low-severity issues combine into one path from the public internet to your customer database.
We use tooling where tooling is efficient, then spend the time where it is not: on the logic of your specific system, on the assumptions it makes about its own users, and on the paths between components that nobody drew on the architecture diagram.
Scope
What can be assessed.
Each of these is a separate scope with its own authorisation, timing and rules of engagement.
- Threat modellingStructured walk through the system with your engineers: assets, actors, entry points, and what would actually hurt.
- Web and API testingAuthentication, authorisation, business logic, input handling, session management, tenant isolation.
- Cloud configurationIdentity and permission paths, exposed storage, network reachability, and privilege escalation between accounts.
- Internal networkWhat an attacker reaches after one workstation falls — lateral movement, credential exposure, segmentation in practice.
- Red-team exerciseObjective-based, low-noise testing that also measures whether your detection and response actually notice.
- RetestA focused second pass after remediation that states, per finding, whether it is closed.
Sequence
How an assessment runs.
Authorise
Written scope, target list, time window, permitted techniques, emergency contacts and the condition under which we stop immediately.
Map
Enumerate what is genuinely exposed. Most of the useful surprises happen here, before anything is exploited.
Test and chain
Verify each candidate issue by hand and follow it as far as the scope allows — a finding is only real once it is demonstrated.
Report and debrief
Reproducible write-ups, a live walkthrough with your engineers, and agreement on what gets fixed first.
Deliverables
What is on the table at the end.
Reproducible findings
Each with the exact steps, the affected component, the observed result and the business impact.
Attack narrative
The paths that worked, told end to end, so the fix addresses the route and not just the last step.
Detection notes
What we did that your monitoring saw, and what it did not — usually the more useful half.
Handling
What happens to what we find.
Encrypted throughout
Findings, evidence and reports are encrypted at rest and in transit, and exchanged over a channel you approve.
Deleted on schedule
Test data and evidence are destroyed at an agreed date after delivery. The retention period is in the contract.
Never a reference
We do not name clients, publish findings, or reuse your environment as an example without written permission.
Ready to have your assumptions tested?
Send the system, the boundary you care about and the date you need the report by. Scope, effort and rules of engagement get agreed in writing before anything is touched.