Security Assessment: What Gets Reviewed and What You Receive

When you ask for a quote for a security assessment, the prices can differ by a factor of ten, and none of them fully explains what you receive in return. That gap is usually explained by scope and deliverables, much less often by provider quality. An automated scan of your website and an assessment that reviews servers, accounts, backups and processes share a name and little else. This is what an assessment should include if it is meant to support decisions.

Scope is defined first, in writing

An assessment starts by agreeing what is included and what is excluded. That list belongs in the quote, not halfway through the work. For an SME with 10 to 50 employees, the usual scope includes:

• Internet-facing systems: website, email, VPN, remote access portals and published services you may not even remember having.
• The internal network: servers, file systems, network devices and employee workstations.
• Identities and access: active accounts, administrator rights, second factor, joiner and leaver processes.
• Cloud and SaaS services: corporate email, storage, ERP or CRM hosted by third parties.
• Backups: what is copied, how often, where it is stored and when the last restore was tested.
• Documentation and processes: existing policies, supplier contracts and the incident response plan if one exists.

If a quote does not say which of those blocks it covers, that is the first question to ask.

What is reviewed from the outside

The external part reconstructs what anyone can see about your company without credentials. It inventories active domains and subdomains, internet-facing services and the software versions they expose, certificates and expiry dates, and email configuration (SPF, DKIM and DMARC), which determines how easy it is to impersonate your domain.

It also checks whether company credentials have appeared in earlier breaches and whether information has been published by accident: exposed admin panels, forgotten backups in public directories or repositories with keys inside the code.

What is reviewed from the inside

The internal part usually produces the most uncomfortable findings because nobody has looked at them for years. It reviews pending updates on servers and workstations, network segmentation (if the reception computer can reach the accounting server, that is a finding), permissions on shared folders, service accounts with passwords that never expire and accounts for people who no longer work with you.

It also reviews what is logged and who looks at it. A system that generates logs nobody reads has the same detection value as one that generates none.

The part people forget: processes

Much of what fails in a real incident is organisational. A complete assessment checks whether there is a clear answer to questions such as: who decides to disconnect a system? Who does the first person who sees something strange call on a Sunday? How is a supplier bank account change validated? What happens to someone's access on the day they leave?

These answers cost little and prevent serious damage. If the assessment you are offered only produces tool output, this block is not included.

What you receive at the end

The deliverable is what separates a useful assessment from an expensive PDF. You should receive three documents, not one:

1. An executive summary, one or two pages without jargon: where you stand, the three main risks expressed in business terms, and what is proposed with its cost.
2. The detailed technical report: each finding with its description, how it was verified, which systems it affects, its severity and how to fix it, with concrete instructions for the person doing the work.
3. A prioritised action plan: the list ordered by risk versus effort, separating what gets fixed this week from what needs a project and a budget.

A good report also distinguishes verified findings from configuration observations and explains why something is serious in your specific context. A critical vulnerability on an isolated system with no data can matter less than a mediocre configuration on the server where invoicing lives.

What to do with the report the next week

A report without dates and owners changes nothing. The closing meeting should end with each priority finding assigned to a person and a date, plus an explicit decision on the risks you accept as they are.

Reserve time for verification too. Fixing something without checking that the fix works is one of the most common ways to carry the same finding from one assessment to the next. When you finish, keep the report: it is the evidence large-client security questionnaires ask for when they want to know whether you assess your security, how often and what you do with the results.

How often to repeat it

An assessment captures one moment. An annual review is a reasonable minimum for a stable SME, with an additional one when something important changes: a migration, a new ERP, an acquisition or a change of IT provider.

If your infrastructure or product changes every few weeks, the annual snapshot ages too quickly and should be complemented with continuous security testing, which reviews every deployment instead of waiting for next year.

Our security assessment covers the scope above and delivers the three documents in full. If you need to translate its findings into an investment decision with impact in euros, a cybersecurity risk assessment is the natural next step.