What evidence should an outsourced IT provider provide about security controls?

Security controls evidence is the verifiable information that shows how an outsourced IT provider protects systems, data and administrative access in practice. A suitable evidence pack should identify the controls in scope, explain how they operate, show who is responsible for them, and demonstrate that they are checked rather than merely described in a policy.

Start with the scope of the evidence

Before assessing individual documents, establish what the evidence actually covers. The provider should identify the services, platforms, offices, data types and support processes included in its security arrangements. It should also distinguish between controls operated by the provider, controls operated by a cloud or hosting partner, and controls that remain the customer’s responsibility.

This scope should make clear:

• which parts of the provider’s service are included;
• which legal entities, locations and technical environments are covered;
• where customer data is stored, processed or transferred;
• which third parties or subcontractors support service delivery; and
• which responsibilities must be completed by the customer.

A certificate or assessment with a narrow scope may be valid but still provide limited assurance if it excludes the service team, support tools or infrastructure used for your organisation. The scope statement is therefore as important as the name of the assessment.

Ask for evidence that is specific and attributable

Useful evidence should be dated, owned and linked to a defined control or process. For example, a review record should identify the period covered, the person or team that performed it, the systems considered and any resulting actions. Generic statements such as “access is reviewed regularly” are less useful than a completed review record showing what was examined and how exceptions were handled.

For each important control, look for four features:

• Design: what the control is intended to prevent or detect.
• Operation: how the control is applied in the provider’s environment.
• Ownership: who performs, approves and oversees it.
• Evidence: what records demonstrate that it operated as intended.

This approach helps distinguish a documented intention from a control that is embedded in day-to-day operations.

Review the control areas that affect your risk

The evidence should cover the security measures most relevant to the services being outsourced. Depending on the arrangement, this can include:

• identity lifecycle processes for creating, changing and removing user and administrator access;
• privileged access arrangements, including approval and oversight of elevated permissions;
• secure configuration standards for endpoints, servers, network equipment and cloud services;
• vulnerability management, including how findings are prioritised and tracked;
• backup design, protection and restoration exercises;
• security event handling, escalation routes and decision-making responsibilities;
• data protection measures, including retention, disposal and encryption where relevant;
• physical security for offices, equipment and facilities used to deliver the service;
• staff screening, security training and leaver procedures; and
• resilience arrangements for maintaining or restoring important services.

The provider should explain how these controls apply to your particular service rather than supplying a broad document with no connection to the proposed arrangement.

Understand independent assurance

Independent assurance can take several forms, including an audit report, certification, penetration test, vulnerability assessment or review by a qualified external assessor. These forms of evidence answer different questions. A certification may assess whether a management system meets a defined standard, while a penetration test examines selected technical weaknesses at a particular point in time. Neither should automatically be treated as proof that every aspect of the service is secure.

When reviewing an independent report, check:

• the assessment date and reporting period;
• the assessor’s qualifications and independence;
• the systems, locations and services included;
• the assessment method and any limitations;
• whether findings were rated by severity;
• the provider’s response to findings; and
• whether the report is a full report, an executive summary or a supplier-issued statement.

It is reasonable for sensitive technical detail to be redacted. However, redaction should not remove the information needed to understand the scope, method, material findings and corrective action.

Look for evidence of improvement, not a claim of perfection

Well-managed security programmes can have weaknesses or exceptions. More informative evidence shows how the provider records, assesses and addresses them. Ask whether each significant issue has an owner, a target date, a risk decision and confirmation of closure. Where an issue is accepted rather than fixed, the provider should explain who accepted the risk, why that decision was made and when it will be reconsidered.

Unresolved findings are not automatically disqualifying. A transparent explanation, sensible prioritisation and visible follow-through are generally more useful than an assurance statement that provides no insight into limitations.

Check the incident and evidence-handling process

The provider should be able to explain how security events are identified, recorded, assessed and escalated. Ask what information would be supplied if an incident affected your systems or data, who would make decisions, and how relevant records would be preserved for investigation. The process should also address lessons learned and the updating of controls after a material event.

Ask how security evidence itself is protected. Reports may contain network details, user information or weaknesses that should not be distributed without controls. The provider should define who can access evidence, how it is transferred, how long it is retained and how confidential material is disposed of.

Agree evidence requirements in the contract

Security assurance should not depend entirely on an informal request after the service has started. Contractual or service documentation can define the evidence the provider will supply, the circumstances in which additional information can be requested, and the process for addressing material changes or control failures.

Useful arrangements may cover:

• the evidence categories relevant to the outsourced service;
• the format and review process for assurance information;
• notification of material security incidents or significant control changes;
• co-operation with reasonable audits or customer risk reviews;
• responsibilities for regulatory or contractual reporting; and
• access to information needed when the service is changed or ended.

These requirements should be proportionate to the sensitivity of the data and the importance of the service. A small, low-risk engagement may need a focused control summary and targeted records, whereas access to sensitive information or core business systems justifies deeper scrutiny.

Warning signs in a provider’s response

Take care if the provider supplies only undated policy documents, refuses to describe the scope of an assessment, relies on a certification that excludes the relevant service, or cannot explain who owns unresolved findings. Other concerns include inconsistent answers from different contacts, evidence that has not been reviewed for a long period, and a refusal to discuss subcontractors or shared responsibilities.

The objective is not to collect the largest possible volume of paperwork. It is to establish a traceable connection between the provider’s stated controls, the services you are buying, the risks those controls address and the records showing that they operate. That evidence gives your organisation a more reliable basis for supplier due diligence, ongoing governance and informed risk decisions.