Before scoping, 'you'll have full visibility' is only a proposed sales claim. After scoping, your co-managed buyer can see which records they may read, which actions they may take, and who removes access. GDAP addresses Microsoft partner administration; it doesn't replace the access decisions for your shared service tools.
I'd cut full access from the offer unless the delivery team can explain exactly what it means. A reassuring phrase on the co-managed page doesn't configure a permission. Test the actual working arrangement before you describe it as ready.
Keep Microsoft Delegation and Shared Tool Access Separate
GDAP means granular delegated admin privileges. Keep your MSP's delegated Microsoft administration separate from the client's permissions in your MSP's tools.
Your PSA manages service records and workflow; your RMM manages and monitors endpoints. Those are separate permission decisions, as is access to your documentation platform. Decide what the client needs to do in each product rather than applying a single label called co-managed access.
Eric Anthony warns about separation problems when different clients share a productivity tenant, while Justin Esgar distinguishes that arrangement from a multi-tenant RMM management interface. That is their practitioner exchange. It makes an important scoping distinction: a shared console and a shared customer environment are different things to examine.
Start with the service responsibilities you've agreed. For each task, identify the person who performs it and the information they need. Then ask the technical owner to map that task to the supported role and customer boundary in the relevant product.
Decide What the Client Sees and Can Change
Separate reading from acting. An internal IT manager may need to see the status of their escalations without receiving authority to change your service configuration. A technician handling agreed endpoint work may need operational access that a report recipient doesn't.
Use the following review to make those decisions with delivery. These are questions for configuration, not claims that every vendor offers the same permission controls. If a product can't enforce the boundary, change the access design or the service before promising it.
| Access Area | What to Decide | What to Demonstrate |
|---|---|---|
| Client service records in the PSA | Which client tickets and notes are visible, and which actions the client can perform | The intended client view and a denied view of another client's records |
| Endpoint management in the RMM | Which endpoints and operational actions belong to the client role | An approved task works without exposing another client's devices or unrelated actions |
| Client documentation | Which records the internal team needs, and what must remain restricted | The authorized document view without unrelated client records or secrets |
| Microsoft partner administration through GDAP | The partner administration rights needed for the agreed work and the staff authorized to use them | The assigned partner user can perform the approved task under the actual relationship |
| Reporting-only access | Which service evidence the client needs to inspect | The report is available without granting operational administration |
Don't give the client a staff role merely because it is convenient to provision. Have your technical owner test the proposed client role against the agreed tasks. Include the actions it must refuse, not just the screen it successfully opens.
The model calls for a standard stack and training on it. Apply that discipline to the staff who configure and support this arrangement. A bespoke permission exception needs an owner and documentation, rather than depending on the salesperson remembering what was promised.
Make the GDAP Request Match the Work
Have the technical lead check the actual provisioning requirements and verify which staff can perform the agreed work. Record the approved access and demonstrate it with the intended user; don't rely on a relationship name as the check.
Have the technical lead select the required roles against the current Microsoft task guidance. Explain the requested responsibilities to the client's authorized approver before sending the request. Keep the approved relationship and its scope in the account's access record.
Review who belongs to the partner groups mapped to the relationship. Don't assume that a group used elsewhere contains only the people intended for this client. Record the people responsible for group membership and for reviewing the delegated relationship as work changes.
Keep the client's own administration arrangements explicit as well. The MSP's delegated access is one part of the operating agreement. It doesn't settle who within the client's organization can authorize a change or how the client maintains its own access.
Write the Revocation Path Before Onboarding
Name who initiates access removal when a person leaves or the service ends. Keep the request and completion evidence in your service record. Review the actual access routes so deleting a portal account isn't mistaken for ending every administrative permission.
Treat administrative access and commercial subscription arrangements as separate offboarding decisions.
Apply the same completeness check to the tools around it. Identify separate accounts and application access that also need review. Have the technical owner verify removal through the platform's supported process rather than closing the task because a termination email arrived.
If the client's internal IT person leaves, check the service responsibility as well as their login. Decide who now performs that work and whether the agreement needs changing. Revoking an account doesn't provide the missing employee's capacity.
Test the Promise and Record the Result
Use an authorized test account for the intended role and record the expected allowed and denied actions. Keep the configuration evidence with the test results in the access-review record. The account owner needs a clear explanation of what was verified before discussing the arrangement with the client.
Count two failures separately, alongside completed reviews: an allowed task the client role could not perform, and a denied task the role was able to perform. Any rise in the second would make me withdraw the access claim and reopen the configuration, even if the completed-review count improved. Record the actual action and customer boundary behind the count so the total leads to work.
Marketing can't make an unsupported customer boundary safe or give the service desk capacity it hasn't planned. If the product cannot enforce the proposed access, revise the offer. Don't ask the client to rely on a sentence saying staff will be careful.
The model includes MFA in the security baseline. Keep that requirement with the actual access configuration, rather than describing basic authentication protection as a premium collaboration benefit. Confirm what each product supports and what your team has implemented.
Take the next co-managed proposal through an access review before signature. Show the client the records they can see and the actions they can take, then identify who grants and removes each access route. Keep GDAP as the defined Microsoft delegation within that plan, with the shared-tool permissions documented beside it.
mspoutpost.com/articles/gdap-and-shared-tools-who-gets-access-in-co-managed-it
Written by Owen Gallagher
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.