The subsidiary at the certification boundary

No. A certificate held by another legal entity does not remove the dependency. Clause 4.3 requires the scope to consider external and internal issues, interested-party requirements, and interfaces and dependencies with third parties. Northwind's in-scope London service depends on Lisbon's tokenisation platform, a shared identity provider, shared backups and a shared SOC. If those components fail or are compromised, the London service is affected. The correct analysis is therefore not 'does Lisbon have a certificate?' but 'which controls must Northwind rely on, and can Northwind demonstrate they operate effectively?'

Two defensible options exist. First, extend the scope to include the Lisbon platform and its interfaces, then assess its risks and audit its controls. Second, maintain a narrower scope but document the boundary, the interface controls, and the governance arrangements (OLAs, control-responsibility matrix, monitoring, incident escalation, audit rights). The second option is weaker because shared services create shared risk. In either case the CISO must obtain evidence, not rely on the subsidiary's certificate as a proxy; certificates cover a defined scope and point in time. Relying on one without reviewing its scope, findings and surveillance history is itself a supplier-management weakness.

The CISO should run a short, focused programme rather than wait for the audit:

1. Perform an interface risk assessment covering the API gateway, shared identity provider, SOC, backups and incident ticketing. Identify scenarios such as a compromised Lisbon administrator reaching London systems, or a backup failure affecting recovery.
2. Produce a control-responsibility matrix showing who operates each shared control and who monitors it. Test at least one incident escalation end-to-end.
3. Obtain Lisbon's SoA, most recent internal audit results, risk treatment status and any certification surveillance findings. Record the review and any gaps.
4. Decide and document the scope position: extend scope, or justify the exclusion and define how interfaces are controlled. Update the scope statement accordingly.
5. Update the risk register, risk treatment plan and SoA, and have top management approve the change.
6. Commission a focused internal audit of the interface controls, using an auditor independent of both sites.

Evidence should include the scope statement, interface risk assessment, control matrix, signed OLA or contract clauses, incident test record, supplier review record, updated SoA, management approval minutes and the internal audit report. This demonstrates control rather than assertion.

The SoA must reflect the actual scope and the controls selected after the interface risk assessment. For each Annex A control, record whether it is applicable, the justification, and its implementation status. Controls likely to become relevant include supplier relationships, cloud-service security, identity and access management, backup, logging and monitoring, incident management and technical vulnerability management. Where the parent relies on Lisbon for a control, the SoA should say so and identify the evidence and monitoring mechanism.

The mistakes to avoid are: (1) marking a control 'not applicable' merely because another entity operates it; (2) listing all 93 controls as implemented without evidence of effectiveness; (3) leaving the scope statement and SoA inconsistent; and (4) treating the subsidiary's certificate as the justification for exclusion. An auditor will test consistency between scope, risk assessment, SoA and evidence. If the exclusion is retained, the justification must be specific, approved and supported by evidence that the excluded platform cannot undermine the security of in-scope services.