Vulnerability assessment
A systematic review of what you run and how it is configured, ranked by what matters.
Vulnerability assessmentServices
Security work that starts with authorisation
Security work is worth nothing unless it is authorised, documented and explained. Every engagement here begins with a written scope and a set of rules of engagement, and finishes with findings ranked by what they would actually cost you rather than by how long the report is.
Where we work
The parts cyber security is made of.
Each discipline can stand alone, and they are at their best when they run in sequence.
Penetration testing
Authorised testing against an agreed goal, under rules of engagement written down first.
Penetration testingSecurity hardening
Configuration tightened against known weaknesses, with every change recorded.
Security hardening
How we approach it
Authorisation comes before anything is tested
Nothing is looked at until the scope and the rules of engagement have been agreed in writing by somebody entitled to authorise access. The document names the systems in scope, the systems explicitly left out, the hours in which work may run, the techniques that may be used, who to contact if something stops responding, and where data encountered along the way may be stored.
- A signed scope naming in-scope and out-of-scope systems
- Rules of engagement covering timing, techniques and escalation
- Confirmation that the person signing may grant access to those systems
Findings ranked by what they would cost you
A list of everything technical is not a report anybody can act on. Each finding says what it is, how it was reached, what somebody could do with it, and what we would fix first — in order, with the reasoning for that order, because the first thing to repair is rarely the one with the longest name.
- What the issue is, in words a manager can repeat
- How it was reached, so a developer can reproduce it
- What we would fix first, and why that order
The limits of any assessment
A test finds what was there while it ran, on the systems that were in scope, using the techniques that were agreed. It does not prove that a system is secure, and any supplier who offers that certainty is selling something that does not exist. So every report says plainly what was not examined, and what has to be tested again after a change.
- What was tested, and what was not
- Which assumptions the findings rest on
- What has to be revisited after a change
Data, evidence, and afterwards
Material encountered during testing is treated as carefully as the client's own sensitive records: stored only where it was agreed, kept only as long as the report needs it, and destroyed once it has been handed over. Fixes are then retested, and the retest report says what is closed and what is still open.
- Evidence stored where agreed, and destroyed after handover
- A retest of the agreed fixes, with the result in writing
- A conversation with the people who will do the fixing, not just a PDF
One studio
What this connects to.
The other service lines this one meets on a real project, and what the two of them share.
Software development
Anything the studio builds can be tested by the team that built it, so findings come back as changes in the product rather than as a list of regrets.
Hosting and ongoing support
Most known weaknesses are closed by an update that was actually applied, which is where routine maintenance and security turn out to be the same work.
Campaigns
A campaign that collects entries, phone numbers or email addresses is holding other people's data, and it is governed by the same rules as any other system.
Questions we are often asked
Do we need a penetration test or a vulnerability assessment?
An assessment is the broader, repeatable review: it looks at everything in scope and tells you what is weak. A penetration test takes one stated goal and tries to reach it, which is what you need when somebody — a client, a bank, an investor — is asking whether a specific thing can be done rather than whether anything is wrong.
Will testing disrupt our systems?
Some techniques carry risk of disruption, and the ones that do are only used if you authorise them specifically. That is why the window, the exclusions and the stop condition are agreed before work begins, and why the person who can halt everything is named in the document rather than left implied.
What do we receive that we could show to somebody else?
A report written to be read by your auditor as well as by the people doing the fixing: scope, dates, techniques, findings and limits, with the technical detail separated from the summary. It is evidence that the work happened and what it found. It is not a certification of any framework, and we will say so rather than let it be read as one.
Where to go next
- Penetration testing or vulnerability assessment — which do you need?Both look at the same systems and both produce findings. One gives you a list of what is weak; the other tries to prove that something can actually be done.
- All servicesBranding, campaigns, advertising, print production, software development and cyber security.
- Start a projectTell us what you are building and we will reply with how we would approach it.
Next step
Tell us what you are working on.
A short description of the project is enough to start. We will reply with how we would approach it, what it needs and what it would take.