Shadow IT Discovery: Building a Software Inventory You Can Trust

Most organizations have more software in use than their official asset lists show. SaaS applications, browser extensions, AI tools, mobile apps, open-source packages, and “temporary” team subscriptions can create security and compliance risk when they are not visible, governed, or tied to accountable owners.

In this article, you’ll learn how to build a trustworthy software inventory that supports cybersecurity, access management, compliance reporting, and smarter technology decisions. We’ll cover shadow IT discovery, the user access review process, and employee AI tool usage risks with practical steps your IT, security, compliance, and business teams can use.

Why a Trusted Software Inventory Matters

A software inventory is more than a spreadsheet of applications. It is the foundation for understanding:

• What software is used across the organization
• Who owns each application
• Which users and third parties have access
• What data is stored, processed, or transmitted
• Whether the software has been reviewed for security and compliance
• Whether licenses, integrations, and administrative privileges are appropriate
• Which applications should be retained, restricted, consolidated, or retired

Without a trusted inventory, security teams cannot reliably manage risk. Compliance teams may struggle to demonstrate controls. Business leaders may unknowingly approve budgets for redundant tools. IT teams may discover applications only after a security incident, data exposure, failed audit, or employee departure.

For healthcare organizations and other regulated entities, the stakes are higher. If software stores or processes protected health information, financial data, employee data, or confidential business information, it may trigger specific security, privacy, contractual, and regulatory obligations. For example, covered entities and business associates subject to the HIPAA Security Rule must implement administrative, physical, and technical safeguards under 45 CFR Part 164, Subpart C. The specific obligations depend on the organization’s role, data involved, contracts, state laws, and other applicable frameworks.

A trustworthy software inventory helps answer a simple but critical question: Do we know what technology is being used to handle our data and support our operations?

What Makes a Software Inventory “Trustworthy”?

A software inventory you can trust has four qualities.

1. It Is Comprehensive

The inventory should include more than enterprise applications managed by IT. It should also capture:

• Cloud applications and SaaS platforms
• Locally installed software
• Mobile applications used for work
• Browser extensions
• Open-source software and libraries
• Developer tools and repositories
• AI tools, chatbots, transcription tools, and productivity assistants
• File-sharing and collaboration tools
• Remote access tools
• Department-purchased subscriptions
• Free-tier applications used with company data
• Integrations between applications
• Legacy systems that remain in limited use

Many organizations maintain an “official” application list but miss the long tail of tools used by marketing, finance, HR, operations, engineering, clinical teams, or individual employees.

2. It Is Current

An inventory that is updated once per year is unlikely to reflect reality. Software adoption changes quickly, especially with SaaS and AI tools. A trusted inventory should be supported by repeatable discovery methods and regular validation.

3. It Has Business Context

A list of application names is not enough. Each entry should identify the business purpose, owner, users, data types, risk level, access model, and review status.

4. It Is Actionable

The inventory should drive decisions. It should support access reviews, vendor risk management, incident response, license management, security monitoring, and application retirement.

The Hidden Risk: Shadow IT Discovery

“Shadow IT” means software, systems, or services used for business purposes without formal approval, oversight, or management by IT or security. Shadow IT is not always malicious. In many cases, employees adopt tools because they are trying to solve real business problems quickly.

Examples include:

• A department signs up for a project management tool using a corporate credit card.
• A clinician uses an unapproved transcription app to summarize notes.
• A sales team stores client files in a personal file-sharing account.
• A developer connects a code repository to an unreviewed automation service.
• An employee uses a public AI chatbot to draft documents containing internal information.
• A team installs browser extensions to capture screenshots, manage passwords, or automate workflows.

The problem is not simply that these tools exist. The problem is that the organization may not know:

• What data is being uploaded
• Whether data is retained or used to train models
• Who has access
• Whether multifactor authentication is enabled
• Whether the vendor has appropriate security controls
• Whether contractual protections are in place
• Whether the tool complies with internal policy or regulatory obligations
• Whether access is removed when employees change roles or leave

Shadow IT discovery is the process of finding these tools and bringing them into a governed software lifecycle.

Start With Governance: Define Ownership and Rules

Before launching a discovery effort, establish clear governance. Otherwise, the inventory may become a one-time cleanup project instead of a sustainable process.

Assign Core Roles

At minimum, define these roles:

| Role | Responsibility | |---|---| | Executive sponsor | Supports policy enforcement and cross-functional participation | | IT owner | Leads technical discovery and inventory management | | Security owner | Assesses risk, controls, and monitoring needs | | Compliance or privacy owner | Reviews regulatory, contractual, and data protection implications | | Procurement or finance owner | Identifies purchases, renewals, and contracts | | Business application owner | Explains purpose, users, and operational needs | | Data owner | Confirms data classification and handling requirements |

In smaller organizations, one person may wear multiple hats. The key is to avoid applications with no clear owner.

Define What Must Be Inventoried

Create a written standard that defines software broadly. Include:

• Paid and free tools
• Trial subscriptions
• Employee-installed applications
• Cloud services accessed through a browser
• Applications connected to company identity systems
• Software used with company data, even if not company-funded
• AI tools used to generate, summarize, analyze, transcribe, translate, or classify work content
• Applications used by contractors or third parties on the organization’s behalf

This definition should be practical and easy for employees to understand.

Set Approval Thresholds

Not every tool needs the same review depth. Define tiers based on risk.

Example:

| Tier | Example Software | Review Needed | |---|---|---| | Low risk | Public reference tools with no company data | Basic inventory entry | | Moderate risk | Productivity tool using internal business data | Security and data handling review | | High risk | Software processing protected health information, financial data, credentials, or sensitive HR data | Security, privacy, legal, vendor risk, and contract review | | Critical risk | Systems supporting patient care, authentication, payment, or regulated workflows | Formal risk assessment, executive approval, ongoing monitoring |

For healthcare environments, any software that creates, receives, maintains, or transmits electronic protected health information should receive careful review under applicable HIPAA obligations and business associate requirements. Whether a vendor is a business associate depends on the facts and should be evaluated with qualified legal counsel where needed.

Build the Software Inventory Data Model

A trusted inventory needs consistent fields. Start with enough detail to support security and compliance decisions, but avoid making the process so burdensome that teams bypass it.

Recommended Inventory Fields

Use these fields as a baseline:

• Application name
• Vendor name
• Application URL or installation source
• Business owner
• Technical owner
• Department or business unit
• Business purpose
• User population
• Number of active users
• Authentication method
• Single sign-on status
• Multifactor authentication status
• Administrative users
• Data types processed
• Data classification
• Whether regulated data is involved
• Whether protected health information may be involved
• Integrations and connected systems
• API access or service accounts
• Contract status
• Vendor risk review status
• Privacy review status
• Security review status
• Last access review date
• Last risk review date
• Renewal date
• License count and cost center
• Logging and monitoring status
• Backup or export capability
• Data retention and deletion method
• Status: approved, under review, restricted, exception, retire

Keep Status Labels Simple

Avoid ambiguous labels. Use clear categories:

• Approved: Reviewed and permitted for defined use.
• Approved with conditions: Permitted if specific controls are met.
• Under review: In discovery or assessment.
• Restricted: Use limited to specific teams, data types, or purposes.
• Exception: Temporary approval with documented risk acceptance and expiration.
• Prohibited: Not allowed for company data or business use.
• Retire: Scheduled for replacement, consolidation, or shutdown.

Example Inventory Entry

| Field | Example | |---|---| | Application | AcmeForms | | Business purpose | Online intake forms | | Owner | Patient Access Director | | Users | Front desk, scheduling team | | Data | Patient contact details, appointment request information | | Authentication | SSO enabled | | MFA | Required through identity provider | | Vendor review | Completed | | Contract | Active; reviewed by procurement | | Status | Approved with conditions | | Conditions | No clinical notes or payment card data; quarterly access review | | Last access review | 2026-09-15 | | Next review | 2026-12-15 |

Practical Methods for Shadow IT Discovery

No single source will reveal every application. Use multiple discovery methods and reconcile the results.

1. Review Identity Provider and Single Sign-On Data

Your identity provider is often the best starting point. Review:

• Applications integrated with single sign-on
• OAuth grants and consented apps
• SAML applications
• OpenID Connect integrations
• Users with administrative privileges
• Dormant applications still connected to identity
• Applications with broad directory permissions

Pay particular attention to third-party applications granted access to email, calendars, files, chats, or user profiles.

2. Analyze Endpoint Management Data

Endpoint management tools can reveal installed software on laptops, desktops, and servers. Look for:

• Unauthorized remote access tools
• Consumer file-sharing clients
• Unapproved browsers or browser extensions
• Development tools that connect to external services
• Local AI tools or data synchronization apps
• Outdated or unsupported software
• Multiple versions of the same application

Endpoint data is especially useful for finding software that does not appear in procurement or identity systems.

3. Check Network and DNS Logs

Network, proxy, secure web gateway, firewall, and DNS logs can show which cloud services employees access. This is useful for identifying SaaS applications used outside approved channels.

Look for:

• Frequent access to unapproved SaaS domains
• AI chatbot and content generation tools
• File-sharing and collaboration platforms
• Personal email and storage services
• Developer automation platforms
• Remote desktop or tunneling services
• High-volume uploads to unknown domains

Network logs do not always prove business use, but they provide leads for investigation.

4. Review Finance, Expense, and Procurement Data

Many shadow IT tools are purchased through credit cards or departmental budgets. Work with finance and procurement to identify:

• Recurring software subscriptions
• Vendor names that do not match application names
• Small monthly charges across multiple departments
• Reimbursements for software tools
• Trial subscriptions converted to paid plans
• Renewals approaching within 90 to 180 days

Procurement data helps identify business owners and contract status.

5. Survey Departments With a Non-Punitive Approach

Employees may not report tools if they fear punishment. Position the process as risk reduction and support, not blame.

Ask each department:

• What tools do you use to perform daily work?
• Which tools store or process customer, patient, employee, or financial information?
• Which tools did the department purchase directly?
• Which free tools are used for business tasks?
• Which tools are essential to operations?
• Which tools are frustrating, redundant, or no longer needed?
• Are employees using AI tools for drafting, summarizing, transcription, coding, analytics, or decision support?

Keep the survey short and follow up with interviews for high-risk areas.

6. Review Browser Extensions

Browser extensions can access sensitive data, including web pages, session information, clipboard contents, or user activity depending on permissions. Inventory extensions installed in managed browsers and classify them by risk.

High-risk examples include extensions that:

• Read and change data on all websites
• Capture screenshots or keystrokes
• Manage credentials
• Access email or file storage
• Inject scripts into web applications
• Sync data to external accounts

Establish an allowlist for approved extensions and block known risky categories where appropriate.

7. Inspect Collaboration and File-Sharing Platforms

Search for references to unapproved tools in:

• Shared documents
• Team channels
• Internal wikis
• Ticketing systems
• Project plans
• Automation workflows
• Help desk requests

Employees often mention the actual tools they use in day-to-day collaboration.

8. Include Developer and Automation Tools

Software inventory should cover tools used by IT, engineering, analytics, and security teams. These tools may have privileged access or contain sensitive code and data.

Inventory:

• Source code repositories
• CI/CD platforms
• Package managers
• Infrastructure-as-code tools
• Secrets management tools
• Monitoring platforms
• Automation services
• API testing tools
• Cloud administration utilities
• Data science notebooks
• AI coding assistants

Developer tools can introduce supply chain and credential risks if not governed.

Address Employee AI Tool Usage Risks

Employee AI tool usage risks deserve specific attention because AI tools are easy to access, often free or low cost, and may be used without a formal procurement process.

AI tools can include:

• Chatbots
• Writing assistants
• Coding assistants
• Meeting transcription tools
• Image, audio, or video generators
• Translation tools
• Document summarization tools
• Data analysis platforms
• AI features embedded in existing SaaS applications

Key Risks to Evaluate

When employees use AI tools, evaluate:

• Data disclosure: Are users entering confidential, patient, customer, employee, or proprietary data?
• Retention: Does the provider retain prompts, files, transcripts, outputs, or metadata?
• Model training: Can submitted content be used to train or improve models?
• Access control: Can the organization manage accounts, roles, and offboarding?
• Auditability: Are logs available for administrative review?
• Accuracy: Could incorrect AI-generated output affect clinical, financial, operational, or security decisions?
• Regulatory impact: Does the use involve protected health information or other regulated data?
• Contract terms: Are data processing, confidentiality, retention, deletion, and security obligations documented?
• Integration risk: Does the tool connect to email, files, calendars, code repositories, or business systems?

Create an AI Usage Intake

Add AI-specific questions to your software request process:

• What is the intended use case?
• What data will be entered, uploaded, recorded, or connected?
• Will the tool process protected health information, personal information, credentials, source code, or confidential business data?
• Will outputs be used for decision-making or only drafting and assistance?
• Are humans required to review outputs before use?
• Can the organization disable training on submitted data where applicable?
• What administrative controls are available?
• Can access be managed through SSO?
• What logs are available?
• How can data be deleted or exported?
• Does the vendor offer contractual terms suitable for the intended data?

Example AI Tool Policy Language

A practical policy might say:

> Employees may use approved AI tools for business purposes within the conditions documented in the software inventory. Employees must not enter protected health information, credentials, confidential client data, sensitive employee data, source code, or non-public business information into unapproved AI tools. AI-generated content must be reviewed by a qualified person before being used in business, clinical, legal, financial, or security decisions.

Tailor policy language to your legal, compliance, and operational requirements. For healthcare use cases, involve privacy, security, compliance, and counsel before allowing AI tools to process protected health information.

Connect Inventory to the User Access Review Process

A software inventory is not complete unless it connects to access governance. The user access review process confirms that users have appropriate access based on their job responsibilities and that unnecessary access is removed.

Access reviews help answer:

• Who has access to each application?
• Are users still employed or under contract?
• Do users still need access for their current role?
• Are privileged accounts limited and justified?
• Are shared accounts present?
• Are service accounts documented?
• Are terminated employees fully removed?
• Are third-party users still authorized?
• Are access levels excessive?
• Are inactive users disabled?

Define Review Frequency by Risk

Not every application requires the same frequency. Consider:

| Application Type | Suggested Review Frequency | |---|---| | Critical systems with sensitive or regulated data | Quarterly or more often | | Privileged administrative access | Monthly or quarterly | | Moderate-risk business applications | Semiannually | | Low-risk tools with no sensitive data | Annually | | Temporary access or exceptions | At expiration or within a defined short period |

Frameworks and contracts may have specific expectations, and requirements vary by industry, state, payer, and framework version. Healthcare organizations should align access review practices with applicable HIPAA Security Rule safeguards, organizational risk analysis, and internal policies.

Standard Access Review Workflow

A repeatable workflow may look like this:

1. Generate user list: Export active users, roles, groups, administrative accounts, service accounts, and external users.
2. Validate business owner: Confirm who is responsible for approving access.
3. Review access by role: Compare access to job responsibilities.
4. Flag exceptions: Identify excessive privileges, dormant accounts, shared accounts, and unknown users.
5. Approve or revoke: Require owners to explicitly approve continued access or request removal.
6. Track remediation: Document removals, role changes, and unresolved issues.
7. Retain evidence: Store review records, timestamps, reviewers, decisions, and remediation proof.
8. Update inventory: Record the review date, findings, and next review date.

Access Review Checklist

Use this checklist for each application:

• [ ] Application owner confirmed
• [ ] Current user list exported from the source system
• [ ] Administrative users identified
• [ ] External users identified
• [ ] Shared accounts identified
• [ ] Service accounts documented
• [ ] Dormant users reviewed
• [ ] Terminated users removed
• [ ] Role changes reflected
• [ ] Excessive privileges reduced
• [ ] MFA and SSO status verified where applicable
• [ ] Exceptions documented with expiration dates
• [ ] Evidence retained
• [ ] Inventory updated

Common Access Review Problems

Watch for these recurring issues:

• Business owners rubber-stamp all users without review.
• IT exports user lists but no one validates business need.
• Reviews exclude administrators and service accounts.
• SaaS applications have local accounts outside SSO.
• Contractors remain active after projects end.
• Shared accounts prevent accountability.
• Access reviews are performed but remediation is not tracked.
• Evidence is scattered across emails and spreadsheets.

A strong user access review process should result in actual access changes, not just completed forms.

Prioritize Risk: Not All Software Needs the Same Treatment

Once discovery begins, you may find more applications than expected. Prioritize based on risk.

High-Priority Software Categories

Review these first:

• Applications storing protected health information
• Applications handling financial, payment, payroll, or tax data
• Identity, access, and password management tools
• Remote access and administration tools
• File-sharing and collaboration platforms
• AI tools that process confidential or regulated data
• Applications with many users
• Applications with privileged integrations
• Tools connected to email, calendars, cloud storage, or source code
• Unsupported or end-of-life software
• Software with no clear owner
• Applications purchased outside procurement
• Applications with weak or unknown authentication controls

Risk Scoring Example

You can use a simple scoring model:

| Risk Factor | Score | |---|---| | No sensitive data | 0 | | Internal business data | 1 | | Confidential data | 2 | | Regulated or protected data | 3 | | No external integrations | 0 | | Limited integration | 1 | | Access to major business systems | 2 | | Privileged or identity integration | 3 | | SSO and MFA enabled | 0 | | MFA only | 1 | | Password only | 2 | | Unknown authentication | 3 | | Known owner | 0 | | Unclear owner | 2 | | No owner | 3 |

Applications with higher scores should receive faster review, stronger controls, and more frequent access validation.

Remediate Findings Without Disrupting the Business

Shadow IT remediation should balance security with operational reality. If employees adopted a tool because the approved option did not meet their needs, simply blocking it may push usage further underground.

Remediation Options

Depending on risk, choose one or more actions:

• Approve the tool after security and privacy review
• Move the team to an existing approved tool
• Negotiate appropriate contract terms
• Enable SSO and MFA
• Restrict sensitive data usage
• Limit access to approved users
• Disable risky integrations
• Remove public sharing links
• Export and delete data
• Retire duplicate tools
• Block prohibited tools through technical controls
• Create a time-bound exception while replacing the tool
• Provide employee training on acceptable use

Example: Unapproved File-Sharing Tool

Discovery finds a department using an unapproved file-sharing platform for vendor collaboration.

A practical response:

1. Identify the data stored in the platform.
2. Determine whether regulated, confidential, or contractual data is involved.
3. Confirm who has access, including external parties.
4. Disable public links and remove unnecessary users.
5. Export business records to an approved repository.
6. Evaluate whether the tool should be approved, restricted, or retired.
7. Train the department on approved collaboration methods.
8. Update the inventory and access review schedule.

Example: AI Meeting Transcription Tool

Discovery finds employees using an AI meeting assistant that records and summarizes calls.

A practical response:

1. Identify whether meetings include patients, workforce members, clients, or confidential topics.
2. Review vendor retention, training, deletion, and access controls.
3. Determine whether consent, notice, or contractual requirements apply. These requirements may vary by state, context, and type of communication, so consult qualified counsel as needed.
4. Disable use for sensitive meetings until reviewed.
5. Provide an approved alternative if transcription is business-critical.
6. Publish clear guidance on when AI meeting tools may be used.

Automate Where Possible, But Do Not Rely on Tools Alone

Technology can accelerate discovery and inventory management, but tools do not replace governance.

Useful technical sources include:

• Identity provider reports
• Endpoint management platforms
• Mobile device management systems
• SaaS management tools
• Cloud access security broker capabilities
• Secure web gateways
• DNS and firewall logs
• Data loss prevention alerts
• Procurement and expense systems
• Configuration management databases
• Security information and event management platforms
• Vulnerability management tools

Automation can help identify applications, users, traffic patterns, risky OAuth grants, and unmanaged devices. However, only business owners can confirm business purpose, data context, and operational need. The best results come from combining automated discovery with human validation.

Maintain the Inventory Over Time

A trusted software inventory is a living control. Build maintenance into normal business processes.

Trigger Inventory Updates

Require updates when:

• A new software request is submitted
• A contract is signed or renewed
• A department purchases a subscription
• A new integration is enabled
• A vendor changes security or privacy terms
• A new data type is added
• An application begins processing protected or regulated data
• AI functionality is enabled in an existing tool
• Users are granted administrative access
• A business process changes
• An application is retired
• An incident or audit finding identifies a gap

Review Cadence

Set a recurring review schedule:

• Monthly: new software discoveries and high-risk exceptions
• Quarterly: high-risk application access reviews
• Semiannually: moderate-risk application validation
• Annually: full inventory attestation by business owners
• Before renewal: security, usage, cost, and access review

Metrics to Track

Useful metrics include:

• Number of inventoried applications
• Number of newly discovered applications
• Percentage of applications with assigned owners
• Percentage with data classification completed
• Percentage with SSO enabled
• Percentage with MFA enforced
• Number of applications processing regulated or sensitive data
• Number of overdue access reviews
• Number of unresolved high-risk findings
• Number of applications scheduled for retirement
• Number of approved AI tools and restricted AI tools
• Time from discovery to risk decision

Avoid vanity metrics. Focus on measures that help leaders understand risk reduction and operational maturity.

Align With Security and Compliance Frameworks

A software inventory supports multiple cybersecurity and compliance activities, including asset management, access control, vendor risk management, incident response, and risk analysis.

Relevant standards and frameworks may include:

• NIST Cybersecurity Framework 2.0
• NIST Special Publication 800-53
• NIST Special Publication 800-66 for HIPAA Security Rule implementation guidance
• CIS Critical Security Controls
• SOC 2 Trust Services Criteria
• ISO/IEC 27001
• HIPAA Security Rule, 45 CFR Part 164, Subpart C
• PCI DSS, where payment card data is involved
• State privacy and breach notification laws, where applicable

Requirements vary by organization type, jurisdiction, contract, payer, and framework version. Treat the inventory as a control that supports compliance, not as a substitute for a full legal or regulatory analysis.

Practical Implementation Plan

If your organization is starting from an incomplete inventory, use a phased approach.

First 30 Days: Establish the Baseline

• Assign an executive sponsor and inventory owner.
• Define what counts as software.
• Create standard inventory fields.
• Pull application lists from identity, endpoint, procurement, and finance systems.
• Identify obvious high-risk applications.
• Start an AI tool usage survey.
• Create status labels and review categories.
• Assign business owners for the top 20 to 50 applications by risk or usage.

Days 31–60: Validate and Prioritize

• Reconcile duplicate application names.
• Interview business owners.
• Classify data types and regulated data involvement.
• Identify applications without SSO or MFA.
• Review administrative users for high-risk tools.
• Investigate recurring software charges.
• Review browser extensions and OAuth grants.
• Create a remediation backlog.
• Document prohibited or restricted software categories.

Days 61–90: Remediate and Institutionalize

• Complete access reviews for high-risk applications.
• Remove terminated, dormant, and excessive access.
• Approve, restrict, or retire discovered tools.
• Publish software request and AI usage procedures.
• Add inventory review to procurement and renewal workflows.
• Establish recurring reporting to leadership.
• Define ongoing review cadence and evidence retention.
• Track remediation to closure.

Software Inventory Checklist

Use this checklist to assess your current maturity:

• [ ] We have a defined owner for the software inventory.
• [ ] Our definition of software includes SaaS, AI tools, browser extensions, mobile apps, and free tools.
• [ ] We use multiple discovery sources, not just procurement records.
• [ ] Each application has a business owner.
• [ ] Each application has a documented business purpose.
• [ ] Data types are classified for each application.
• [ ] Applications involving protected or regulated data are identified.
• [ ] SSO and MFA status are tracked.
• [ ] Administrative users are documented.
• [ ] Third-party and contractor access is tracked.
• [ ] AI tool usage is reviewed and governed.
• [ ] Access reviews are scheduled based on risk.
• [ ] Review evidence is retained.
• [ ] Exceptions have expiration dates.
• [ ] Retired applications are removed from identity, endpoints, and contracts.
• [ ] Inventory updates are tied to procurement, onboarding, offboarding, renewals, and incident response.

Conclusion: Trust Comes From Process, Not a Spreadsheet

A trustworthy software inventory is built through repeatable discovery, clear ownership, risk-based review, and disciplined access governance. Shadow IT discovery should not be treated as a one-time cleanup; it should become part of how the organization manages technology, protects data, and supports compliance.

Start with the highest-risk software: tools that process sensitive data, support critical operations, connect to identity systems, or involve employee AI tool usage risks. Then connect the inventory to your user access review process so that visibility turns into measurable control.

Clear Next Steps

1. Pull application data from identity, endpoint, finance, and network sources.
2. Create a standard inventory template with owner, data, access, and review fields.
3. Identify high-risk applications and AI tools for immediate review.
4. Assign business owners and perform access reviews.
5. Establish a recurring process for discovery, approval, remediation, and reporting.

How ThornShield Can Help

ThornShield Technologies helps organizations identify software usage, uncover shadow IT, assess access risk, and prioritize remediation. Our [Software Usage & Access Analysis](https://www.thornshield.tech/services/software-usage-analysis) service provides practical visibility into the applications and access patterns that matter most for security and compliance.

This article is general information and not legal advice.