Managed network security services, written as a contract rather than a concept, are a set of lines each of which either carries a number or decorates the page. The firewall line carries a change turnaround and a review cadence; the firmware line carries a patch lag; the monitoring line carries an alert response time; the remote access line carries an account review schedule; the reporting line carries a delivery date. Buying the services well is mostly insisting on the numbers, because a provider's real capacity is visible in what it will commit to writing, and comparing two providers is comparing their numbers under the same scope. This guide takes the standard lines one at a time, states the number each needs and the range a small organisation should expect, flags the line most contracts omit, and shows how the numbers map back onto your own written programme so the contract enforces your policy rather than the provider's habit.
The change and review numbers
Firewall changes: a standard request turnaround in business hours, and an emergency path with a faster one, both written. Rule review: quarterly for most small sites, with the review's output, rules removed, exceptions re-justified, listed in the report, since a review that removes nothing is a meeting, not a control. Remote access accounts: reviewed monthly against the current staff and vendor list, the leaver's account being the classic finding. Wifi: guest boundary tested and password rotated on a stated schedule. None of these numbers are exotic; their absence from a contract is the provider reserving the right to drift.
The patch and response numbers
Firmware and network device patching: a lag ceiling in days behind vendor release for security fixes, with emergency out-of-band handling named separately, because boundary devices are patched last by habit and attacked first by preference. Alert response: the time from a boundary alert firing to a human triaging it, and the time from confirmed incident to action, both in minutes or hours, both with an after-hours answer. The omitted line in most small contracts is response: monitoring is sold, response is implied, and the implication evaporates at 2am. The incident procedure in your own set should name the provider's committed times, which is what makes the procedure executable.
Mapping the numbers to your programme
The contract's numbers are enforcements of your policy's intentions: the access policy says remote access is named and reviewed, the contract says monthly, by them; the incident procedure says boundary alerts are triaged, the contract says within the hour. Write both sides so they cite each other, and audits, insurer questionnaires and provider changes all get easier, the questionnaire answer is a quote from a document rather than a hope. The free sheet on this site counts the access and incident documents into your set from your facts; Hardenvo Pro generates them with the numbers as your answers, so when the provider's report arrives, it is read against commitments both parties can see.
Questions people ask about managed network security services
What SLA numbers should managed network security services include?
Firewall change turnaround and quarterly rule reviews with removals listed, firmware patch lag in days for security fixes, alert triage and incident response times with an after-hours answer, monthly remote-access account reviews, and a report delivery date.
What line do most network security contracts omit?
Response. Monitoring is sold, response is implied, and the implication fails at 2am. Insist on written triage and action times for boundary alerts, and copy them into your own incident procedure so both documents cite each other.
How do I compare providers on network security services?
Same scope to each, then compare committed numbers: turnarounds, review cadences, patch lags, response times. Capacity shows in what a provider will write down; adjectives are not comparable, numbers are.