Your SOC runs on a defined stack. Each client you protect runs something different. When a security incident triggers in a client environment- a Dynatrace problem crossing the AVAILABILITY threshold, a suspicious authentication event in their ServiceNow, a vulnerability flagging Critical in their scanning module - that event needs to land in your SOC tooling immediately, with full context, and without any of the client's internal infrastructure data leaking into a system it was never meant to reach.

The challenge is not connectivity. Connecting Dynatrace to ServiceNow via a webhook takes minutes. The challenge is every field inside that webhook payload. A Dynatrace problem notification contains the problem title, the severity level, and the affected application name. It also contains the full impacted entity list with internal hostnames, the raw problem evidence stream, the complete topology of affected services, and in some configurations, the Dynatrace environment ID and tenant references. If your field mapping sends the whole payload, you have just deposited a map of the client's internal infrastructure into your MSSP's ITSM.

This is the MSSP version of the data contract problem. The same structural failure that causes MSP integrations to break - undefined boundary rules, uncontrolled field mapping, no semantic translation layer -causes MSSP integrations to create new security exposure. The difference is that MSP failures typically surface as SLA disputes. MSSP failures can surface as breach disclosures.

‍

‍

Why MSSPs Have a Harder Version of the Integration Problem

MSPs deal with tool diversity. MSSPs deal with tool diversity plus data sensitivity plus regulatory exposure plus per-client contractual confidentiality obligations. The operational complexity is structurally similar: your internal stack versus each client's stack, multiplied across your entire book of business. The risk profile is categorically different.

Three realities define the MSSP integration environment in 2026.

First: the scope of MSSP responsibility has expanded. A growing proportion of MSSPs now manage the combined IT and security estate fortheir clients, not just the security layer in isolation. This means theintegration boundary is not just SOC-to-SIEM - it is SOC-to-ITSM, monitoring-to-incident-management, vulnerability-management-to-remediation-tracking. Multiple data flow types, multiple sensitivity classifications, multiple compliance obligations.

Second: the threat model for MSSPs has changed. Recent threat intelligence is unambiguous: attackers increasingly target MSSPs as the fastest path to multiple client environments simultaneously. An MSSP integration that passes authentication context, identity fields, or infrastructure topology data across the boundary without field-level controls is not just a compliance gap. It is a lateral movement path for an attacker who has already gained access to one side of the integration.

Third: the regulatory environment is tightening specifically around supply chain and third-party access. NIS2, which came into force for EU-covered sectors in October 2024, explicitly extends security obligations to the supply chain, including managed service and managed security service providers. An integration that moves client security data without a defined contract is a reportable gap under NIS2 Article 21 supply chain securityrequirements.

The data contract approach described in our MSP article applies here, but the content of the contract is different. The excluded fields list is longer, the directionality rules are stricter, the regulatory context is mandatory rather than advisory, and the audit trail requirements are tied to incident response obligations rather than just operational continuity.

‍

The Four Integration Patterns MSSPs Actually Run

Unlike MSP ticket syncs, MSSP integrations span four distinct data flow types, each with a different sensitivity profile and boundary requirement. Getting one wrong does not just break the workflow - it can expose the client's security posture, your SOC's internal methodology, or both.

Pattern1: Alert-to-incident routing (monitoring to SOC ITSM)

Detection and observability tools in the client environment --Dynatrace, Datadog, SolarWinds, Prometheus - generate problems and alerts that need to become actionable incidents in the MSSP's SOC ITSM (ServiceNow, Jira, BMC Remedy) within seconds of detection. This is the highest-volume pattern and the one most commonly misconfigured.

The Dynatrace webhook payload is the canonical example. When Dynatrace detects a problem, it pushes a notification to ZigiOps' Web Listener endpoint. The payload contains everything Dynatrace knows about the problem at that moment:

{

 "problem_title":  "{ProblemTitle}",

 "problem_details":  "{ProblemDetailsText}",

 "status": "{State}",

 "severitylevel":  "{ProblemSeverity}",

 "impactlevel":  "{ProblemImpact}",

 "rankedimpacts":  {ImpactedEntities},

 "tagsofaffectedentities":  "{Tags}",

 "problem_url":  "{ProblemURL}",

 "id": "{PID}"

}

The fields that should cross the MSSP boundary: problem_title (incident summary in ServiceNow), severitylevel (maps to ServiceNow priority via conditional mapping), status (OPEN triggers incident creation; RESOLVED triggers closure), and id (the Dynatrace problem ID, written to a custom field for cross-reference). The fields that must not cross: rankedimpacts (contains the full impacted entity list with internal hostnames and service topology), tagsofaffectedentities (can contain internal environment labels, team names, and infrastructure tags), and problem_details (raw evidence text that may reference internal IP addresses, hostnames, and service dependency chains).

The ZigiOps field map for this pattern explicitly maps only the four permitted fields. Everything else is excluded by omission - if it is not in the field map, it does not move. The Respond Field Map writes the ServiceNow incident number back to Dynatrace as a comment, establishing the cross-reference for the audit trail without persisting the incident data in the client's Dynatrace environment.

Technical note: ZigiOps' Web Listener triggers on the incoming Dynatrace webhook in real time - no polling delay, no batch  window. The listener endpoint URL is configured in Dynatrace under Settings  > Integration > Problem Notifications as a Custom Integration. The  payload format shown above is the required ZigiOps custom payload structure.

Pattern2: Security incident escalation (client ITSM to MSSP SOC)

A security incident in the client's ITSM reaches a severity threshold - Critical priority, high-risk classification, a specific incident category - that requires MSSP involvement. The escalation needs to move to the MSSP's incident management system immediately, with the context required for triage, but without the client's internal threat data, investigation notes, or affected user identities leaving the client environment.

Example: ServiceNow Security Incident Response (SIR) record at the client site triggers an escalation to the MSSP's Jira. The ZigiOps trigger condition on the client's ServiceNow collects only records matching all three conditions: category = 'Security Incident', state = 'Analysis' (numeric value 2in ServiceNow SIR), AND priority = 1 (Critical). This is a conjunction filter-- a record must match all three conditions to be collected. Records that meet two of three are ignored.

The field map to MSSP's Jira carries: short_description (Jirasummary), category (mapped to a Jira custom label), subcategory (mapped to a Jira component), affected_ci (the asset name only, not the full CMDB record),and sys_created_on (detection timestamp). The Respond Field Map writes the Jira issue key (e.g., SEC-4821) back to the ServiceNow SIR's correlation_id field. Every subsequent update to the Jira issue writes a status update back to the ServiceNow SIR's work notes as a public comment.

Excluded fields on this pattern: work_notes (client's internal investigation notes), close_notes when state is not Resolved, assigned_to (client analyst identity), threat_intelligence_indicator (any linked threat intel records), and attachments (evidence files stay in the client environment).

Pattern3: Vulnerability data handoff (client scanning to MSSP remediation tracking)

Vulnerability scan results from the client environment flow into the MSSP's remediation tracking or risk register. This is the highest-riskdata flow in the MSSP stack. Vulnerability records combined with the asset inventory they reference constitute a near-complete attack surface map. An integration that passes unfiltered vulnerability data into a shared MSSP system creates a target that, if accessed by an attacker, exposes every client's highest-priority weaknesses simultaneously.

The field contract for this pattern is the most restrictive. Permitted fields: vulnerability name, CVSS base score, affected CI name (the application or server label, not the full CMDB record with network relationships), remediation status, and first_found timestamp. Excluded: full CVE details and exploit references (the client's security team owns prioritization), internal patch management notes, affected user accounts associated with the vulnerability, network path data, and any field that references the client's internal asset naming conventions beyond the single affected CI.

The ZigiOps trigger condition for this pattern typically uses a CVSS score filter: only collect records where risk_score >= 7.0 (High orCritical) AND state = 'Open'. This reduces the volume to the records the MSSPneeds to act on and excludes the lower-severity informational findings thatwould inflate the data crossing the boundary without adding remediation value.

Pattern4: SOC-to-client status reflection (MSSP resolution back to client)

Once the MSSP's SOC takes action on an incident or completes are mediation task, the client needs visibility into what happened -- resolution status, closure timestamp, a public-facing summary. This is the inverse of the previous patterns: data flows from MSSP to client, and the boundary controls are equally critical in this direction.

The MSSP's Jira security ticket transitions to 'Done'. ZigiOps detects the status change via the configured trigger and maps back to the client's ServiceNow SIR. The field map to client ServiceNow carries: resolution status (mapped to ServiceNow closure state), a resolution summary (public-facing only, written to the work_notes field as an external comment),and closed_at timestamp. Excluded from the MSSP-to-client direction: all internal Jira fields (sprint, story points, internal labels, assignee), MSSP SOCteam assignment details, internal triage notes, and any reference to the MSSP'sinternal playbook or response methodology.

Why this direction  matters: MSSPs often focus their data contract on the inbound direction (client data into  SOC) and treat the outbound direction (SOC status back to client) as low-risk. But a client environment that has been partially compromised is an active threat to any data flowing into it. The outbound field map should be as controlled as the inbound one.

‍

‍

Three MSSP-Specific Integration Failure Modes

The five failure modes from the MSP data contract article(note leakage, priority scale collisions, status loops, timestamp misalignment, mandatory field injection) apply to MSSP environments as well. These three arelayered on top, specific to the security data context.

1.Monitoring tool payloads carry the client's infrastructure map

Dynatrace, Datadog, and SolarWinds send rich event payloads that contain substantially more than an incident summary. The Dynatrace {ImpactedEntities} field, for example, returns a structured JSON array of every entity Dynatrace has identified as affected by or contributing to the problem. In a well-instrumented client environment, this can include dozens of internal hostnames, application service names, infrastructure component labels, and dependency relationship data.

A field mapping that sends the full problem_details text or the rankedimpacts array to the ServiceNow incident description is not a misconfiguration in any technical sense -- the API accepts it, the data moves, the incident is created. It is a boundary violation. The client's internal service topology is now sitting in a ServiceNow text field in the MSSP's environment, visible to every agent with access to that ITSM queue.

The correct configuration treats the Dynatrace payload as a source from which specific fields are extracted, not as a block to be forwarded. In ZigiOps, the field map explicitly lists what is mapped: {problem_title} to short_description, {severitylevel} to the conditionalpriority mapping, {status} to the trigger condition for create vs. close, {id} to the cross-reference field. The rankedimpacts, tagsofaffectedentities, andproblem_details fields are not in the field map. They never touch the target system.

‍

‍

2. Identity fields create cross-environment compliance exposure

Security incidents frequently include user identity data: the account that triggered the detection, the analyst assigned to the investigation, the user associated with the affected CI. When these fields cross the MSSP-client boundary in either direction, they create compounding problems.

From client to MSSP: the MSSP's systems now hold client employee identity data. Under GDPR Article 25 (data protection by design and by default), processing personal data beyond its defined purpose requires explicit justification. An integration that copies the assigned_to field from a client's ServiceNow SIR into the MSSP's Jira as a custom field is processing personal data without a clear purpose limitation. For MSSPs operating under a Data Processing Agreement with EU-covered clients, this is a contractual violation regardless of whether a breach occurs.

From MSSP to client: the MSSP's Jira tickets often show internal SOC analyst names in the assignee field. If the status reflection integration maps the Jira assignee back to a field in the client's ServiceNow, the client's ITSM now contains the identities of specific MSSP SOC personnel. In a scenario where the client environment is actively compromised, this is operational security data that should not be available to the attacker.

The data contract rule for identity fields: excluded from bidirectional sync by default. Where contractually agreed to pass, map to a role-based identifier (e.g., 'MSSP SOC Team' rather than'analyst.name@mssp.com'). Never pass personal identifiers across the boundary unless the purpose is defined in the DPA and the field is mapped to an equivalent anonymized value.

3. Audit trail gaps compromise incident response evidence

During a security incident, the audit trail is not just an operational record. It is potential legal and regulatory evidence. Incident response under NIS2 requires organizations to be able to demonstrate the timeline of detection, escalation, and remediation. An MSSP that manages the SOC function for an in-scope client is part of that evidence chain.

An integration that creates incidents, updates status fields, and closes records without maintaining bidirectional cross-references producesa disconnected timeline. The MSSP's Jira shows a resolved ticket. The client's ServiceNow SIR shows an open record. Neither system can establish which action in which system corresponded to which moment in the incident sequence. In a post-incident review - or a regulatory inquiry - this gap is a finding.

The Respond Field Map in ZigiOps is the mechanism that prevents this. After each integration action completes successfully, the Respond Field Map writes the target system's record identifier back to the source record. After creating a Jira issue from a ServiceNow SIR, ZigiOps writes the Jira issue key (SEC-4821) to the ServiceNow correlation_id field. After a Jira status update triggers a ServiceNow work note, ZigiOps confirms the write. Every record in both systems carries a cross-reference. The incident timeline can be reconstructed from either side, with timestamps, record IDs, and action sequence intact.

‍

‍

The MSSP Data Contract Template

The data contract structure from the MSP article applies here, extendedwith the security-specific dimensions that MSSP environments require. The additions are not optional enhancements - they are the fields that separate a defensible integration from a liability.

‍

‍

Client review  requirement: Unlike  the MSP data contract, the MSSP version should be reviewed by three parties  before configuration begins: the MSSP's security architect, the client's  security team, and where applicable, the client's legal or compliance team. This is not bureaucratic overhead - it is the documented evidence that the integration design was deliberate and reviewed.

Architecture Considerations for Security-Sensitive Environments

On-premises deployment for regulated clients

MSSPs operating in regulated sectors - financial services, healthcare, energy, government - frequently cannot route security telemetry through a cloud-hosted integration layer. Security policy, contractual obligations, or the client's own regulatory requirements (SOC 2, ISO 27001,HIPAA, NIS2 implementation in national legislation) may require all data processing to remain within a defined perimeter.

ZigiOps supports on-premises deployment behind the MSSP's or client's firewall. The connectivity model is outbound-only: ZigiOps makes outbound API calls to connected systems, and receives inbound webhook pushes from monitoring tools like Dynatrace. No inbound firewall rules are required into the client's network from the MSSP side. Transport is encrypted via TLS.Authentication credentials are encrypted at rest using FIPS 140-2 compliant AES/CBC with a 256-bit key.

This is the 'no new inbound exposure' model. From the client's security team's perspective, the integration does not open new ports, does not require inbound access from the MSSP's infrastructure, and does not create a new attack vector into the client environment. The Dynatrace webhook pushes outbound to the ZigiOps listener. Every other integration action is an outbound API call from ZigiOps to the target system.

Separate integration instances per client

In an MSSP environment managing 20 or more client integrations, running all client workflows through a single ZigiOps instance creates a cross-client data risk. A misconfigured trigger condition that failsto filter by client-specific attributes could theoretically collect recordsfrom one client's integration context and route them to another client's ITSM.

The recommended architecture: separate connected system configurations per client, with integration templates that include client-specific filter conditions as mandatory elements. In ZigiOps, connected systems are isolated configuration objects. A Dynatrace connected system for Client A and a Dynatrace connected system for Client B are entirely separate, each with their own server URL, API token, and integration actions. There is no shared state between them.

ZigiOps is a standalone application, not a plugin or a shared multi-tenant SaaS layer. This means the MSSP controls the deployment boundary. Client A's integration instance can be isolated at the network level if required. It does not share runtime processes, configuration storage, or credential context with Client B's instance.

Configurable data retention aligned to incident response obligations

ZigiOps does not store transferred records on disk or in a database. Data flows through the platform in memory. The only data retained is troubleshooting payload data -- HTTP request and response logs -- which is configurable in the General Settings panel with a defined purging interval. For MSSPs, this interval should be set in alignment with the client's DPA and the relevant incident response retention requirements.

Under NIS2, significant incidents must be reported to the relevant national authority within 24 hours (early warning) and 72 hours(formal notification). The MSSP's integration layer should retain enough troubleshooting context to support this reporting window without retaining data beyond the contracted period. The ZigiOps troubleshooting data purging intervalis the configuration lever for this: set it to cover the reporting window, not indefinitely.

‍

‍

Regulatory Context MSSPs Cannot Route Around

The regulatory dimension of MSSP integrations is not an edge case for compliance-heavy industries. It applies broadly to any MSSP managing security functions for clients in the EU, and increasingly to those serving US federal, state, and regulated private sector clients.

NIS2: Supply chain security obligations

NIS2 Directive Article 21 requires essential and important entities to implement security measures for their supply chain, including the security practices of direct suppliers and service providers. MSSPs serving NIS2-covered entities are in scope as supply chain participants. The directive explicitly requires that the security of network and information systems used to deliver managed services is maintained.

An integration layer that passes security telemetry and incident data across the MSSP-client boundary without defined controls is asupply chain security gap that a covered entity's competent authority could identify during an audit. The data contract - documented, reviewed, and enforced through configuration -- is the evidence that the MSSP has implemented appropriate controls at the integration layer.

GDPR: Identity fields and data minimisation

GDPR Article 5(1)(c) requires that personal data be 'adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed' (data minimisation). GDPR Article 25 requires that data protection by design and default be implemented at the system architecture level, not bolted on after the fact.

An MSSP integration that maps the assigned_to field from a client's ServiceNow SIR to the MSSP's Jira ticket is processing personal data(an employee name or identifier) without a clear purpose limitation. Unless the DPA between the MSSP and client explicitly covers this transfer and defines the purpose, it is a Article 5 and Article 25 gap. The data contract's identity field exclusion rule is the Article 25 implementation.

Contractual DPAs: The per-client compliance layer

Above the regulatory floor, most MSSP contracts include explicit Data Processing Agreements that define what client data the MSSP can access, store, and process. These DPAs pre-date NIS2 and GDPR for most established MSSPs, and they are the most immediately enforceable layer.

The integration data contract needs to be reviewed against the DPA before configuration begins. A DPA that restricts data processing to 'security incident management activities' creates a clear exclusion for vulnerability detail, CMDB data, and infrastructure topology -- even if those fields are technically available in the integration payload. The data contract is the mechanism that aligns the technical integration to the contractual scope.

MSSP Tool Combinations and ZigiOps Integration Patterns

The following combinations represent the most common MSSP integration patterns in 2026, all supported by ZigiOps with no-code configuration. Each combination lists the primary data boundary rules that should appear in the data contract.

‍

‍

ZigiOps integration  note: All combinations above use ZigiOps' 100% no-code configuration. Dynatrace uses  the Web Listener trigger (real-time webhook push). PagerDuty, ServiceNow,  Jira, BMC Remedy, Datadog, and SolarWinds support both Web Listener and  Poller triggers depending on the workflow. No scripts, no custom connectors,  no plugin dependencies on the client's ITSM instance. ZigiOps deploys as a  standalone application -- the MSSP installs it in their own environment and  it connects to client tools over the existing API layer.

Build the Contract Before You Build the Integration

The sequence that makes MSSP integrations defensible is the same as for MSPs, applied to a dataset where every unchecked field has a compliance implication.

Before configuring any integration action: produce a per-pattern data contract that covers permitted fields and their directionality, the full exclusion list by field name, the semantic translation rules for severity and status values, the identity field policy (excluded by default, role-based where contractually permitted), the cross-reference ID mechanism for the audit trail, and the data retention setting aligned to the relevant DPA and reporting obligation.

Review it with the client's security team, the MSSP's securit yarchitect, and where applicable the client's compliance or legal function. Then enforce it at the source filter layer (what ZigiOps collects), the field mapping layer (what it sends), and the Respond Field Map layer (what it writes back). Document the configuration so that it can be audited, replicated per client, and updated when the client's DPA is renegotiated.

The integration layer is now part of the MSSP's security architecture. Treat it like one.

Further reading: MSP Data Contract  Article - Why Integrations Break: Not the API, the Data Contract