How is this different from penetration testing?

An assessment looks at everything in scope and tells you what is weak; a penetration test takes one stated goal and tries to reach it by exploiting what it finds. Assessment is broader and is repeated regularly. Testing is deeper and answers a specific question, such as whether somebody could reach customer records from outside.

How often should it be done?

More often than most organisations expect, and the honest answer depends on how much changes: a system updated every week needs reviewing far more often than one that sits still. We agree the interval with you, and any significant change — a new system, a new integration, a move of hosting — is a reason to look again.

Do you fix what you find, or only describe it?

Either. The report is written so an internal team or another supplier can close the findings without us, and it says what we would do first. Where the fixes are in software or configuration we can carry them out and retest afterwards, which is often the faster route.

Cyber security

Vulnerability assessment

An assessment answers a deliberately broad question: what is exposed, what is out of date, how is it configured, and which of those things matters first. It is repeated work rather than a one-off exercise, because the useful comparison is against your own last assessment and not against a score.

Organisations with no security function of their own, teams preparing for a question from a client, a bank or an investor, and businesses that have never had an outside look at what they run.

How we work through vulnerability assessment

Scope and authorisation, before anything is scanned

Nothing is scanned until somebody entitled to grant access has signed off the scope in writing. That document names the systems in scope, the systems deliberately left out, the hours in which scanning may run, the techniques that may be used, who to call if something stops responding, and where any material collected may be stored.

A signed scope listing in-scope and out-of-scope systems
The testing window, agreed in advance
An escalation contact and a stop condition
Written confirmation that the person signing may authorise access

What the review actually covers

The assessment works through the things an attacker notices first and an owner rarely sees: services reachable from the internet, the age of the software behind them, how accounts and permissions are arranged, how traffic is protected, whether logging exists, and whether the backups would survive a real incident.

Externally reachable services, and what they give away
Software versions and patch levels checked against known problems
Accounts and roles, and whether the principle of least privilege is followed in practice
Certificates, encryption and how sessions are handled
Logging and backups, because an incident nobody can see is one nobody can stop

Findings written for two readers

A severity score on its own is not something anybody can act on, so every finding is written twice over: what it is, in language a manager can repeat, and how it was reached, so a developer can reproduce it. The fix order comes with the reasoning behind it, because the first thing to repair is rarely the one with the longest name.

What the issue is, and what somebody could do with it
How it was found, in steps a developer can follow
The order we would fix things in, and why that order

Repeat it, then compare

A single assessment is a photograph of one afternoon. The valuable version is repeated at an interval agreed in advance, and again after any significant change, so the report can say what has been closed, what has appeared since, and what has been open long enough to be a decision rather than an oversight.

An agreed repeat interval rather than a one-off report
A retest of the fixes, with the result written down
A comparison with the previous assessment, so drift is visible

What you receive

A signed scope and rules of engagement before any scanning
An assessment of the agreed systems
Findings written for a manager and for a developer
A ranked fix order with the reasoning behind it
A retest of what was fixed, with a written result
A plain-language summary for whoever needs assurance that it happened

Questions we are often asked

How is this different from penetration testing?
An assessment looks at everything in scope and tells you what is weak; a penetration test takes one stated goal and tries to reach it by exploiting what it finds. Assessment is broader and is repeated regularly. Testing is deeper and answers a specific question, such as whether somebody could reach customer records from outside.
How often should it be done?
More often than most organisations expect, and the honest answer depends on how much changes: a system updated every week needs reviewing far more often than one that sits still. We agree the interval with you, and any significant change — a new system, a new integration, a move of hosting — is a reason to look again.
Do you fix what you find, or only describe it?
Either. The report is written so an internal team or another supplier can close the findings without us, and it says what we would do first. Where the fixes are in software or configuration we can carry them out and retest afterwards, which is often the faster route.

One studio

What this connects to.

The other service lines this one meets on a real project, and what the two of them share.

Penetration testing
An assessment says where the weakness is; a test is what proves whether it can actually be used.
Security hardening
Findings are closed in configuration — permissions, updates, settings — rather than in a document that gets filed.
Hosting and ongoing support
The update schedule agreed here decides whether the next assessment finds the same list all over again.

Next step

Talk to us about vulnerability assessment.

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.

Start a project shasaistudio@pm.me 0799 003 003