What information should you give a managed SOC at onboarding?

At onboarding, a managed SOC needs five types of information: who to contact and in what order, the list of critical assets, normal activity that might look suspicious, technical access to the sources being connected, and business constraints such as operating hours and regulatory duties. Without them, the SOC sees events; with them, it understands what matters and knows who to call.

This article is part of our series How do you implement a managed SOC?. It covers the preparation step, just before connection.

The onboarding checklist

Type	Examples	Why the SOC needs it
Contacts	MSP and client leads, out-of-hours numbers, deputies, call order	Reach the right person fast, even at 3am
Critical assets	Business servers, privileged accounts, executives, service accounts	Prioritise alerts that touch what matters
Normal activity	Remote admin tools, scheduled scripts, travel, third-party providers	Avoid false alarms without hiding real ones
Technical access	EDR console, Microsoft 365 or Google Workspace tenant, firewall	Connect sources and, where agreed, act through the EDR
Business constraints	Production hours, sensitive periods, applicable regulation	Choose the right containment at the right time

1. Contacts and call order

This is the most important information and the most often out of date. For each client you need:

• a technical lead at the MSP, plus a deputy;
• an out-of-hours and weekend contact;
• a decision-maker at the client who can authorise a disruptive action;
• the call order by severity.

These contacts feed the escalation procedure. See How to build a SOC escalation procedure.

2. Critical assets

Not all machines are equal. An alert on the payroll server or the finance director’s account weighs more than one on a test laptop. Tell the SOC about:

• servers and applications whose outage stops the business;
• privileged accounts (administrators, service accounts);
• exposed people: executives, finance, HR.

3. Normal activity

This is the key to limiting false positives. A remote support tool used by the MSP looks very much like an attacker’s. List:

• the admin and remote support tools in use;
• scheduled tasks and regular scripts (backups, deployments);
• third parties who connect, and from where;
• staff who travel or work from abroad.

See How to handle false positives when a SOC starts.

4. Technical access

Cyna integrates natively with SentinelOne and Microsoft Defender, and ready-made connectors cover Microsoft 365, Google Workspace, Stormshield and Fortinet. You therefore need admin rights on these consoles on connection day.

Two checks avoid delays: Microsoft 365 auditing, which Microsoft says is not on by default for some Business licences, and clock synchronisation across devices, which ANSSI recommends for a reliable timeline. See How long does it take to deploy a managed SOC?.

It is good practice to create dedicated accounts for the SOC with the minimum rights needed, and not to share them in clear text by email.

5. Business and regulatory constraints

Isolating a laptop is routine; shutting down a production server during month-end close is not. The SOC needs to know:

• the business’s critical hours and periods;
• systems that are never shut down without approval;
• the applicable regulation. For entities in scope of NIS2, Article 23 provides for an early warning within 24 hours of becoming aware of a significant incident, so it helps if the SOC knows who receives its findings. See Does a managed SOC help with NIS2?.

Keeping it current

Onboarding information ages quickly: a lead leaves, a new server arrives, a supplier changes. Plan a review after every significant change and at least during regular client reviews. Name someone at the MSP who owns these updates, or nobody will.

A forgotten update is among the most common pitfalls: see Managed SOC implementation mistakes to avoid. For the split of roles, see Managed SOC and MSP: who does what?.

Talk to an expert

Getting ready to onboard a managed SOC? If you already work with a Cyna partner, they are your first point of contact. Otherwise, get in touch.

Frequently asked questions

Should you send passwords to the SOC?

No. Access goes through connectors or dedicated accounts created for the purpose, with the minimum rights needed. Passwords should never travel by email.

Does the SOC see employees' personal data?

It processes logs that contain some (usernames, IP addresses). This processing falls under GDPR, whose Article 28 covers the use of a provider that processes data on an organisation's behalf. How this framework applies to your situation and contracts is best checked with your DPO or legal adviser.

Who provides this information, the MSP or the client?

The MSP gathers most of it, as it runs the IT environment. The client adds what only it knows: critical business assets, operational constraints and who to inform at management level.

What if the inventory is incomplete?

Start with what you know and fill the gaps as you go. Monitoring endpoints and cloud services often uncovers forgotten assets. For a deeper review, see Do you need an assessment before a managed SOC?.