Why do security awareness training platforms need separate service levels for support and recovery?

Why separate support and recovery clocks matter

Support service levels measure responsiveness, but recovery service levels measure restoration. For security awareness and human risk platforms, those are not the same outcome: a vendor can acknowledge a problem quickly and still leave phishing simulations blocked, reporting workflows broken, or compliance records unrecoverable.

The practical reason to separate them is that the buyer is not purchasing “ticket handling”, but continuity of a programme. If the platform underpins training delivery, phishing simulations, reporting, assignments, or evidence retention, then the ability to restore those functions is the service that security and compliance teams actually depend on.

That distinction is why recovery needs its own clock, its own target, and its own escalation path. If only support is measured, a vendor can remain contractually “green” while the business stays unable to run campaigns, prove completion, or recover historical records after an incident or failed change.

What each service level should cover

Support service levels should cover acknowledgement, triage, communication quality, and progress updates. They tell you whether the vendor is engaging the issue and whether the case is being handled with discipline, but they do not by themselves prove that the platform is usable again.

Recovery service levels should cover the restoration of the affected capability, such as campaign delivery, user enrolment, reporting, integrations, or data recovery. For this kind of platform, the question is not just whether the vendor responded, but whether the security programme can resume normal operation with acceptable data integrity and minimal interruption.

In practice, the two clocks often need different definitions of “done”. A support ticket may close when a workaround exists, while recovery should remain open until the original function is back, the underlying cause is addressed, and any lost or corrupted content has been restored or accounted for.

How buyers should structure the contract and escalation path

For this type of platform, service design should separate incident handling from business restoration. That usually means defining support response targets, recovery targets, ownership for each stage, and the evidence required to close them. The most useful wording is operational, not aspirational: what is acknowledged, what is mitigated, what is fully restored, and what counts as acceptable recovery.

Buyers should also align the recovery obligation to the platform’s real dependencies. If the service is tied to identity integrations, content libraries, user enrolment, or reporting exports, then recovery time must reflect those dependencies rather than a generic helpdesk promise. The contract should make clear which parts are vendor-controlled and which parts require customer coordination.

Separate clocks also make vendor governance easier. They let procurement, security, and compliance teams compare suppliers on the basis of programme continuity, not just service desk speed. That is especially important where the platform is used to demonstrate awareness activity, show completion evidence, or support audit requests.

Risk and Threat Considerations

When support and recovery are merged into one metric, a provider can appear to meet its obligation while the platform remains partially unusable. That creates operational blind spots, because the buyer may not see that campaigns, records, or integrations are still impaired even though a ticket has been acknowledged or partially worked.

Failure mechanism: The vendor closes or de-prioritises the issue after responsiveness targets are met, but the underlying service restoration, data repair, or programme continuity work is still incomplete. This is a common failure mode in services that mix incident support with restoration of business-critical functions.

Impact: Security awareness activity can stall, compliance evidence can be delayed or lost, and teams may have to run the programme manually until the platform is genuinely restored. In a serious outage, the business may also lose confidence in reporting, completion history, or campaign integrity.

Practitioner Guidance

What to prioritise: Define support and recovery as separate obligations in the SLA or MSA, then tie recovery to the specific functions that matter most, such as training delivery, phishing simulation, reporting, and record retention. If those functions differ in criticality, give them different recovery targets.

What to verify: Check that the vendor can demonstrate both response performance and restoration performance from real incidents or exercises. Ask for the point at which a ticket is considered acknowledged, mitigated, resolved, and fully recovered, and make sure those states are not collapsed into one.

Practitioner takeaway: A fast reply is not the same as a restored service, so the contract should measure whether the awareness programme can actually resume, not just whether the vendor answered the call.

Related resources from NHI Mgmt Group

• Guide: Security Awareness and Human Risk Management Guide
• How should security teams govern Active Directory service accounts?
• Why does traditional security awareness training fail to reduce risk for users with different access levels?
• How should security teams adapt awareness training for GenAI-driven social engineering across email, messaging, voice, and social platforms?
• What happens when organisations treat awareness training and email security as separate programmes?