Control Inheritance Misunderstandings

A logistics company engaged a cloud platform vendor to host their customer data and order management system. The vendor held an ISO 27001 certification, and the logistics company's TPRM team accepted this as confirmation that the vendor's security controls met the international standard. During a follow-up audit, the auditor reviewed the vendor's ISO 27001 certificate and statement of applicability. The certification scope statement read: 'The information security management system for the internal corporate IT infrastructure supporting the organisation's business operations.' The customer-facing cloud hosting platform , the environment where the logistics company's data actually resided , had been built and operated by a separate division that was not within the certification scope. The penetration testing, access control reviews, encryption management, and incident response practices that the ISO 27001 certification attested to applied to the corporate IT infrastructure. They did not apply to the cloud hosting division. The logistics company had inherited confidence from a certification that certified a different organisational scope than the service they were purchasing.

What is the Control Inheritance Misunderstanding Problem, Really?

Control inheritance is the practice of relying on a third-party certification, audit, or assessment as evidence that certain controls are in place, rather than conducting direct assessment of those controls. When a vendor holds a SOC 2 Type II report, an ISO 27001 certificate, or a PCI-DSS compliance attestation, customers can inherit assurance from those certifications for the controls and scope they cover , reducing the need to directly assess controls that a reputable third party has already assessed. This is a legitimate and efficient approach to evidence-gathering that reduces the assessment burden on both vendors and customers.

The misunderstanding arises when customers inherit assurance from certifications without verifying that the certification's scope covers the assets, services, and controls relevant to their specific relationship. Every major certification has a defined scope , the boundaries of what was assessed and what the certification applies to. ISO 27001 certificates specify the management system scope and the assets within it. SOC 2 reports define the system description covering the services assessed and the infrastructure supporting them. PCI-DSS compliance attestations cover the cardholder data environment. Each certification is bounded by its scope, and controls outside the scope boundary are not covered by the certification's assurance.

The scope-narrowing problem is where misunderstanding most commonly creates risk. Vendor certification scopes are frequently narrower than they appear. An ISO 27001 certification for a multi-product company may cover only the product line that sought certification. A SOC 2 report for a SaaS vendor may explicitly exclude development infrastructure, subprocessors, and data centre physical controls. A PCI-DSS attestation for a payment processor may cover the payment processing environment while excluding the fraud analytics platform that also processes cardholder data. Each narrowing is legitimate , certifications cover what they were designed to cover. The problem is customers who assume the certification covers the full vendor relationship without reading the scope statement.

• Certification scope not reviewed , certificate accepted as assurance without reading the scope statement
• Scope narrower than assumed , corporate IT scope applied to customer-facing service assumption
• Excluded systems not assessed , controls on systems outside certification scope not directly evaluated
• Subprocessor coverage assumption , assuming certification covers subprocessors that are explicitly excluded
• Certification age not considered , older certifications covering the environment as it existed at assessment time, not current state

Why this matters

Control inheritance misunderstandings matter for TPRM because they create a specific type of false assurance , the confidence that comes from a genuine, well-regarded certification that does not actually cover the assets relevant to the customer's risk. The certification is real. The assurance it provides is real for its defined scope. The customer's assumption that the scope includes their relevant service is the error. This type of false assurance is particularly insidious because it is based on genuine evidence that is genuinely authoritative for what it covers , the error is entirely in the scope assumption, not in the certification itself.

The SOC 2 scope exclusion problem is the most frequent practical manifestation. SOC 2 reports explicitly define the system in scope in the system description , the services, infrastructure, and controls assessed. Many SOC 2 reports include explicit exclusions: 'subprocessors are not within the scope of this examination,' 'physical security of the data centre infrastructure is provided by [cloud provider] and is not assessed in this report,' 'the development environment is not within the scope of the system.' Customers who accept a SOC 2 report as evidence of comprehensive security assurance without reading the system description and exclusions have accepted assurance for a subset of the relevant controls.

Where most teams get this wrong

The most consistent failure is accepting certifications as evidence without reading scope statements and exclusions. Scope statements are not fine print , they are the definition of what the certification covers and what it does not. An assessor who confirms 'ISO 27001 certified' without reading the scope statement has confirmed certification existence without confirming certification relevance.

• Accepting certification as assurance without reading scope statements
• SOC 2 exclusions not reviewed , system description and excluded systems not examined
• No scope relevance check , whether certification scope covers the assets relevant to the relationship
• Certification age not evaluated , how recently the environment was assessed
• Complementary control requirements not assessed , controls the vendor's certification places responsibility on the customer

What good looks like

Mature control inheritance programmes read scope statements and exclusions before relying on certifications as assurance, confirm that the certification scope covers the specific services and assets relevant to the customer relationship, and identify and directly assess the controls that are outside the certification scope.

• Read scope statements , for every certification relied upon, the scope statement is reviewed and the covered assets are confirmed
• Identify scope exclusions , systems and controls explicitly excluded from certification scope are identified and assessed directly
• Confirm service relevance , the specific service and infrastructure relevant to the customer relationship is within the certification scope
• Review complementary controls section , SOC 2 complementary controls the customer must implement are reviewed
• Check certification currency , when was the most recent assessment and does the scope reflect the current environment

Tooling

SOC 2 Report Review , AICPA guidance, SOC 2 system description review

SOC 2 reports follow a defined structure , service organisation description, applicable trust services criteria, description of controls, and test of controls results. The system description section specifies what is in scope. The complementary user entity controls section specifies what the customer must implement. For TPRM practitioners, reading both sections before relying on a SOC 2 report provides the scope relevance and complementary control information that certification acceptance without reading does not.

ISO 27001 Certificate Review , Certificate scope statements, Statement of Applicability

ISO 27001 certificates specify the scope on the face of the certificate. The Statement of Applicability documents which controls are included, excluded, and on what basis. For TPRM practitioners, requesting the Statement of Applicability alongside the ISO 27001 certificate provides the detailed scope information that the certificate's brief scope statement summarises.

Governance challenges

The governance challenge with control inheritance is the reading investment. SOC 2 reports can be lengthy documents. ISO 27001 statements of applicability can be comprehensive spreadsheets. The efficiency benefit of control inheritance is reduced if every assessor must read every document in full. The governance resolution is scope-focused reading , assessors trained to immediately locate and evaluate scope statements, system descriptions, exclusions, and complementary control requirements without reading every page.

• Train assessors to read scope statements and exclusions , not every page, but the scope-defining sections
• Require scope confirmation before relying on certifications , documented confirmation that scope covers relevant assets
• Identify and directly assess excluded controls , controls outside certification scope receive direct assessment
• Track certification currency , when was the most recent assessment
• Review complementary controls , customer control obligations from vendor certifications are identified and implemented

If you are a small team

For the three certifications you rely on most heavily in your TPRM programme, find the scope statement or system description and read it specifically to answer: does the scope cover the specific service or infrastructure through which this vendor accesses or processes our data? For SOC 2 reports, also read the complementary user entity controls section to identify what your organisation is responsible for implementing. Those two readings , scope and complementary controls , will reveal whether your control inheritance assumptions are accurate.

• Read scope statements for every certification relied upon in TPRM
• Confirm scope covers the specific service and infrastructure relevant to the customer relationship
• Review SOC 2 complementary user entity controls sections
• Identify and directly assess controls outside certification scope

What to require

Ask directly:

"For your ISO 27001 certification, can you confirm that the scope covers [specific service name and infrastructure] , specifically, that the system handling our data is within the certification scope statement?"

"For your SOC 2 report, what systems and services are explicitly excluded from the scope , and specifically, is [named system] within or outside the examination scope?"

Expect as evidence

• Certification scope statement or system description confirming coverage of relevant service
• List of explicitly excluded systems from SOC 2 system description
• Statement of Applicability for ISO 27001 if requested
• Complementary user entity controls from SOC 2 report

A vendor who provides an ISO 27001 certificate should be asked to confirm that the scope on the face of the certificate covers the specific service and infrastructure relevant to the customer relationship. The certificate is genuine. The scope it covers is the question.

How to evidence it

• Scope statement review records for all certifications relied upon
• Scope relevance confirmation documentation
• Excluded controls direct assessment records
• Complementary user entity controls implementation records

Key Takeaway

Control inheritance works when the scope matches. It fails silently when it does not. The ISO 27001 certification is real and the controls it covers are genuinely assessed to the standard. The cloud hosting platform where the customer's data resides is outside the certification scope. The assurance inherited from the certification does not extend to the assets the customer's risk depends on. Reading the scope statement is the governance step that distinguishes relevant assurance from assumed assurance. The certificate is genuine. The scope is bounded. The boundary is the thing to read.

More on Compliance

• Assurance vs Validation
• Audit Evidence Quality
• Audit Scope Limitations