Cybersecurity services for growing businesses

The controls underwriters and assessors ask about, in order

A cyber-insurance application is a control inventory with commercial consequences. It asks whether multi-factor authentication is enforced, on what: remote access, email and privileged or administrative accounts are the usual distinctions, and an application that asks about all users is asking a different question from one that asks only about administrators. It asks whether endpoint detection and response is deployed across servers and workstations and actually monitored, which is a higher bar than having antivirus installed. It asks whether security logs are collected centrally and retained for a defined period, whether critical systems are segmented from general user networks, whether backups are immutable or offline and whether restores have been tested, and what the patch cadence is. Answering these accurately is the first step to buying intelligently, because each answer names a gap with a price attached.

• MFA: enumerate the access paths, then say which one is not covered.
• EDR: coverage across servers and endpoints, plus who reviews the alerts.
• Logging: central collection and a stated retention period, not a default.
• Backups: immutable or offline copies, and documented restore tests.
• Patching: a cadence you can evidence, not one you intend.

There is a published baseline to measure against

Two free public documents turn a general worry about security into a numbered list that can be assessed. NIST released version 2.0 of its Cybersecurity Framework on 26 February 2024, organised around six functions — Govern, Identify, Protect, Detect, Respond and Recover. Govern is the function added in that edition, and it is the one a buyer should care about most, because it places accountability for risk with the organisation rather than with a vendor. NIST publishes quick-start guides aimed at particular audiences and a searchable catalogue of informative references that maps the framework against more than fifty other cybersecurity documents, so a small business can begin from the guide written for its situation rather than from the whole framework. The CIS Critical Security Controls v8.1 is the companion baseline: its Implementation Group 1 is defined as essential cyber hygiene, described as the emerging minimum standard of information security for all enterprises, and consists of fifty-six safeguards chosen to be implementable with limited security expertise against general, non-targeted attacks. Either gives you a list to put in front of a provider and ask which items are owned, by whom, and how they would be evidenced.

• NIST CSF 2.0: six functions, with Govern the addition in the 2024 edition.
• The framework ships with audience quick-start guides and a mappings catalogue.
• CIS Controls v8.1 Implementation Group 1 is 56 safeguards of essential cyber hygiene.
• Use a baseline to assign ownership item by item, not to buy a product.

PCI DSS sets specific, testable duties for a card-accepting business

For a merchant, PCI DSS v4.0.1 replaces several of those questions with numbered requirements. Multi-factor authentication is required for all personnel with non-console administrative access into the cardholder data environment and for all remote access into it, which is broader than the older administrative-access wording and is where most small merchants have a gap. Audit logs must be reviewed at least once daily under requirement 10.4.1, and log history retained for at least twelve months with at least the most recent three months immediately available for analysis under 10.5.1 — a period whose stated reason is that compromises often go unnoticed for significant lengths of time. Penetration testing is required at least once every twelve months and after any significant infrastructure or application upgrade or change: internally under 11.4.2 and externally under 11.4.3, by a qualified internal resource or external third party whose organisational independence exists, and not necessarily a QSA or ASV. Where segmentation isolates the cardholder data environment from other networks, the segmentation controls themselves must be penetration tested at least once every twelve months and after any change to those controls or methods under 11.4.5; a service provider must do the same at least once every six months under 11.4.6. Requirements the standard previously listed as best practice became mandatory on 31 March 2025.

• MFA covers non-console administrative access and all remote access into the CDE.
• Logs reviewed at least daily (10.4.1); retained twelve months, three months available (10.5.1).
• Internal and external penetration tests at least annually, and after significant change.
• Segmentation controls penetration tested at least annually (11.4.5) — every six months for a service provider.
• Requirements that were best practice until 31 March 2025 are now fully assessable.

Identity: which second factor, and on which path

If one control has to be closed first it is multi-factor authentication, because it defeats the credential-theft path most intrusions still begin with and because it is the control insurers screen on hardest. Second factors are not equivalent, and NIST's digital identity guidance ranks them: it defines three authenticator assurance levels, AAL1 through AAL3, and describes an authentication as verifier impersonation resistant when it is designed to thwart a phishing attack, a property it requires at AAL3. Authenticators that rely on the public switched telephone network, including phone- and SMS-based one-time codes, are classed as restricted. Using one obliges the organisation to offer at least one alternate authenticator that is not restricted, to give users meaningful information about the risk and the alternatives, to include the added risk in its own assessment, and to hold a migration plan for the day the restricted type is no longer acceptable. The rest is enumeration: every path that reaches a privileged or remote session — the remote-access gateway, the administrative console, the mail tenant, the finance system, the line-of-business application, and any third party holding an account. Each path either has a second factor or it is the gap, and recovery codes and bypass accounts belong in that inventory rather than beside it.

• Enumerate access paths rather than users; the paths are what an attacker uses.
• Know which factor sits on each path, and whether that factor type is restricted.
• Include third-party and vendor accounts, which are frequently missed.
• Manage bypass and recovery credentials deliberately, and review them.

Segmentation is a scope decision before it is a product

Segmentation is usually bought as equipment and should be planned as an argument about scope. The purpose is to keep systems that store, process or transmit card data away from general user networks, so that the population of systems needing assessment shrinks. That only works if the boundary is real and provable, which is why the standard requires the control to be tested and the penetration test to validate it. A segmentation project that cannot produce a test result has not reduced scope; it has added a device.

• Define which systems are in scope for card data before designing anything.
• Prove the boundary with testing, and keep the evidence.
• Re-test after changes, not only on the annual cycle.
• Treat remote and wireless paths as part of the boundary question.

Detection and logs: what 'monitored' has to mean

Endpoint detection without review is a licence rather than a control, and the same is true of centralised logging with no alerting. The standard asks for mechanisms to detect and address malware on commonly affected system components and for audit logs that support investigation; insurers ask whether alerts are monitored and by whom. In practice that means agreeing who is woken up, in what time, with what authority to isolate a machine, and what happens when that person is on holiday. A managed detection and response service is often bought precisely to answer that question, which is worth understanding before buying one.

• Define who reviews alerts, in what window, with what authority.
• Retain logs long enough to reconstruct an incident that is discovered late.
• Test the escalation path, not just the alert path.
• Cover servers and endpoints, not only laptops.

If you bid on defence work, the requirement arrives by contract

A fourth regime sits apart from insurance and card data because it applies by contract rather than by sector. A contractor handling covered defence information must safeguard it under the DFARS clause at 48 CFR 252.204-7012, which points at NIST SP 800-171 as the standard for protecting controlled unclassified information in non-federal systems; the current published revision of that standard is Revision 3. On top of it the Department of Defense runs the Cybersecurity Maturity Model Certification programme, set out in 32 CFR part 170, with three levels: the 15 requirements drawn from the basic safeguarding clause at 48 CFR 52.204-21 for Level 1, the 110 requirements of NIST SP 800-171 Revision 2 for Level 2, and 24 requirements selected from NIST SP 800-172 for Level 3. A program manager or requiring activity selects the level a given procurement needs, based on whether the work involves federal contract information or controlled unclassified information. The rule phases the requirements into solicitations and contracts over four phases, with the later phases each beginning a calendar year after the one before, and it does not displace the separate safeguarding duties that already apply. For a small supplier the consequence is that the obligation arrives with an award and, at the higher levels, is assessed rather than self-declared.

• FCI triggers a lower bar than CUI; the level follows the information, not the size.
• Level 1 is self-assessed; Level 2 is self- or C3PAO-assessed; Level 3 is government-assessed.
• The requirement flows down to subcontractors who touch the information.
• Establish where you sit before a bid, not after an award.

What to gather, and how HighGround helps

Bring the current cyber-insurance application and its answers, the systems that handle card data or personal information, the account inventory that reaches them, the current backup and logging arrangements, and any assessment or questionnaire already completed. HighGround sources security and managed services through the AppDirect catalog and scopes each requirement individually. Availability, pricing and terms depend on the environment, the providers serving your location and the contract term. An inquiry places no order and commits you to nothing, and HighGround may receive compensation from a provider on a completed purchase.

• The insurance application as submitted, including the answers you would change now.
• Systems holding card or personal data, and who can reach them.
• Current backup, logging and monitoring arrangements, with retention periods.
• Any prior assessment findings and their open items.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions