Managed security onboarding: acceptance before go-live

Define what operational acceptance means

Installing an agent or connecting a data source is a step in onboarding, not the entire result. The service owner should be able to explain what is covered, when work is available and what happens when a signal requires a decision. Set acceptance criteria during procurement so both parties know what they must demonstrate. Record prerequisites that the client must provide and identify the person who can accept the service. A target date should not conceal missing permissions, unsupported systems or unresolved escalation ownership.

Build a bounded inventory

Begin with platforms, approximate users and devices, important workloads, operating regions and existing suppliers. Agree which inventory becomes the coverage baseline and how exceptions are tracked. For Microsoft 365 or Google Workspace, identify the relevant tenant and administrative owner through an agreed secure channel. For AWS and other clouds, confirm the intended account and region boundaries. Avoid sending live identifiers in a public form. Ask how the provider will reconcile changes so assets do not silently drift outside the original agreement.

Approve access deliberately

List the permissions needed for review, investigation and implementation separately. Identify who grants access, who checks it and how it will be removed. Prefer a documented role and approval process to informal credential sharing. Any production change needs an owner, a suitable window and a rollback plan. Confirm how emergency access differs from routine access and who authorises its use. If a proposed permission is broader than the agreed activity, resolve the mismatch before onboarding continues rather than accepting it as a permanent convenience.

Verify the complete operational path

Use an agreed harmless exercise to demonstrate the path from source to investigation to escalation. Check that the expected evidence arrives, the intended team receives it and an authorised decision maker can be reached. Include missing-source detection and unavailable contacts in the exercise. Document what was actually observed rather than recording only that the integration succeeded. If coverage is limited during a staged rollout, make that limitation visible to the internal incident team and to anyone relying on the new service.

Close with an acceptance record

The acceptance pack should identify included systems, completed checks, known gaps, temporary arrangements and outstanding client actions. Give each exception an owner and review date. Obtain the appropriate sign-off and state when the agreed operating terms start. Schedule an early service review to compare assumptions with actual volumes and handoff quality. Onboarding evidence also creates a useful baseline for later renewal or supplier transition. Keep the pack maintainable, with a change process that survives the departure of the original project team.

For the next procurement discussion, read our related guides on Microsoft 365 service inputs and verification and closure evidence. These cover complementary decisions; technical testing still needs its own scope and authorisation.

Prepare your requirements

Use the managed security services RFP builder to select your platforms, describe existing support and review suggested workstreams. You can edit your requirements before sending them through the contact form with an NDA or RFP. Approximate counts and business context are enough initially. Do not include credentials, personal records or live incident evidence. Service hours, delivery capacity and commercial commitments must be agreed in the proposal; submitting a form does not activate a service.