Shadow IT SaaS signups bypassed controls; Netskope and ServiceNow intake with Okta Single Sign?On governed approvals

Overview

A marketing agency saw shadow IT spread quickly as teams signed up for new SaaS tools to meet client deadlines. Usage spanned design, collaboration, analytics, and ad platforms, with little visibility into where data flowed or whether contracts and security reviews existed. Intelligex deployed Netskope for SaaS discovery, stood up a Service Catalog intake for new tools, embedded a security review and Data Processing Agreement (DPA) path, and enforced decisions through single sign?on and access controls. Risky signups decreased, approvals became standardized, and vendor tracking moved into one place—while the agency kept its identity platform, procurement process, and existing SaaS stack.

Client Profile

• Industry: Marketing and creative services (multichannel campaigns and ad operations)
• Company size (range): Multi?brand agency with distributed account teams and contractors
• Stage: Google Workspace and Microsoft 365 in use; Okta for SSO; SaaS adopted ad hoc by teams; spreadsheets for vendor tracking
• Department owner: IT & Infrastructure (Cloud/Network and Identity)
• Other stakeholders: Security, Legal/Privacy, Procurement, Finance, Creative Operations, Ad Ops, Internal Audit

The Challenge

Shadow IT took root because experimentation was part of the culture. Creative and media teams trialed new tools for campaign work, link tracking, asset management, and analytics. Signups happened with corporate email, personal cards, or agency cards. Data landed in unknown locations, OAuth grants proliferated, and offboarding relied on individuals to remember which tools were connected to which accounts. Vendor spreadsheets lagged reality, and renewals surfaced as surprise invoices.

Security and Legal were stuck reacting. The team saw usage in browser history and occasional invoices, but there was no consistent discovery or intake. DPAs and terms were negotiated case by case, often after data moved into a new tool. OAuth consent to third?party apps in Google Workspace and Microsoft 365 was broad, and SSO was not required. When questions came from clients about where creative and audience data lived, answers required a scavenger hunt across inboxes and platform admin pages.

Operational friction mounted. Teams needed to move fast, but approvals took the form of email threads or after?the?fact purchase orders. Comparisons between tools were anecdotal because there was no central registry of what existed, who owned it, and which data types were involved. Deprovisioning for leavers was inconsistent, leaving behind orphaned accounts with access to client assets and data.

Why It Was Happening

Root causes were the absence of a discovery source and a governed intake workflow. SaaS usage was invisible until invoices arrived or a security incident surfaced. There was no canonical SaaS registry with owners, data types, regions, SSO status, OAuth scopes, DPA status, or renewal dates. Risk scoring and approval criteria lived in tribal knowledge rather than in policy, and exceptions were not tracked with expirations or compensating controls. Without a single path for evaluation and access control, teams defaulted to self?service signups.

Ownership and timing were misaligned. Creative Operations and Ad Ops needed tools now; Procurement and Legal needed contracts and DPAs; Security needed risk assessment and SSO; Finance needed vendor tracking. Lacking a shared pipeline that joined discovery to review and enforcement, the organization traded speed for control and then re?paid the cost during audit and client reviews.

The Solution

Intelligex implemented a shadow IT control plane that began with discovery and ended with governed access. Netskope provided SaaS discovery and risk context; a Service Catalog intake standardized new tool requests; security and privacy reviews were embedded with DPA templates and a vendor questionnaire; and decisions flowed into SSO assignment and access controls. High?risk or unknown tools were steered to the intake, while approved tools gained a standard onboarding path with owner, data types, and renewal details captured. The design leveraged Netskope for discovery and policy, the agency’s ITSM catalog and approvals (for example, ServiceNow), and industry?recognized vendor questionnaires such as the CSA CAIQ.

• Integrations: Netskope SaaS discovery and risk scoring; API visibility for Google Workspace and Microsoft 365 OAuth apps; ITSM Service Catalog and approvals; Okta SSO and SCIM for assignment and deprovisioning; Procurement’s vendor records; collaboration tools for notifications.
• Canonical SaaS registry: Standard fields for app name, category, risk score, data types processed, region/hosting, owner, business sponsor, SSO/SCIM status, DPA status, OAuth scopes, renewal date, and approved use cases.
• Risk and policy engine: Rules combining Netskope app risk with agency data sensitivities; gates for SSO requirement, OAuth scope restrictions, and DLP controls; categories requiring DPA and security questionnaire before use.
• Intake workflow: Service Catalog request pre?populated with discovery data; routing to Security, Legal, and Procurement; embedded DPA and a CSA?aligned questionnaire; reason codes and compensating controls for exceptions.
• Enforcement and onboarding: Okta as the front door for approved apps; SCIM or documented account creation; OAuth governance to restrict unapproved third?party apps; Netskope policies to block or warn on high?risk apps pending review.
• Exception handling: Time?bound approvals for trials and client?mandated tools; expiration reminders; documented limits on data and sharing; regular review to convert to approved or retire.
• Dashboards and reporting: New discoveries, unapproved usage by category, pending reviews, approved app inventory, DPA status, OAuth consent posture, and upcoming renewals; drill?downs by brand or client team.
• Audit and lineage: Immutable logs tying discovery, intake decisions, SSO assignment, OAuth restrictions, and renewals; exportable evidence packs for clients and auditors.

Implementation

• Discovery: Enabled Netskope discovery across egress paths; collected baseline usage by app, category, and team; inventoried current vendor spreadsheets, SSO assignments, and renewal calendars; gathered legal templates and client data requirements.
• Design: Defined the SaaS registry schema; authored risk and approval rules by category and data type; designed the Service Catalog form and routing with embedded DPA and CSA?aligned questions; mapped SSO and OAuth governance patterns; planned dashboards and evidence exports.
• Build: Configured Netskope discovery, app risk, and policy; created the Service Catalog intake and approval steps; built the SaaS registry and data flows from discovery and approvals; integrated Okta SSO/SCIM and OAuth restrictions; wired notifications and renewal reminders; assembled dashboards and logging.
• Testing/QA: Ran in shadow mode: flagged unapproved apps and drafted intake records without blocking; reconciled discovery to invoices and anecdotes; piloted the intake with a few teams and high?value apps; tuned risk thresholds, routing, and exception categories; verified OAuth and SSO enforcement on sample apps.
• Rollout: Turned on warnings for high?risk apps first, then enforced blocks for categories requiring review; required SSO for approved apps as they were onboarded; moved renewals into the registry with alerts; expanded OAuth restrictions after initial education and exceptions were in place.
• Training/hand?off: Delivered sessions for Creative Operations, Ad Ops, and account teams on the intake path, trial exceptions, and approved catalog; briefed Security, Legal, and Procurement on routing and evidence expectations; updated SOPs for vendor onboarding, renewals, and deprovisioning; transferred ownership of rules and dashboards to IT and Security under change control.
• Human?in?the?loop review: Established a recurring committee to review exceptions, aging trials, and app categories; decisions recorded with rationale and effective dates; outcomes fed back into policy updates.

Results

SaaS adoption moved from improvisation to a predictable path. Netskope surfaced new tools quickly, intake requests arrived with pre?filled context, and Security and Legal applied consistent gates for SSO, OAuth scopes, and DPAs. Teams still trialed tools, but trials carried limits and expirations, and approved apps were onboarded with owners, data types, and renewal details captured.

Vendor tracking and reviews steadied. The registry became the single view of what was in use, who owned it, and where data went. Renewals were anticipated with enough time for renegotiation or retirement. Client and audit questions about data location and contracts were answered from one evidence trail. Netskope, the ITSM catalog, Okta, and existing SaaS remained; the addition was a discovery?to?approval pipeline with enforcement and documentation.

What Changed for the Team

• Before: Teams signed up for tools with only a credit card. After: Discovery steered new tools into an intake with security and DPA review.
• Before: Vendor lists lived in spreadsheets. After: A SaaS registry tracked owners, data types, SSO, DPA status, and renewals.
• Before: OAuth permissions were wide open. After: Unapproved apps were restricted, and approved apps used scoped access.
• Before: SSO was optional. After: Approved tools required SSO and, where possible, SCIM for onboarding and offboarding.
• Before: Trials became permanent by default. After: Exceptions were time?bound with reminders and conversion or retirement decisions.
• Before: Client and audit questions triggered a scramble. After: Evidence packs tied discovery, approvals, and enforcement in one trail.

Key Takeaways

• Start with discovery; you can’t govern what you can’t see.
• Standardize intake; use a Service Catalog to route new tools through security, legal, and procurement with embedded templates.
• Bind policy to enforcement; require SSO, restrict OAuth, and apply DLP where appropriate for approved apps.
• Track what matters; maintain a registry with owners, data types, DPAs, and renewals to avoid surprises.
• Allow experiments safely; permit time?bound trials with limits and clear conversion paths.
• Integrate, don’t replace; keep Netskope, your ITSM, and identity provider, and add a governed pipeline around them.

FAQ

What tools did this integrate with? Netskope provided SaaS discovery, risk scoring, and policy enforcement (Netskope). The intake and approvals ran through the ITSM Service Catalog (for example, ServiceNow). Okta handled SSO and SCIM onboarding/offboarding. Google Workspace and Microsoft 365 OAuth app governance fed visibility and restrictions. Vendor questionnaires aligned to the CSA CAIQ.

How did you handle quality control and governance? Risk and approval rules lived under change control with owners and rationale. The registry captured owners, data types, and DPA status. Exceptions required maker?checker approvals, time?bounded expirations, and compensating controls. All discovery events, intake decisions, SSO assignments, OAuth restrictions, and renewals were immutably logged with evidence exports for audit and client reviews.

How did you roll this out without disruption? Discovery and intake ran in shadow mode first, with warnings instead of blocks. A pilot cohort used the intake for new tools, and SSO was required for newly approved apps. After education and tuning, blocks were enabled for high?risk categories and OAuth restrictions were tightened. Trials were supported through a documented exception lane to keep experimentation viable.

How were DPAs and security questionnaires handled? The Service Catalog embedded DPA templates and a CSA?aligned questionnaire. Legal and Security received the same request context and vendor responses. Approvals tracked DPA status and any required contract terms. Renewals pulled the prior evidence to avoid re?collecting unless something changed.

What about tools mandated by clients or short?term campaigns? A time?bound exception path supported client?mandated apps and rapid campaigns. Requests captured the client requirement, data scope, and duration. Netskope policies and SSO/OAuth controls constrained access, and reminders triggered review to convert or retire the app after the campaign.

Did this slow teams down? The goal was a fast, governed path. Discovery pre?filled intake requests, standard questionnaires avoided bespoke emails, and approved apps appeared in the catalog for one?click assignment. Trials were still possible, but with clear limits and visibility.

How did you manage deprovisioning and offboarding? Approved apps used SSO and SCIM where available to remove access automatically when people left or changed roles. The registry listed apps and owners to handle edge cases, and OAuth governance removed third?party access no longer needed.