What ISO 27001, SOC 2, and Tier III Actually Tell You

The Certification Confidence Gap

When evaluating infrastructure providers, procurement teams in regulated industries look for certifications as shorthand for trustworthiness. ISO 27001, SOC 2, Tier III—these labels appear on vendor websites and sales decks as proof of security, reliability, and operational maturity. And to a degree, they are. But the gap between what these certifications actually attest and what buyers assume they mean is consistently wider than most organisations appreciate.

Each of these standards addresses a different dimension of infrastructure assurance. They overlap in places, but none of them individually—or even collectively—guarantees that a provider is suitable for your specific regulated workload. Understanding what each certification covers, what it explicitly does not cover, and how to verify its applicability to your use case is a core procurement competency for any organisation deploying AI in regulated life sciences.

ISO 27001: The Information Security Management System

ISO 27001 is an international standard published by the International Organization for Standardization. It specifies the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Certification confirms that an organisation has a structured approach to managing information security risks, including policies, procedures, and controls across a defined scope.

The key phrase is "defined scope." An ISO 27001 certificate applies to the specific processes, locations, and services listed in the certificate's scope statement. A provider may be certified for their corporate IT operations but not for the datacentre hosting your workloads. They may be certified for their managed hosting service but not for the application layer that sits above it. The certificate itself is not enough—you must read the scope statement and verify that it covers the services you are procuring.

What ISO 27001 Does Not Cover

ISO 27001 does not prescribe specific technical controls. It requires that the organisation identify risks and select appropriate controls from Annex A (or elsewhere), but it does not mandate specific encryption algorithms, access-control architectures, or monitoring tools. It does not assess the effectiveness of individual controls in practice—only that a management system exists to govern them. And critically, it does not address application-level security, data integrity in the regulatory sense, or the suitability of infrastructure for specific workload types.

ISO 27001 tells you that a provider has a system for managing security. It does not tell you that the system is adequate for your specific regulatory obligations.

SOC 2: Controls Relevant to Trust Service Criteria

SOC 2 is a reporting framework developed by the American Institute of Certified Public Accountants (AICPA). It produces an auditor's report on the design and operating effectiveness of a service organisation's controls relevant to one or more Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. A SOC 2 Type I report assesses control design at a point in time; a Type II report evaluates operating effectiveness over a period, typically six to twelve months.

SOC 2 reports are more granular than ISO 27001 certificates because they describe specific controls and include the auditor's test results. However, their scope is equally important. The report covers only the systems and services described in the system description section. A provider may have a SOC 2 report that covers their cloud hosting platform but excludes their backup infrastructure, their disaster-recovery site, or their customer-support systems.

Scope Matters More Than the Badge

The Trust Service Criteria included in the report also vary. Many SOC 2 reports cover only the security criterion. If availability, processing integrity, or confidentiality are material to your risk model, you need to confirm that the report addresses those criteria—and that the controls tested are relevant to your specific deployment. A SOC 2 report that covers security for a provider's SaaS application tells you nothing about the availability guarantees of the underlying infrastructure.

Additionally, SOC 2 reports typically include "complementary user entity controls"—controls that the provider expects the customer to implement. If your organisation does not implement these controls, the assurance provided by the SOC 2 report is materially weakened. These are often buried in the report's appendices and overlooked during procurement.

Tier III: Concurrently Maintainable Infrastructure

Tier III is a classification defined by the Uptime Institute as part of its four-tier system for datacentre infrastructure. A Tier III datacentre is described as concurrently maintainable, meaning that every component and distribution path needed to support the IT load can be removed from service for planned maintenance without interrupting the IT load. This requires redundant capacity components and multiple independent distribution paths, only one of which needs to be active at any time.

In practical terms, Tier III certification means the facility can undergo planned maintenance activities—replacing a UPS module, servicing a cooling unit, or performing electrical switchgear maintenance—without taking your servers offline. It does not protect against unplanned outages such as a fire, a catastrophic cooling failure, or a simultaneous failure of redundant components.

What Tier III Does Not Tell You

Tier III addresses physical infrastructure—power, cooling, and physical distribution paths. It does not address network architecture, cybersecurity, application availability, or data replication. A Tier III datacentre could host a server with a single network connection, no backup, and no access controls, and the Tier III classification would still be valid because it pertains only to the facility's mechanical and electrical infrastructure.

It is also important to distinguish between Tier III design, Tier III facility, and Tier III operations certifications. A facility may be designed to Tier III standards but not yet certified. It may be certified at the facility level but not have undergone the operational sustainability assessment. Each represents a different level of assurance, and the distinction matters.

Questions to Ask Providers

Given the scope limitations inherent in each certification, due diligence requires going beyond the certificate itself. The following questions should be part of any procurement evaluation for regulated infrastructure.

• Scope verification: Can you provide the scope statement for your ISO 27001 certificate? Does it explicitly cover the services we are procuring?
• SOC 2 coverage: Which Trust Service Criteria are included in your SOC 2 report? Can we review the system description and complementary user entity controls?
• Tier classification detail: Is your datacentre Tier III certified by the Uptime Institute, or designed to Tier III standards? Does the certification cover design, facility, or operational sustainability?
• Gap disclosure: What areas of your infrastructure or operations fall outside the scope of your certifications? How do you address those gaps?
• Audit cadence: When were your certifications last renewed? Can you share the most recent SOC 2 Type II report under NDA?
• Exception tracking: Were there any exceptions or qualified opinions in your most recent SOC 2 report? How were they remediated?

Mapping Certifications to Your Risk Model

Certifications become meaningful only when mapped to your organisation's specific risk model. A pharmaceutical company running GxP-regulated computational workflows has different risk priorities than a medical device company focused on EU MDR compliance or a clinical-stage biotech managing patient-derived data.

Start by identifying the risks that matter most to your regulatory context: data confidentiality, system availability, processing integrity, audit trail completeness, data residency. Then assess whether the provider's certifications address those specific risks within their stated scope. Where gaps exist—and they will—determine what additional controls are needed, whether those controls are your responsibility or the provider's, and how they will be evidenced.

When "Certified DC" Still Is Not Enough

A datacentre can hold every certification available and still be inadequate for regulated AI workloads if the platform layer above the physical infrastructure lacks appropriate controls. Certifications typically cover the facility and the management system. They do not cover the operating system configuration, the container orchestration layer, the ML framework security posture, or the application-level audit trail.

For regulated life-sciences organisations, the platform-level controls—access management, change control, monitoring, logging, and data governance—are where compliance evidence is actually generated. A certified datacentre provides a solid foundation, but the regulatory conversation happens at the platform level. If your provider cannot demonstrate platform-level controls with the same rigour as their facility certifications, the certification stack is incomplete for your purposes.

The goal is not to dismiss certifications—they represent genuine investments in operational discipline and provide valuable assurance within their scope. The goal is to treat them as the starting point for due diligence, not the conclusion. In regulated life sciences, the difference between those two approaches can determine whether your infrastructure withstands its first audit or generates findings that take months to remediate.