Shadow IT: turn discovery into accountable ownership

A team adopts a tool because it solves a real problem. The security issue begins when the organization's inventory, contracts, and access processes do not reflect that use. An application can become essential to a business process before anyone has decided who administers it, what data it may hold, or how to retire it.

Shadow IT includes services, applications, and devices used outside established approval or management processes. Discovery should lead to a proportionate decision and a named owner, not simply a longer list of suspicious domains.

For a CTO, the objective is operational: understand the dependency, contain unacceptable exposure, and give the business a workable route to managed technology.

Define the boundary before collecting signals

Shadow IT is a management condition, not a category of inherently unsafe products. A reputable collaboration service can be unmanaged when employees create personal workspaces. A personal laptop can be legitimate under a controlled bring-your-own-device arrangement. Conversely, a purchased service may still be outside effective management if nobody controls its administrators or offboarding.

Look beyond unfamiliar software names. Relevant examples include:

• Personal cloud storage, messaging accounts, and password managers used for company information.
• Browser extensions, AI meeting assistants, and transcription services with access to corporate content.
• Third-party applications connected to email, calendars, repositories, or file storage through OAuth.
• Unmanaged laptops, removable storage, network devices, and remote-access utilities.
• Team-owned cloud accounts, low-code applications, and automation scripts that support production workflows.

Approved applications can also develop unmanaged uses. A new integration, public-sharing setting, or AI feature may change the original risk assessment without changing the product name.

Start with one business process or department. Define which accounts, endpoints, networks, suppliers, and data flows belong to the first review. This makes findings actionable and exposes gaps in the method before organization-wide collection begins.

Build a picture from several sources

No single discovery source shows every tool. Identity records miss local accounts; spending records miss free services; network logs may show a destination without explaining what information went there.

Use complementary sources and retain the provenance of each finding.

Explain why discovery is happening, what will be collected, who can inspect it, and how long it will be retained. Follow applicable privacy and employment rules. Prefer metadata sufficient to identify the service and its access over collecting message bodies, recordings, or personal browsing content. Restrict access to discovery records themselves.

Ask teams practical questions: where do you share large files, record meetings, translate documents, collect customer feedback, or automate repetitive tasks? Ask which tools would interrupt work if removed tomorrow. These questions reveal dependencies that a domain list cannot.

Normalize findings before counting them. A vendor may have several domains, products, workspaces, and billing entities. Separate product identity from tenant identity, and distinguish evidence of installation, authorization, login, and confirmed business use. Record uncertain findings as candidates rather than declaring every observed destination an unauthorized application.

Turn each finding into an ownership record

A useful register describes the use, not just the vendor. Two teams using the same product may have different data, access, contracts, and consequences.

For each confirmed use, capture:

• Product, supplier, tenant or workspace identifier, and discovery source.
• Business purpose, dependent process, user population, and criticality.
• Data categories, data sources, destinations, sharing settings, and retention.
• Account types, administrators, authentication, integrations, and granted permissions.
• Contract holder, subscription plan, renewal details, and relevant processing arrangements.
• Business owner, technical custodian, reviewer, proposed treatment, and review date.

The business owner justifies the need and coordinates acceptable use. The technical custodian manages configuration, access, integrations, and retirement. Security assesses risk; procurement and privacy specialists review matters within their remit. These responsibilities can sit with the same person in a small organization, but they should remain explicit.

If nobody will own a service, do not classify it as approved merely because users like it. Assign a temporary accountable sponsor and a decision deadline. Record what remains unknown and who will resolve it.

Follow the data as well as the application. A tool may receive uploads, synchronize entire folders, create transcripts, or send content to another provider. Our data-discovery guide explains how to trace those relationships.

Inspect OAuth access separately from application usage

OAuth lets an application obtain authorized access without receiving the user's password. That is useful, but the authorization can be broader or longer-lived than the task requires. Signing in to an application and granting it access to corporate resources are different events.

For each connected application, inspect the publisher or client identity, granting user, resource, scopes, consent type, and grant date where available. Distinguish delegated access exercised on behalf of a user from application permissions that can operate without an interactive user. Examine refresh-token behavior and whether authorization can continue after the user stops actively using the tool.

Prioritize grants that permit mailbox reading, file modification, directory access, repository changes, or broad access across users. Check whether the requested scopes match the stated purpose. A scheduling utility requesting calendar access raises a different question from one requesting mailbox contents and unrestricted file access.

As a practical control, restrict high-impact consent to administrators or a review workflow where the platform supports it. Review newly granted permissions and changes to existing applications, not only new application registrations.

Removing a browser extension or disconnecting a user-facing integration may not remove every grant, token, or external data copy. Verify revocation in the resource platform and supplier account. Encrypted transport is not proof that an integration is safe, nor does it make all inspection impossible; visibility depends on the controls and telemetry available.

Prioritize by exposure and business dependency

Use triage to decide what needs attention first. Avoid treating every unapproved tool as equally urgent.

Assess the sensitivity and volume of information involved, breadth of access, external sharing, device posture, administrative control, and evidence of compromise. Also consider availability: an undocumented automation might be the only route for sending orders to a supplier.

A public design-reference tool used without uploads may need lightweight registration. An AI meeting assistant with calendar access, recordings, and customer discussions needs a deeper review of permissions, storage, retention, and downstream processing. An unmanaged remote-access service on a production system warrants prompt containment and investigation.

Record a specific risk scenario, not “shadow IT risk.” For example: “A former employee retains workspace administration and can export customer proposals.” That statement points toward an owner, a control change, and a test.

Discovery is not automatically evidence of a breach. If findings indicate unauthorized disclosure or compromise, move into the incident process while preserving relevant logs. Where personal data is involved, notification assessment depends on the circumstances and organizational role under GDPR Articles 33 and 34, not simply on whether the tool was approved.

Choose a treatment that preserves the business need

Every decision needs an owner, rationale, completion criteria, and follow-up. Four treatments are useful in practice.

Approve and bring into management

Approval should describe permitted use, not grant unrestricted permission for the product. Establish company-controlled administration, suitable authentication, least-privilege access, joiner–mover–leaver handling, and supported configuration. Check logging, sharing restrictions, recovery or export options, and retention against the use case.

Review the supplier and contract where applicable. If the supplier processes personal data on the organization's behalf, assess the required processor arrangements under GDPR Article 28. International-transfer arrangements require a separate assessment; a selected hosting region does not settle every question. Article 32 security measures are risk based, not a universal checklist satisfied by one setting.

Keep approval evidence: configuration exports, administrator assignments, access tests, contractual review, and the accepted residual risk.

Replace with a suitable alternative

Replacement works only if the alternative meets the actual need. Test file limits, external collaboration, accessibility, automation, and required integrations before mandating migration.

Define the migration sequence, reconcile records, and confirm users can complete the workflow. Preserve required records and relevant metadata. Check shared links and integrations after cutover, then close the old tenant rather than merely stopping payment.

Remove unjustified use

For a tool without a defensible purpose or with unacceptable exposure, stop new use and plan removal. Revoke grants and tokens, remove extensions or software, disable accounts, close sharing links, and address data already exported. Rotate exposed credentials where the findings justify it.

Deleting an account is not evidence that all supplier-held information has disappeared. Obtain the available deletion evidence and document contractual retention, backups, or other limitations. Preserve information subject to required retention or legal holds.

Allow a controlled, temporary exception

A business-critical tool may need a transition period. Specify allowed users and data, compensating controls, an accountable risk acceptor, expiry, and exit conditions. Restrict further expansion where practical. A permanent “temporary” exception without review is an unresolved management gap.

Worked example: an AI meeting assistant

Consider an illustrative organization reviewing its sales process. Assume eight employees use a free meeting assistant through individual accounts. Interviews confirm that it records customer calls; an identity export shows calendar grants. No procurement record exists, and a sales manager relies on transcripts for handovers.

The first decision is to pause additional recordings and users while determining what was captured. Security records the grants and account identities. The manager identifies affected meetings and the operational need. Privacy and procurement review the processing arrangements, participant information, supplier terms, retention, and any relevant transfer arrangements. The team also checks whether recordings or transcripts are publicly accessible and whether the service uses content for other purposes.

Assume the review finds that the free plan cannot provide company-controlled administration or the required retention settings. The decision is replacement, not abandonment of the handover process. Sales tests an approved alternative with suitable access and recording controls, while the technical custodian revokes the old calendar grants and migrates permitted records.

Closure evidence includes the affected-account list, configuration of the replacement, grant-revocation results, checks of old sharing links, and available deletion confirmations. Any unresolved backup-retention limitation remains recorded. The sales manager owns acceptable use; IT owns configuration and offboarding. The review ends with a managed process, not merely a blocked application.

Prevent the next blind spot with a usable intake process

Teams often adopt tools to overcome slow approvals, missing features, or friction in existing systems. Discovery should identify those causes. Otherwise, removal simply moves the same activity somewhere less visible.

Make requests easy to submit. Ask for purpose, users, data categories, integrations, urgency, and a business owner. Publish the criteria that trigger deeper review and provide a practical route for low-risk trials. Give requesters a status and expected decision point; do not leave requests in an unexplained queue.

Teach concrete behaviors: ask before connecting a service to corporate email, avoid uploading customer information to an unreviewed tool, and report an existing workspace before renewing it. Give teams a disclosure route focused on fixing gaps rather than punishing good-faith reporting.

Keep monitoring changes after approval. Review new OAuth grants, administrative changes, external sharing, newly enabled AI features, and expansion into more sensitive data. As a practical recommendation, combine event-driven checks with periodic owner confirmation. Review frequency should reflect exposure and business criticality, not a universal interval.

Make the evidence useful for the ISMS

ISO/IEC 27001 concerns a scoped information security management system. Shadow IT findings can inform asset management, supplier review, access controls, risk assessment, and treatment. Control selection remains risk based; an application list is neither an ISMS nor proof that controls operate.

Keep the discovery scope, assessment, treatment decision, implementation evidence, and effectiveness check distinct. A closed ticket stating “removed” is weaker evidence than revoked access plus a tested result. Risk acceptance should identify who had authority to accept it and when it must be revisited. Certification does not itself establish GDPR compliance.

Secani provides a connected workspace for modeling systems and services, relating evidence to requirements and decisions, and assigning owners and review tasks. Keep discovery and enforcement in the appropriate operational systems, then bring relevant exports, reviews, and approvals into that compliance context. Treat AI-assisted suggestions as drafts requiring human review, with source traceability preserved.

For the next review, choose one business process and reconcile its identity, spending, endpoint, and interview findings. Finish each confirmed finding with a named owner, treatment, deadline, and closure test. Useful measures include owner coverage, overdue decisions, expiring exceptions, and completed access-removal checks—not just the number of tools discovered.