The proposed vendor claim is complete visibility into every app. Test it by asking which evidence sources are connected and what falls outside them. A shadow IT audit should produce an app register with known gaps and a short list of client decisions, rather than treating a discovery dashboard as the whole environment.
Shadow IT means technology used for work outside the organization's approved arrangements. Start by finding the work behind it. You can use a client meeting to decide what happens next if you collect and check the relevant evidence beforehand; the meeting alone won't establish a complete inventory.
Agree What You Are Looking for and Where
Set the review boundary with the client's authorized owner. Identify which business units and environments are included and the period the evidence covers. Agree the permitted collection methods before examining employee activity or exporting records.
Use the client's approved application list as a starting point, then compare it with the evidence available to you. Keep the sources identifiable. A paid subscription, an installed application, and observed access to a service each tell you something different.
| Possible Evidence Source | What to Investigate | What to Keep Uncertain |
|---|---|---|
| Approved application and service records | Which services the business already recognizes and who owns them | An approved list may not describe current use |
| Authorized endpoint or network discovery | Which apps or services appear in the covered devices and traffic | Activity outside the collection scope may be missing |
| Identity and application-consent records | Which integrations and permissions have been approved through the reviewed identity system | Accounts using another sign-in route need further investigation |
| Purchasing and subscription records | Which work tools the business is paying for | Free use or spending outside the reviewed records may not appear |
| Staff workflow discussion | Which tools people use to complete named work | A recollection needs checking against the available evidence |
Microsoft's discovered-apps documentation distinguishes log-based report streams from a separate Defender managed-endpoints stream. The practical question for your review is which data your actual report contains, not whether a product has discovery in its name.
An app inventory is like a stocktake: finding an item tells you it is present, not whether anyone approved the purchase or still needs it. Keep approval and business purpose as separate fields. Drop neither because the discovery tool supplied a confident-looking category.
Ask What the App Is Doing Before Deciding Its Fate
Ask the person doing the work what they use the app for and which approved tool failed to meet that need. Keep the question practical. You need enough context to judge the service, not a confession that someone has broken a rule.
Say a department uses an unapproved file-transfer service to exchange project material with a client. Establish which data is involved and why the approved route wasn't used. Don't assume the mere appearance of that service proves that sensitive files left the business.
Record the business owner and the technical owner separately where they differ. Identify who can approve continued use and who would implement a change. An app without a clear owner needs an ownership decision before its renewal or a hurried removal turns into the next incident.
Prioritize the Exposure You Can Explain
Assess each app using the client's agreed risk approach. Keep the underlying reasons visible instead of inventing a score from a product logo or an unsupported weighting formula. If you use a vendor's score, label whose assessment it is and investigate the client-specific use separately.
It depends on the data involved, the permissions granted, the control settings, and the business consequence if the service fails or access is lost. Those conditions can differ between uses of the same app. A public-content drafting tool and a service holding client records need different questions, even if both are outside the approved list.
- Identify the data involved and the consequence of disclosure, alteration, or loss.
- Check the actual account ownership, access, and integration permissions against the agreed use.
- Verify the relevant security and recovery controls rather than assuming a feature is enabled because it is available.
- Establish which business work depends on the service and what a change would interrupt.
- Mark missing evidence as unresolved and assign the person who can obtain it.
The model places MFA in the security baseline and calls for a standard technology stack with trained staff. Use those positions to examine the client's control gaps and supportability. They don't justify approving an unfamiliar service merely because it has an MFA option.
For the decision meeting, distinguish a verified concern needing prompt action from a question that still needs investigation. A missing answer isn't evidence of a breach. A confirmed exposure shouldn't be left waiting merely because the overall register remains unfinished.
Follow a Failure to the Person Who Would Notice
Consider the unapproved service whose only administrator leaves. The next employee who needs to change access or retrieve a business record might discover that nobody else can administer it. Put account ownership and the recovery route into the review before that person becomes your detection method.
Now consider an integration that retains permissions after the team stops using its app. Ask the technical owner to check the current grant and the approved removal path. Keep any suspected compromise in the incident process instead of waiting to debate it as an ordinary application-policy choice.
Avoid promising that moving everything into the standard stack removes all risk. An approved tool can still have an inappropriate configuration or an owner who no longer works there. The audit needs evidence about the current use, not just a list of approved names.
Leave the Meeting With Decisions and Owners
Bring the client a decision page grouped by the action needed. Keep the evidence register available behind it. The proposal below is a working decision format, not a validated risk scale.
| Decision | What Must Be Recorded |
|---|---|
| Approve within the agreed controls | The accepted use, business owner, technical owner, and controls to verify |
| Continue while a named condition is resolved | The condition, interim boundary, authorized decision-maker, and next review |
| Move the work to an approved alternative | The work to preserve, migration owner, client approval, and dependency plan |
| Stop or revoke the identified use | The authorized decision, removal steps, preserved records, and verification |
| Investigate before deciding | The unanswered question, evidence needed, and person responsible |
Luis Giraldo recommends returning to the data with the customer after an initiative, while Todd Kane suggests selecting measures relevant to the particular story. That's their practitioner review advice. Apply it by checking whether the agreed app decisions were implemented, rather than presenting a growing discovery count as success.
Give each accepted action a ticket and preserve the client's decision. For a change, use the normal approval and communication process; removing a service can affect work even when the service was never approved. Update the register when the implementation is verified, not simply when the meeting ends.
Start with a client-approved review boundary and the evidence sources you can actually inspect. Prepare the register, then ask the business owner to decide the unresolved uses. Carry the known blind spots and uncompleted actions into the next review so the report remains honest about what it establishes.
mspoutpost.com/articles/a-shadow-it-audit-that-produces-client-decisions
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
