The group identity team says access is covered. A product team still manages its own administrator accounts. An operating company has promised a customer controls that the shared platform does not provide. When the next SOC request arrives, who can say what actually works across the service?
For CISOs and GRC leaders, the decision is not simply whether to buy one report or several. It is what to run centrally, what must stay with the business, and how to know the handoffs work. Identity and other security leaders need the same clarity before taking responsibility for group-wide coverage.
Start with one important customer-facing service. Follow the work across corporate functions, operating companies, regional teams and products. Use that picture to assign controls and decide what assurance the service needs. The method below is a practical starting point, not a prescribed company structure.
Separate the corporate structure from the report scope
The organization chart tells you who owns each company. The report needs to explain the system and service being examined. Those are different maps. A product sold by one operating company may depend on group IT, a regional support team, and another company’s processing staff.
The AICPA SOC 2 guide explains that systems for different services can overlap while having different boundaries. Shared infrastructure does not make the boundaries identical. Relevant supporting processes must be considered, even when another team performs them.
Ask what each customer needs assurance about
SOC 1 addresses controls relevant to customers’ internal control over financial reporting. SOC 2 addresses controls against the applicable Trust Services Criteria for the system in scope. A group can have reasons for both. They are not levels in a single ladder. The AICPA overview explains the different purposes.
For example, a group’s payroll processing service may receive SOC 1 requests because customers rely on its outputs for financial reporting. A separate collaboration product may receive SOC 2 requests about protecting customer information. Both may use the same identity team. That does not make payroll processing controls and collaboration-product controls interchangeable.
Make a service map before buying more audits
Use one row for each meaningful service or deployment. A simple spreadsheet is enough to start. Record:
- The service name and the legal entity that contracts with the customer.
- The operating companies, locations, and product teams involved in delivery.
- The shared platforms and central teams the service depends on.
- The customer commitments and reporting needs.
- The proposed report, date or period, and any important exclusions.
- Other applicable requirements that need separate attention.
Distinguish a legal entity from a product name and a hosting region. Do not use one field called “business unit” for all three. Otherwise a gap can disappear inside an ambiguous label.
Separate group oversight from control execution
Corporate management should be able to see where important risks remain unresolved. That does not mean corporate staff perform every control. A shared platform can enforce a setting while a local team makes the decision that setting depends on.
- Corporate oversight: Set group expectations, review significant gaps, and make sure someone can fund and resolve them.
- Shared teams: State exactly which systems and activities their controls cover. Identify what service teams must still do.
- Operating company or regional owners: Address delivery differences and relevant local obligations. Escalate gaps they cannot resolve locally.
- Product and service owners: Connect customer commitments to the actual workflow. Own application-specific decisions and the handoffs needed to deliver the service.
These are responsibilities to allocate, not mandatory layers or job titles. A product can cross several operating companies. A regional team can serve several products. Assign a named decision-maker for each unresolved issue rather than relying on everyone being copied into a discussion.
Test one handoff before declaring it covered
Consider a payroll service delivered by several country teams through a regional processing center. Group IT operates identity and infrastructure. The application team manages payroll permissions. Country managers approve payroll changes.
When a payroll administrator leaves, local HR notifies the identity team. The central login is disabled. But the application also has a separate support account. Who identifies it and removes access? A successful central disablement is useful evidence, but it does not answer that second question.
The practical response is to identify the separate account, assign removal to the application team, and retain evidence that both steps happened. Then check whether the gap affects other services using the same arrangement. Avoid treating it as a one-person problem if the process itself is incomplete.
The same service may need controls over payroll input approval and output reconciliation for customers’ financial-reporting reliance. Those are different from proving account removal. A shared identity team cannot stand in for the processing owners.
For each important control, record who performs it, who verifies completion, and who resolves failures. Identify the systems it reaches and the records that demonstrate the work. Keep local variations visible.
Reuse evidence carefully
One central training record may support several engagements. First check whether it includes the relevant people and reporting period. A group-wide access review may omit a product’s local administrator accounts. A ticket queue may exclude work handled by an acquired company.
Keep the source record and identify which service it supports. Record gaps rather than treating a shared folder as proof that every control worked everywhere. The auditor decides what evidence is sufficient for each engagement. Our audit evidence guide explains the underlying records.
Allow differences without losing oversight
Countries and services can have different legal, contractual, or operational obligations. Maintain a common baseline where it fits. Then document additional local requirements and justified variations. Have the relevant legal or specialist owner resolve jurisdiction-specific questions.
A control mapping can reduce repeated work. It does not prove that SOC 1, SOC 2, ISO standards, privacy laws, and customer contracts are equivalent. Keep the reason for each requirement visible.
NIST CSF Organizational Profiles offer a way to compare current and target cybersecurity outcomes. They can help organize improvement work. They do not establish a SOC report’s scope or replace its examination.
Start where uncertainty can hurt the business
Do not begin with an exhaustive mapping of every framework. Choose a service with an approaching customer commitment, a major change, or a known control gap. Bring its business owner together with the relevant shared teams.
- Confirm what the customer receives and which teams deliver it.
- Walk through one important process from start to finish. Identify unowned steps and coverage assumptions.
- Agree who will close each gap and retain the evidence.
- Check whether existing assurance actually covers that service and period.
- Use what you learn to address other services with the same dependency.
For leadership reporting, show unresolved gaps by affected service, owner and next action. A count of completed policies is not a substitute for knowing which customer-facing services still have an exposed handoff.
Then agree on the reporting approach
Take the service picture to the auditor before committing to one group report or several. Discuss whether the descriptions, controls, locations, and periods support the proposed arrangement. A central team does not automatically need its own SOC report just because several subsidiaries use it. Common ownership also does not settle the treatment of a separate service organization.
Be explicit about relevant outside providers and what is included or excluded. Do not assume a subsidiary or new product is covered because it shares the parent’s name or infrastructure.
Finish with a clear answer for each customer-facing service: what report supports it, what is not covered, and who owns the remaining work. Revisit that answer when an acquisition, new region, shared-platform change, or new service changes delivery.
For the next step inside an individual SOC 2 engagement, see how to describe your service. For SOC 1, see choosing control objectives.