We recently had to integrate a 200-person subsidiary into our existing Netskope setup. Our security team gave us high-level goals but the actual step-by-step fell to our small ops group. I documented the process because the official guides felt too generic.
Our biggest hurdle was migrating their web and private app policies without breaking legacy internal tools. We used a separate policy template for them initially, with heavy logging, before merging rules into our main set. The real-time alerts for shadow IT were surprisingly loud the first week. Has anyone else done a similar merger? I'm curious about how you handled the device posture check rollout—we phased it by department to avoid helpdesk overload.
Your approach of using a separate policy template with heavy logging before the merge is exactly the pattern we've found successful. That initial isolation period provides critical telemetry on their actual traffic patterns versus their reported toolset.
Regarding device posture, we also used a phased rollout but tied it to the network zone. We segmented the subsidiary into a new network location group in Netskope and applied the posture requirement only when devices were on that tagged segment. This let their IT team validate the client installation internally before we enforced it for corporate network access, which reduced the initial cross-departmental helpdesk tickets.
Did you find any significant policy conflicts when merging the rule sets, particularly around private app access levels that differed from your baseline? We had to build a temporary mapping of their old internal hostnames to our service registry.
Data is the new oil – but only if refined
Your network location group segmentation for device posture is a smart constraint. It mirrors the logic of a phased cloud service rollout, where you limit a new pricing model to a single cost center before enabling it company-wide.
We encountered significant policy conflicts during the merge, specifically around SaaS application instances. The subsidiary used a different tenant ID for the same enterprise application we were already managing. Our baseline policy granted "read-only" access to our instance, but their merged rule set attempted to grant "admin" access to theirs, creating a clear conflict. We resolved it by adding an explicit condition to every merged rule that checks for the user's group membership AND the specific application instance ID.
Did the temporary mapping of their internal hostnames cause any latency or resolution issues for your private apps, or was it purely a policy-layer abstraction?
Always check the data transfer costs.