Most IT supplier contracts promise uptime and response times, but very few let the customer see, month by month, whether the provider is actually patching, controlling admin access, testing recovery and reporting incidents as agreed. Third-party risk programmes are good at onboarding due diligence; the gap is the running relationship, where service reviews talk about ticket volumes while security commitments go unmeasured. This guide covers operational assurance for IT providers already in service: managed service providers, outsourced service desks, hosting and infrastructure operators and SaaS platforms that run critical services. It explains how to write measurable security and availability service levels, what evidence to ask for and how often, how to run service reviews that catch drift, and how to act when commitments are missed. It is for service owners, supplier managers, IT risk teams and auditors.
Key takeaways
- Security belongs in the service levels, not only the security schedule. If patch timeliness, access reviews and recovery tests are not measured like availability, nobody reviews them.
- Measure from your side where you can. Your own monitoring, logs and test results are stronger evidence than a supplier's monthly slide.
- Attestations have a scope and a date. Read what a SOC 2 or ISO certificate actually covers and what it expects you to do, then fill the gap with targeted evidence.
- Service reviews need a security agenda. A fixed set of security metrics, incidents, changes to staff and subcontractors, and open actions belongs in every review.
- Remedies must be usable. Service credits rarely change behaviour; improvement plans, escalation, audit rights and a tested exit plan do.
Where operational assurance fits in third-party risk
The Third-Party Risk Management Guide covers the life cycle: inventory, tiering, due diligence, contracting, monitoring and offboarding. The Managed Service Provider Risk Assessment Guide covers assessing an MSP before and during the relationship. This page goes deeper on one part of the life cycle: turning contract commitments into measured, reviewed operating performance for IT providers whose failure would stop or expose your services.
Regulators expect this for critical services. In the EU, the Digital Operational Resilience Act (Regulation (EU) 2022/2554) requires contracts for ICT services supporting critical or important functions to include full service level descriptions with precise quantitative and qualitative performance targets, so that the financial entity can monitor them and take corrective action when targets are not met (Article 30(3)(a)). It also requires notice periods and reporting obligations on the provider for developments that might materially affect its ability to deliver (Article 30(3)(b)), and exit strategies for those services (Article 28(8)). In the UK, the PRA's Supervisory Statement SS2/21 sets expectations for outsourcing and third party risk management for PRA-regulated firms, including a chapter on business continuity and exit plans. Even outside regulated sectors these are a sensible template. This guide summarises those provisions for operational practice and is not legal advice.
Writing service levels that cover security
Availability and response time service levels are well understood. Security service levels are often missing, or written as "the supplier will follow good practice". Each one needs a definition, a target, a measurement source and a reporting frequency.
| Commitment | Example measure (ours) | Evidence source | Frequency |
|---|---|---|---|
| Availability of the service | Monthly availability against agreed hours, excluding only agreed maintenance windows | Your synthetic monitoring plus supplier report | Monthly |
| Security incident notification | Notify the customer within an agreed number of hours of a suspected incident affecting the customer | Incident records with detection and notification timestamps | Per incident, summarised monthly |
| Patch timeliness | Critical and known exploited vulnerabilities on in-scope systems fixed within agreed days | Vulnerability scan exports or your own scan results | Monthly |
| Privileged access control | Supplier admin accounts on your systems named, MFA-protected and reviewed | Account export from your directory or PAM, review sign-off | Quarterly |
| Joiner and leaver timeliness | Supplier staff leaving your account removed within an agreed time | Leaver list matched against your access logs | Monthly |
| Backup and recovery | Restore tests completed and recovery time within the agreed objective | Test reports, witnessed tests for critical services | Quarterly or twice yearly |
| Change control | Changes to your environment raised, approved and logged; emergency changes reported | Change records from your ITSM or the supplier's | Monthly |
| Subcontractor changes | Advance notice before new subcontractors gain access to your data or systems | Notification log | Per change |
- Define the clock: State when measurement starts and stops (detection, acknowledgement, containment, resolution) and the time zone. Ambiguous clocks make every breach of a service level arguable.
- Define the scope: List the systems, environments and locations in scope. Service levels that apply only to "production" leave test environments with your data unmeasured.
- Keep operational and security levels separate: A provider can meet response times while missing patch targets. Report them separately so one cannot hide the other.
- Write targets you will measure: If nobody can produce the evidence monthly, the target will be ignored. Fewer, measured targets beat a long schedule.
Evidence: attestations and what they leave out
Independent attestations are useful but limited. A SOC 2 report comes from a CPA's examination of controls at a service organisation relevant to security, availability, processing integrity, confidentiality or privacy, and the provider chooses which of these categories are in scope. Check whether the report covers how controls operated over a period or only their design at a point in time. ISO/IEC 27001 certification shows a management system is in place for the certified scope. ISO/IEC 20000-1:2018, the service management system standard (confirmed current by ISO in 2023), shows the provider runs a certified service management system. None of these tells you how your specific service performed last month.
| Evidence type | What it tells you | What to check | Gap to fill |
|---|---|---|---|
| SOC 2 report covering a period | Controls operated over the report period | Period dates, systems in scope, exceptions, subservice organisations excluded from scope, complementary user entity controls | Period gap to today (ask the provider for a written statement covering it, often called a bridge letter), your own responsibilities |
| ISO/IEC 27001 certificate | Management system certified for a defined scope | Scope statement, certification body, expiry date | Operational metrics for your service |
| ISO/IEC 20000-1 certificate | Service management system certified | Scope and services covered | Security-specific performance |
| Supplier monthly report | Performance as the supplier measures it | Definitions match the contract; raw data available on request | Independent corroboration |
| Your own telemetry | What actually happened on your systems | Coverage of supplier-managed assets | Supplier internal controls you cannot see |
| Witnessed tests and audits | Direct observation of recovery or controls | Test scope and pass criteria agreed in advance | Cost and frequency |
Two habits make attestations useful. First, read the complementary user entity controls section and assign each one to a named owner on your side; these are controls the auditor assumed you operate. Second, check subservice organisations excluded from the report's scope, such as the hosting provider under a SaaS platform, and decide whether you need their reports too. Fourth-party concentration is covered in the TPRM guide.
Running service reviews that catch drift
Service reviews are where assurance either happens or quietly stops. Our recommendation at NHI Mgmt Group is a standing security section in every monthly or quarterly review for critical suppliers:
- Security service levels: Each measure against target, with trend over the last three periods.
- Incidents and near misses: Security incidents and major outages affecting you, with root cause status and open actions. Link to the problem records (see Problem Management for Security).
- People and access changes: Supplier staff joining and leaving your account, changes in admin access, new remote access paths.
- Subcontractors and locations: New or changed subcontractors, data locations and support locations.
- Changes and planned work: Major changes, emergency changes and anything that alters your risk.
- Attestation status: Report periods, renewals, exceptions and bridge letters.
- Action log: Every open action with owner, due date and status.
Minute the review, keep the evidence pack, and escalate repeated misses to the contract owner rather than recording them again next month.
Where identity fits
Operational suppliers hold some of your most powerful credentials: delegated admin roles in your cloud tenants, domain admin or RMM access to your endpoints, API keys and service accounts for integrations, and break-glass accounts. Assurance should cover them explicitly. Ask for a monthly list of supplier identities with access to your environment, matched against your own directory, and confirm MFA and named-user access for people and scoped, rotated credentials for non-human identities. The Caesars Entertainment breach began with social engineering against an outsourced IT support vendor, a reminder that the supplier's own help desk verification is part of your attack surface; see the Caesars Entertainment Breach 2023: How Social Engineering of an IT Vendor Led to a Loyalty Database Theft and Ransom. For delegated admin in Microsoft 365 see the GDAP and MSP Delegated Admin Access Guide.
Acting on missed commitments
| Situation | Response | Contract mechanism needed |
|---|---|---|
| Single miss with a credible cause | Record, agree corrective action, track to closure | Reporting and corrective action clause |
| Repeated misses on the same measure | Formal service improvement plan with dated milestones | Improvement plan and escalation clause |
| Security incident handled poorly | Incident review with the supplier; targeted audit | Incident cooperation and audit rights |
| Evidence refused or delayed | Escalate to executive sponsor; treat as a risk finding | Information and audit rights with response times |
| Sustained failure on a critical service | Invoke exit plan or partial transfer | Termination rights, data return, transition assistance |
Service credits compensate a little for downtime but rarely change a supplier's security behaviour. Improvement plans, executive escalation and a credible, tested exit route are what give the customer leverage. DORA's exit strategy requirement and SS2/21's exit planning chapter both assume the plan can actually be executed; walk through it at least once for each critical supplier.
Small and large organisations
Small organisations with one MSP should pick five measures (availability, incident notification, patch timeliness, admin account list, restore test) and review them quarterly with the provider; see Choosing an IT Support Provider or MSP Securely. Larger organisations should tier suppliers, apply the full security service level schedule to critical tiers, automate evidence collection from their own telemetry, and report supplier performance to the risk committee.
How to implement
- List critical IT suppliers: Start from the TPRM inventory and select providers that run, host or administer services you could not operate without.
- Gap the contracts: For each, list which security commitments exist, which are measurable and which evidence rights you hold.
- Agree a measurement schedule: Negotiate the security service levels table as a schedule or side letter at the next change point rather than waiting for renewal.
- Build the evidence pack: Decide which measures come from your own telemetry and which from the supplier, and set up collection.
- Run the first reviews: Use the agenda above for three cycles, then adjust measures that turn out to be unmeasurable.
- Test recovery and exit: Witness one restore test and walk through the exit plan for each critical supplier within the first year.
- Report upward: Summarise supplier assurance status for the risk committee every quarter.
Detection and measurement
- Supplier access monitoring: Alert on supplier accounts signing in from new locations, outside agreed hours, or to systems outside the service scope.
- Independent availability checks: Synthetic monitoring of supplier-run services so you are not relying on their report.
- Patch verification: Your own vulnerability scans of supplier-managed assets, compared with supplier reports.
| Programme metric | Target (ours) |
|---|---|
| Critical suppliers with measurable security service levels | 100% |
| Reviews held with complete evidence pack | 90% or more |
| Supplier actions overdue by more than 30 days | Falling each quarter |
| Critical suppliers with a tested restore and walked-through exit plan | 100% within 12 months |
| Supplier identities on your systems matched to a named, current person or service | 100% |
Common failure patterns
- Availability only: The schedule measures uptime and response times; security commitments sit in an annex nobody reports against.
- Stale attestation: A SOC 2 report from 18 months ago is filed as assurance with no bridge letter and no review of exceptions.
- Supplier-defined metrics: The provider changes how a measure is calculated and performance appears to improve.
- Silent subcontracting: Support moves to a subcontractor in another country without the customer noticing until an incident.
- Untested exit: The exit plan is a paragraph in the contract; data return formats and transition support were never agreed.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-05; GV.SC-07; GV.SC-08; GV.SC-10 | Contract requirements, ongoing monitoring, suppliers in incident response, post-relationship provisions |
| NIST SP 800-53 Rev. 5 | SA-9 External System Services; SR-6 Supplier Assessments and Reviews; SA-4 Acquisition Process | Service agreements, ongoing supplier review |
| NIST SP 800-53 Rev. 5 | IR-6(3) Supply Chain Coordination; CP-2 Contingency Plan | Incident notification, recovery testing |
| NIST SP 800-161 Rev. 1 | Cybersecurity supply chain risk management practices | Programme context |
| DORA (EU) 2022/2554 | Article 28(8); Article 30(2) and 30(3) | Exit strategies, contractual service levels and reporting |
| ISO/IEC 27001:2022 | Annex A supplier service monitoring and review control | Ongoing supplier performance review |
Practitioner checklist
- Identify the IT suppliers whose failure would stop or expose a critical service.
- Add measurable security service levels with clocks, scope and evidence sources.
- Read each attestation's scope, period, exceptions and user entity controls; assign owners.
- Collect evidence from your own telemetry wherever possible.
- Run reviews with a standing security agenda and an action log.
- Reconcile supplier identities on your systems every month.
- Use improvement plans and escalation, not only service credits.
- Witness a restore test and walk through the exit plan for each critical supplier.
Standards and references
- EUR-Lex: Regulation (EU) 2022/2554 Digital Operational Resilience Act
- Bank of England PRA: SS2/21 Outsourcing and third party risk management
- NIST: SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- ISO: ISO/IEC 20000-1:2018 Service management system requirements
- NCSC: Supply chain security principles
- AICPA: SOC 2 services
Related NHI Mgmt Group resources: Third-Party Risk Management Guide · Managed Service Provider Risk Assessment Guide · ISO/IEC 27036 Supplier Relationships Guide · Supplier Security Policy Template. This guide summarises regulatory provisions for operational practice and is not legal advice.