Cybersecurity assessment for SMEs: what to include in scope, evidence, and quote

Why an assessment is different from “doing cybersecurity”

For an SME owner or IT manager, the real question is rarely whether to “do cybersecurity.” It is more practical: what are we buying, what evidence will we get back, and how will that help us decide what to fix first?

That is why a cybersecurity assessment should not be sold as a vague “full check.” NIST SP 800-115 treats security testing and assessment as a planned process: define the scope, run the work, analyze the results, and use the findings to reduce risk. CISA Cyber Hygiene Services makes a related point by separating vulnerability scanning, web application scanning, and remote penetration testing as different activities. CISA’s exposure reduction guidance adds the operational lesson that matters for smaller teams: if you do not know what is exposed, hardening becomes guesswork.

For a small company, the right purchase is usually an assessment with a clear perimeter, not a generic label. The deliverable should help you answer four questions:

What is exposed?
What is weak?
What matters first?
Who owns each corrective action?

That is the difference between a report you archive and a report you can use.

Assessment, scan, and penetration test are not interchangeable

These terms are often mixed together in quotes, but they solve different problems.

Assessment: a broader review of assets, configurations, exposures, and relevant controls. It should help you understand the state of the environment and the priorities for remediation.
Vulnerability scanning: a mostly automated check for known weaknesses, missing patches, or risky exposures.
Penetration test: a more targeted validation of whether selected weaknesses can actually be exploited in a realistic scenario.

The practical issue is not academic. If you ask for a scan but expect recommendations on backup restoreability, identity governance, and logging, you will probably receive the wrong deliverable. If you ask for a pentest but what you really need is a scope review and a remediation roadmap, you may get a narrow test that misses process gaps. NIST’s guidance is useful here because it treats technique selection as a matter of scope and purpose, not marketing. CISA’s service descriptions do the same by separating scanning, application scanning, and remote penetration testing.

For an SME, this usually means:

choose an assessment when you need a structured view of the whole perimeter;
choose a scan when you want fast visibility on known technical exposures;
choose a pentest when you want to validate exploitability of a defined target.

What to include in the scope before asking for a quote

A useful quote starts with a written perimeter. Do not begin with “please send us your cybersecurity offer.” Begin with the environment you want assessed.

At minimum, the scope should describe:

Identity and access

administrative and standard accounts;
MFA status and exceptions;
reset, recovery, and revocation procedures;
any SSO or federated identity already in use.

Email and domain

hosted mail platform;
forwarding rules and shared mailboxes;
anti-phishing controls;
domain and subdomain exposure.

Business application

customer portal, internal portal, APIs, or admin interfaces;
the environments included in the assessment;
external dependencies and third-party services.

Backups and restore

what is backed up;
frequency and retention;
whether restore has been tested;
whether restored data is usable by the application, not just recoverable as files.

Logging and monitoring

what events are logged;
where logs are stored;
who can review them;
whether critical events are centralized.

Internet exposure

public endpoints, VPNs, admin panels, and cloud assets;
the systems that are intentionally reachable from the Internet;
the systems that should not be.

Boundaries and exclusions

systems outside scope;
destructive testing not allowed;
production change windows;
data handling and retention rules for evidence.

If one of these points is missing, the buyer and the provider are likely to talk past each other. A quote with no scope is not a quote; it is a guess.

A simulated defensive case: a small company with email, a portal, and backups

Simulated case for editorial use only. It is not a real customer and not evidence of a real engagement.

Imagine an SME with a limited but realistic environment:

Identity: 18 Microsoft 365 users; MFA enforced for administrators only; no federated SSO.
Email: corporate domain hosted in a cloud mail platform.
Business application: a web portal for orders and customer support, exposed over HTTPS.
Backups: daily backup of the application database and mailboxes; 30-day retention.
Infrastructure: one application server, one managed database, one reverse proxy, and one VPN endpoint for remote staff.

The organization asks for an assessment because it wants to know whether the environment is reasonably controlled before renewing its security budget.

Accesses that should be enough

read-only access to inventory and relevant configuration data;
a low-privilege test account;
a scheduled window for non-destructive checks;
one internal contact for false positives, escalation, and clarification.

Evidence that should be requested back

the list of assets observed;
the list of Internet-facing interfaces;
a summary of MFA, backup, and logging status;
findings ranked by priority;
proof of closure or documented risk acceptance for each item.

Four simulated findings and why they are prioritized that way

MFA not mandatory for all users — high priority. A compromised mailbox or portal account can become a persistent foothold.
Incomplete security headers on the portal — high priority. The most visible application often becomes the easiest target for opportunistic abuse.
Backups exist but restore has never been tested at application level — medium-high priority. Data may be backed up, but that does not prove the business can use it again after an incident.
Logging exists but is not centralized — medium priority. The issue is not only whether events are recorded, but whether someone can reconstruct what happened quickly enough.

These priorities are editorial and simulated. They are not a CVSS score invented for the article. They reflect business exposure, ease of remediation, and the role each control plays in day-to-day operations.

Risk, control, evidence, owner: a table you can use in the quote

Risk observed	Control to verify	Evidence expected	Responsible owner	Priority
Weak or inconsistent MFA coverage	MFA policy and exception handling	Policy export, exception list, admin confirmation	IT / identity admin	High
Portal hardening incomplete	Security configuration for the web app	Technical finding, remediation note, retest result	Application owner	High
Backups not proven through restore	Restore test of data and application	Restore log, test result, elapsed time, issues found	IT operations	Medium-high
Fragmented logging	Log collection and review process	Example event traced end to end	Security or sysadmin	Medium
Public exposure not fully mapped	Asset inventory and exposure review	List of domains, services, and interfaces	IT / provider	High

This table helps separate three things that often get merged in a sales conversation:

risk: what could go wrong;
control: what should reduce that risk;
evidence: what proves the control exists and works.

If a vendor cannot describe all three, the deliverable may look good but remain hard to act on.

A reusable request sheet for the first conversation

You can copy this into email or into a briefing document.

Objective
Assess the real security perimeter of our SME, with focus on identity, email, the exposed business portal, backups, and logging.

Included assets
- access accounts and access policies
- corporate domain and mailbox platform
- web portal and connected APIs
- database and backups
- logging and basic monitoring

Requested activities
- perimeter and configuration assessment
- review of Internet-facing exposure
- review of access, backup, and logging controls
- findings ranked by priority with evidence
- final meeting to explain the results

Excluded unless agreed in writing
- offensive exploitation not explicitly approved
- destructive testing or stress tests
- remediation work
- systems not listed in scope

Deliverables
- asset inventory observed
- methodology used
- findings with priority and rationale
- proof of finding for each issue
- closure note or risk acceptance record

Operational constraints
- no shared real credentials in clear text
- no access beyond the minimum necessary
- no unauthorized copies of sensitive data
- no testing outside the agreed window

This is intentionally simple. The goal is not to create a legal document; it is to make the scope concrete enough for a provider to price and plan it.

How to evaluate providers without getting distracted by labels

When several quotes arrive, compare them on a few practical questions:

Is the perimeter written? If the quote does not distinguish assessment, scan, and pentest, ask for a revised scope.
Are the evidence types described? A good provider says what proof it will collect and how it will protect it.
Are permissions minimal and explicit? The provider should say which access it needs and why.
Are priorities explained? The report should tell you why one finding comes before another.
Is there a closure step? The work should end with a review meeting, not only with a PDF.
Are exclusions visible before the work starts? Exclusions are acceptable when they are not surprises.
Can the same control be checked again later? If the method is not repeatable, improvements are hard to prove.

A strong quote is not the one that promises the most. It is the one that makes the limits visible and the output actionable.

How to handle evidence safely

Evidence handling is often the weakest part of a security engagement, especially for smaller teams.

Ask the provider where screenshots, exports, and notes are stored; how long they are kept; who can access them; and how they are deleted at the end of the work. Ask whether evidence is redacted or minimized where possible. Ask how the transfer will happen and whether it is traceable.

That matters because assessment evidence may include more sensitive material than the final report itself. A careless evidence trail can create a second problem while solving the first.

What a successful assessment should change

A good assessment does more than list issues. It should make it easier to act in four operational areas:

Prevention: tighten identity controls, harden public services, reduce unnecessary exposure.
Detection: improve logging, centralization, and review of relevant events.
Containment: reduce the blast radius of a compromise with role design, segmentation, and fast revocation.
Recovery: confirm that backup and restore procedures actually return the business to service.

Recovery deserves its own validation. Backups that exist but were never restored do not prove business continuity. If your next question is how to design that kind of test, a separate restore validation is the right follow-up, not a side note. A practical example is our internal note on AWS Backup and restore testing, which focuses on whether recovered data can actually be used again by the application.

Where this fits in Dedaloop’s service catalog

If you need to turn a rough idea into a clear brief, the relevant service page is Cybersecurity and cloud infrastructure. If you want to review the wider offer, start from Services. When you already have a non-sensitive description of the process, the systems involved, and the boundary you want assessed, use Contacts to start the conversation.

The practical decision

For an SME, the decision is not whether to “do cybersecurity.” It is whether the next purchase will give you a perimeter you can review, evidence you can trust, and a list of findings you can actually close.

If the provider cannot distinguish assessment from scanning and penetration testing, cannot explain the evidence it will return, or cannot show how priorities and ownership will be documented, the quote is not ready yet.

The useful question is therefore simple: what do we need to know about our current exposure, and what proof will help us decide what to fix first?