Your product is moving onto the group’s identity service. Central IT will manage sign-in. Can the business unit now mark access management as covered?
Not yet. Someone still needs to decide who gets each role, connect the application correctly, and account for access that does not use the central service. The useful question is not just who owns the control. It is what each team will actually do.
For a CISO, this is a coverage decision. For an identity leader, it is a service boundary. For GRC, it is a way to distinguish work performed centrally from work that remains with the business. Here is a practical way to agree on the arrangement without creating a second bureaucracy.
Be clear about what “centrally managed” means
A corporate policy and an operating service are different things. Before relying on a shared control, establish which arrangement applies:
- The central team does the work. It performs the activity for the systems explicitly included in its service.
- The work is split. The central team supplies part of the control. A product or business team completes the rest.
- Corporate sets the expectation. Local teams implement and perform the control themselves.
These arrangements can coexist. Do not label an entire control family “central” when the tasks within it have different owners.
Agree what the shared service includes
The central team should explain what it provides in terms the receiving team can use. A short service description or a section in an existing procedure may be enough. Identify:
- Which systems and activities are covered.
- What the receiving team must set up or keep current.
- Known exclusions and alternative arrangements.
- Who handles failures and urgent requests.
- What records are available and how relevant changes will be communicated.
The business unit should check that the service fits its actual needs. A group-wide baseline may not meet a particular customer commitment or local requirement. Resolve that difference before claiming coverage.
Example: bringing a product onto central identity
Suppose an acquired software company is connecting its product to the group’s identity platform. Successful sign-in is an important milestone. It is not proof that every access responsibility has moved.
A workable division might look like this. It is an example, not a required organization structure:
- The identity team operates the central sign-in service and explains its supported integrations and configuration requirements.
- The product team configures the application integration and identifies access paths outside it, including direct administrative access.
- The application or business owner decides which roles people should receive. Technical ability to provision a role is not the same as authority to approve it.
- The teams together verify the agreed access paths and record anything that remains outside central coverage.
If an emergency account must remain local, decide how it will be protected, used, reviewed and owned. Do not leave it unassigned simply because ordinary users now sign in centrally.
Before closing the onboarding work, retain the relevant configuration and test results. Record open gaps and their owners. Describe the product as partly covered if that is the honest result.
Check the handoff, not just each team’s task
Choose an ordinary access request and follow it through approval, provisioning and verification of the resulting permissions. Did the right person approve it? Did the technical change match the decision? Can the teams connect those records?
Each team may have completed its own task while the handoff still failed. For example, an approved read-only request could have been translated into a broader application role. A closed provisioning ticket would not resolve that difference.
Use this check to improve the process. It is not an auditor’s sampling method and does not establish effectiveness for an entire reporting period. Our control-description guide explains how to align the written procedure with the work.
Give owners enough authority and capacity
A named owner needs the access, time and authority to perform the task. If a product owner cannot see the relevant permissions, assigning them an access review does not solve the problem. Give them usable information and a way to get corrections completed.
GRC can coordinate the arrangement and challenge missing evidence. Collecting evidence does not make GRC the operator of every control. Likewise, do not assume the CISO can approve every business tradeoff. Identify who has authority to decide, especially when funding or customer commitments are involved.
The NIST Cybersecurity Framework 2.0 connects responsibility with authority and resources. It also calls for reviewing performance. These principles support a workable division of responsibilities; they do not prescribe particular job titles.
Keep coverage current after onboarding
The arrangement can stop working when either side changes. A central service may alter its integration requirements. A product may add a new administrative interface. A business unit may introduce a different approval process.
Agree which changes require notice and who checks the effect. Keep enough history to explain what operated during each part of an audit period. Do not overwrite an earlier arrangement and imply the new one always existed.
NIST’s description of a common control provider includes implementation, assessment and monitoring. The useful lesson is that providing a shared control is ongoing work, not a one-time statement that other teams can rely on it.
Report the gaps that need a decision
Leadership reporting should make unresolved coverage clear. State the affected service, the gap, its owner, the immediate response and the decision or resource needed. A count of centrally owned controls can hide all of that.
An approved exception should have a clear purpose and a review point. Approval does not turn a missed control into a completed one or remove a legal or contractual obligation. Involve the relevant business and specialist owners when those obligations are affected.
For SOC work, connect the arrangement to the service and reporting period actually being examined. Shared evidence can be useful, but the auditor determines whether it supports the engagement. See SOC 1 and SOC 2 across a multinational group for the wider scope decision.
The result should be simple: each team knows what it supplies, what it relies on, and what still needs attention.