01Map
Estate, exposure, data holdings and identity model documented.
You getAn asset and exposure inventory, frequently the first one that exists.Build & Run
Security work ranked by what would hurt.
A scanner will hand you four thousand findings. Almost none of them are how you would realistically be breached. We work from what an attacker would do against your estate, and fix that first.
What the review covers
- 01Review2–3 weeks, fixed price
- 02ScopeApplications, cloud, identity, and process
- 03OutputFindings ranked by exploitability and impact
- 04StandardsISO 27001, SOC 2, GDPR, PCI DSS as applicable
- 05RemediationWe fix, or we brief your team to — your call
- 06RetestIncluded, so closure is evidenced not asserted
How we prioritise
Four thousand findings is not a security posture.
Automated tooling is useful and it is not a strategy. It reports what it can detect, weighted by generic severity, with no knowledge of what your systems hold or how they are reached. The result is a backlog nobody can finish and everybody stops reading.
The questions that matter are narrower. What is exposed to the internet? What holds data that would damage you? Who has standing access they no longer need? And if someone got in this morning, how long before anyone noticed?
We work from those, then use the scanner output as supporting evidence rather than as the plan. Findings are ranked by exploitability against your specific estate and the consequence if exploited.
That usually produces a first list of ten to twenty items, not thousands, most of which can be closed within a quarter. It also produces a defensible narrative for a board, which the raw output never does.
How a review runs
01MapWhat exists, what is exposed, what holds sensitive data.
02ModelHow an attacker would realistically reach the crown jewels.
03TestApplications, cloud configuration, identity and process.
04RankBy exploitability and consequence, not by CVSS alone.
05FixRemediation by us or by your team, with support.
06RetestVerified closure, evidenced for audit.
How findings are ranked
Severity is not the same as urgency.
A scanner ranks by generic severity. We rank by whether it is reachable in your estate and what happens if it is reached.
Impact if exploited
Hard to reach · severe
Schedule and fix
Real risk behind a genuine barrier. Planned into the next cycle, not treated as an emergency.
Easy to reach · severe
Fix this week
Internet-facing, unauthenticated, and it reaches something that matters. Usually a handful of items, and they are the entire first conversation.
Hard to reach · minor
Log it, move on
The bulk of any scanner report. Recorded for completeness, not worth a programme.
Easy to reach · minor
Batch it
Cheap to close and worth doing together, but not at the cost of delaying the quadrant above.
How reachable it is
Security audit & compliance
Six areas every audit and questionnaire covers.
Whether the driver is ISO 27001, SOC 2, a customer questionnaire or a regulator, the substance is broadly the same. Building it once serves all of them.
Access and identity
Who can reach what, whether that access is still justified, and how quickly it is removed when someone leaves. Standing privileged access is the most common serious finding we see.
Data classification and handling
What data you hold, where it lives, how long you keep it, and whether anyone can answer those questions without a two-week exercise.
Change management
Whether changes to production are reviewed, recorded and reversible. A good CI/CD pipeline satisfies more of an audit than most teams realise.
Vulnerability management
Not just scanning, but a process with owners and timescales, and evidence that findings are actually closed.
Logging and detection
Whether you would know. Retention long enough to investigate, and alerting on the events that matter, not on everything.
Incident response
A plan that names people rather than roles, and that has been rehearsed at least once against a realistic scenario.
Zero trust architecture
Zero trust, implemented in the order that helps.
Zero trust is a sound principle wrapped in a great deal of marketing. The principle is simply that being inside the network should not by itself grant access — every request is authenticated, authorised and logged regardless of origin.
Implemented as a product purchase it disappoints. Implemented as a sequence of changes to identity, segmentation and access, it materially reduces how far an attacker can move after an initial foothold, which is the outcome that matters.
- Identity as the perimeter — strong authentication and conditional access before anything else in the programme.
- Least privilege, enforced — standing admin rights removed and replaced with time-bound elevation.
- Network segmentation, so a compromised workstation cannot reach the database tier directly.
- Device posture checks — access conditional on the device being managed, patched and healthy.
- Service-to-service authentication — internal calls authenticated too, not trusted because they are internal.
- Continuous verification and logging — access re-evaluated, not granted once at login and left.
Security in delivery
Six controls that belong in the pipeline, not in an annual review.
Security found in a yearly penetration test is security found expensively and late. Most of it can be caught on the merge that introduced it.
01
Dependency scanning
Known vulnerable packages caught on every build, with automated upgrade pull requests where the fix is clean.
SCA in CI
02
Static analysis
Injection, unsafe deserialisation and common flaws flagged before review rather than after deployment.
SAST in CI
03
Secret detection
Credentials caught before they reach the repository, and rotation triggered when one slips through.
Pre-commit & CI
04
Infrastructure policy checks
Terraform plans checked against policy, so a public storage bucket fails review rather than becomes an incident.
Policy as code
05
Container image scanning
Base images checked and rebuilt on a schedule, because a container built last year carries last year's vulnerabilities.
Registry scanning
06
Threat modelling on change
A short structured conversation when a design touches authentication, data or external exposure.
Design reviewHow we deliver
Find it, rank it, fix it, prove it.
02Test
Applications, cloud configuration, identity and process examined against real attack paths.
You getFindings ranked by exploitability and consequence.03Brief
A working session with your technical team and a separate one for leadership.
You getA remediation plan with owners, effort and sequence.04Remediate
Fixes delivered by us, by your team, or split — whichever is faster for you.
You getClosed findings, and the pipeline controls that stop them returning.05Retest & monitor
Verification of closure, then continuous scanning and periodic review.
You getEvidence of closure suitable for an auditor or a customer questionnaire.Questions worth asking
Before you commission security work.
The three below are the ones this page does not already answer. Anything more specific, put it to us directly.
We had a penetration test last year and fixed everything. Are we secure?
You are secure against what that test looked at, on the day it looked. A penetration test is a point-in-time sample of a defined scope, and estates change weekly — a new integration, a contractor's standing access, a dependency with a newly published vulnerability. The teams with good postures treat the annual test as verification of a continuous process, not as the process itself. If dependency scanning, secret detection and infrastructure policy checks are not running on every merge, most of what next year's test finds will be things that could have been caught the day they were introduced.
Can you help us get ISO 27001 or SOC 2?
We can build and evidence the technical controls, and we work alongside your auditor rather than replacing them — certification requires an accredited body and we are not one. What is worth understanding before you start is that both standards largely attest that you do what you say you do. That makes them valuable as a forcing function and misleading as a security guarantee: a poorly secured organisation with excellent documentation can certify. We would rather help you build controls that reduce risk and then evidence them, than assemble a policy set that passes an audit and changes nothing operationally.
What should we do first if we have almost no security in place?
Multi-factor authentication everywhere, then remove standing administrative access, then make sure you have backups you have restored from. Those three account for a disproportionate share of real-world breach prevention and recovery, and none of them requires a large programme or a new product. After that, get an inventory — you cannot protect what nobody has written down, and the exercise itself usually surfaces two or three systems everyone had forgotten were still reachable from the internet.
Related capabilities