Last updated: August 6, 2026

What security certificates should be requested from IT service providers?

Key Points at a Glance

• Request evidence based on risk and service. More documents do not automatically mean better evidence.
• Check the scope, organization, service, period, exceptions, and issuing or examining body for each piece of evidence.
• ISO/IEC 27001, SOC reports, and BSI C5 answer different questions and are not interchangeable without context.
• Technical tests, policies, incident processes, and BCM evidence supplement formal evidence when they fit the risk.
• Protect confidential reports and document any outstanding issues or customer controls.

Evidence must fit the decision.

Security evidence helps to verify statements made by an IT service provider. However, they differ significantly in subject matter, depth, and currency. A certificate evaluates a management system within a defined scope. An audit report may examine control design and effectiveness for a period. A pentest summary considers a technical review area.

There is no universal mandatory catalog for every service. The selection follows performance, criticality, data access, and potential impact. This article helps with the requirement and evaluation of the evidence. It does not replace a legal or data protection review.

Derive evidence from risk and performance.

Start with the specific service. What data does the provider process? Do they have administrative rights? Do they develop software, operate infrastructure, or provide a standardized cloud service? Which business processes would be affected in the event of failure? These questions determine what statement needs to be substantiated.

Assign each requirement to a risk. For privileged support, relevant are access sharing, strong authentication, logging, and revocation of rights. In software development, the development process, dependency management, and handling of vulnerabilities are of interest. For a cloud service, tenant separation, encryption, availability, and control of subcontractors may be key.

NIST SP 1326 describes due diligence as the research of available, relevant information about suppliers or products so that decisions can be made on a sufficient basis. The guide is tailored to ICT suppliers and mentions, among other things, resilience, basic cyber practices, and supply chain levels. It does not provide a universal German evidence catalog but supports risk-based construction.

Define before the request which document, summary, or confirmation will be accepted. Some reports may only be viewed under a confidentiality agreement. In other cases, an appropriately detailed management summary may suffice. If evidence is not provided, the provider should be able to explain alternative evidence.

ISO/IEC 27001: Check certificate and scope.

ISO/IEC 27001:2022 defines requirements for an information security management system. Certification shows that the ISMS was tested against the standard within the specified scope. It does not automatically confirm every technical individual control or every performance of the company.

Check the name of the certified organization, locations, activities, validity period, and certification body. The scope description is crucial: Does it cover the service, operating environment, and the company with which you are contracting? A very general scope requires further inquiries. A certificate for the corporate headquarters may exclude a separately operated service of a subsidiary.

For critical services, ask for the Statement of Applicability or an appropriate summary, as far as the provider can release it. This document shows which controls were selected or excluded in the ISMS and how exclusions are justified. The specific statement must be connected to the scope and the related service.

Also consider currency and changes. A valid certificate may come from an audit that occurred before a major acquisition or product change. Clarify significant changes and open findings in a supplier discussion. Certification remains important evidence, but not an automatic approval.

Use SOC reports and BSI C5 in the appropriate context.

SOC reports stem from the US auditing framework of the AICPA. SOC 1 addresses controls that are relevant for the internal financial reporting of the user organization. SOC 2 considers controls of a service organization in relation to security, availability, processing integrity, confidentiality, or privacy. Therefore, not every SOC report is equally suitable for a general security review.

When reviewing SOC 2, check the system description, included Trust Services Criteria, period, audit result, exceptions, and Complementary User Entity Controls. These customer controls must be implemented by the using organization to achieve the considered control objectives. A report with a good result may lose its significance if the customer does not implement the assumed secure configuration.

The Cloud Computing Compliance Criteria Catalogue C5 of the BSI is focused on the information security of cloud services. The BSI clarifies that a C5 certification is conducted by external auditors and is not a BSI certification. Therefore, check the report, audit subject, and usage instructions. A C5 report is particularly relevant when the cloud service in question is within scope.

C5 distinguishes between Type 1 and Type 2 reporting. According to BSI, Type 1 assesses the description as well as design and implementation of controls at a single point in time. Type 2 additionally includes testing procedures for effectiveness over a period of time. BSI considers Type 2 necessary for adequate reliability; however, special circumstances may still justify a Type 1 report.

Technical and Operational Evidence Supplement

A penetration test examines an agreed technical scope with human expertise. Do not necessarily request the complete raw report. A summary may include date, methodology, tested systems, excluded areas, findings by severity, open risks, and status of retesting. A test without a clear scope or retest says little about the current state of the service in question.

For vulnerability management, process description, responsibilities, sources, prioritization logic, and evidence of closed findings are relevant. Specific internal scan results can be highly sensitive. Therefore, agree on a format that provides sufficient evidence and does not create unnecessary attack surface through document distribution. An external Security Rating can additionally assess currently reachable systems and visible features.

In incident management, the reporting process, accessibility, classification, investigation, customer information, and follow-up are verifiable. Suitable evidence may include a process description, a drill log, or an anonymized case summary. Do not request real personal or customer-related incident data if it is not necessary for your decision.

For business continuity and recovery, defined responsibilities, dependencies, recovery objectives, and tests are counted. A policy provides the mandate; a current test log shows whether a scenario has been practiced and evaluated. Check whether the tested scenario includes the service in question and essential subcontractors.

Evaluate Timeliness, Exceptions, and Confidentiality

Every piece of evidence needs a data status. Define for each risk class how old documents can be and what events trigger a new review. Significant product changes, a security incident, a change of critical subcontractors, or a new operational region may necessitate an update of a formally valid piece of evidence.

Read Exceptions and Limitations. An audit report may contain controls with findings, cover a short audit period, or exclude parts of the service. Inquire about management response, treatment status, and compensating measures. A finding is not an automatic reason for rejection; its significance depends on risk and treatment.

Handle sensitive reports according to a need-to-know principle. Use protected transmission, role-based access, defined retention, and regulated deletion. Store evaluation and reference in the supplier file if possible, without creating unnecessary copies. Contractual confidentiality rules must be observed.

Data protection remains a separate examination area. When a service provider processes personal data on behalf, roles, contracts, and requirements according to applicable data protection laws must be examined separately. An ISO certificate, SOC report, or C5 certification does not replace this examination. Similarly, a data protection agreement does not prove the effectiveness of all security controls.

Derive a documented decision from evidence.

Do not create a pure document checklist. For each risk, compile the service provider's statement, the relevant evidence, its limitations, and open questions. Evaluate evidence based on relevance, origin, timeliness, and depth of examination. Multiple weak documents do not automatically result in a strong statement.

The service provider should be able to explain deviations and offer alternative evidence. A small provider may not have a SOC or C5 report but can provide targeted process and test evidence. The decision is based on risk and not on company size or notoriety. For critical services, the absence of independent evidence may still require additional examination.

Document accepted evidence, data status, findings, measures, deadlines, and residual risk. Link expiration dates with follow-ups. For ongoing services, external signals may trigger an earlier examination. The Security Rating provides an additional external view but does not replace evidence evaluation.

LocateRisk supports the technical perspective on identified or reachable systems and their changes. For organizational evidence, documents, interviews, and internal examination remain necessary. You can find guidance on integrating into the supplier portfolio at the Vendor Risk Management.

Frequently asked questions

---

What security evidence is useful for IT service providers?

That depends on the service and risk. Possible evidence includes ISO/IEC 27001 certificates, SOC or C5 reports, pentest summaries, policies, process evidence, and evidence of incident management and recovery. Each piece of evidence must cover the relevant service in an appropriate scope.

---

What must you check for an ISO/IEC 27001 certificate?

Check the certified organization, locations, activities, validity, and certification body. The scope must cover the relevant service and the applicable operating environment.

---

Is BSI C5 a certification from BSI?

No. BSI clarifies that C5 certifications are conducted by external auditors and are not BSI certifications. What matters are the specific report, its subject of examination, and the findings.

---

Must the service provider release the complete pentest report?

Not necessarily. Depending on the risk, a protected, sufficiently detailed summary with scope, date, methodology, findings, open risks, and retest status may suffice. Confidentiality and decision-making needs must be balanced.

---

Do security evidence replace data protection examination?

No. Data protection roles, contractual requirements, and the specific processing of personal data must be examined separately. Security evidence can demonstrate technical and organizational aspects but do not replace a legal classification.

Do you want to supplement formal evidence with an external technical perspective? Request a free security rating and assign the results to your examination scope.