- Identity provider sign-in and application-consent logs for the last 90 days
- Corporate card and expense reports for the last two quarters
- Firewall, DNS, or secure-web-gateway logs, if any exist
- A short interview round with each department head: what tools does your team actually use?
ATL-012INVENTORYEDITORIAL REVIEW COMPLETE
Cloud Service and SaaS Inventory
One row per cloud or SaaS service the business actually uses — sanctioned or not — with owner, authentication method, data types, and terms status, plus the discovery routine that finds the services nobody procured.
Using this artifact
Purpose, inputs, and completion
Purpose. The average small business runs on far more cloud services than anyone in it can name from memory, and the unnamed ones are where sensitive data leaks: personal accounts, password-only sign-in, no agreement, no offboarding. This inventory puts every service — sanctioned or discovered — in one table with an owner, an authentication method, and a decision. It is also the gate for AI tools: a new AI service is a new SaaS row, subject to the same data-types and sanction columns as everything else.
When to use it. Fill in the known services first, then run the discovery routine before calling the inventory complete — the point of this artifact is the services you did not already know about. Review quarterly, and add newly discovered or newly procured services within a week rather than batching them for the next quarter. Every row marked unsanctioned needs a decision in the final section: migrate, formalize, or shut down, with an owner and a date.
- Start with the services you know: the business tenant, accounting, payroll, the transfer portal — then run the discovery checklist to find the rest.
- For every service, name a business owner; a service nobody owns cannot be reviewed, renewed, or shut down deliberately.
- Record the authentication method honestly — 'password only, personal accounts' is a finding worth writing down, not an embarrassment to hide.
- Record which data types each service stores; the moment contract-sensitive data appears in a service with no agreement and no MFA, that row becomes the top of the work plan.
- Decide sanctioned or not for every row, and give every unsanctioned service either a migration path or a shutdown date.
Keeping it honest
Evidence, validation, and failure modes
- A dated inventory of every cloud and SaaS service with owner, authentication method, and data types
- A discovery record showing how unsanctioned services were searched for, not just stumbled upon
- A decision list: each unsanctioned service with its migration or shutdown plan
- Pull 30 days of identity provider consent grants and DNS logs; any service seen there but absent from the inventory is a discovery-routine failure to fix.
- Pick three rows marked SSO/MFA and verify the enforcement policy actually covers them; a row's claim is not evidence.
What looks done but is not
- The inventory lists what was procured, not what is used — the free tier tools that never touched procurement are exactly the ones with no MFA and no agreement.
- Services have named owners who do not know they are owners; the review dates pass silently.
- Discovery runs once, at inventory creation, and never again — new shadow services accumulate from the day after.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain at least the last eight quarterly snapshots (two years); the record of when each service was discovered, sanctioned, or shut down is the trail a reviewer follows.
Full document
Preview — exactly what prints
INVENTORY · ASSET MANAGEMENTv1.0 · REVIEWED 2026-08-06
Cloud Service and SaaS Inventory
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
The average small business runs on far more cloud services than anyone in it can name from memory, and the unnamed ones are where sensitive data leaks: personal accounts, password-only sign-in, no agreement, no offboarding. This inventory puts every service — sanctioned or discovered — in one table with an owner, an authentication method, and a decision. It is also the gate for AI tools: a new AI service is a new SaaS row, subject to the same data-types and sanction columns as everything else.
How to use it
Fill in the known services first, then run the discovery routine before calling the inventory complete — the point of this artifact is the services you did not already know about. Review quarterly, and add newly discovered or newly procured services within a week rather than batching them for the next quarter. Every row marked unsanctioned needs a decision in the final section: migrate, formalize, or shut down, with an owner and a date.
Scope and discovery method
Say what this inventory covers and which discovery sources were actually consulted, so a reviewer can judge how complete it plausibly is.
Scope
| Business units and sites covered | Discovery sources consulted (identity provider, expenses, DNS/firewall, interviews) | Period covered by discovery data | Known limits of this pass |
|---|---|---|---|
Cloud service and SaaS inventory
One row per service — including the ones you are about to shut down. A service leaves this table when it is gone, not when it becomes unfashionable.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Service | Purpose | Business owner | Account / tenant | Authentication (SSO / MFA?) | Data types stored | Admin count | Contract / terms status | Discovered how | Sanctioned? | Last reviewed |
|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE: Business cloud tenant | Email, files, collaboration | IT leader | Company tenant | SSO, phishing-resistant MFA enforced | FCI, CUI project library | 3 | Annual agreement, terms reviewed 2026-05 | Procured | Yes | 2026-07-01 |
| EXAMPLE: Free file-transfer site | Ad-hoc large file sends | None identified | Personal accounts | Password only | Unknown — possibly contract files | n/a | No agreement | Firewall log review | No — migrating to approved transfer by 2026-09 | 2026-07-01 |
AI tools are rows, not a separate universe
Chat assistants, transcription services, code copilots, and image tools belong in this table like any other SaaS: what data goes in, who owns the account, is sign-in enforced through the company identity provider, and is the service sanctioned. The data-types column is where 'someone pasted contract text into a free chatbot' gets caught on paper before it gets caught in an incident.
Shadow-IT discovery routine
Unsanctioned services do not announce themselves. Run all four sources each quarter — each one finds a different kind of hiding place.
Quarterly discovery pass
Log what each source surfaced, even when the answer is nothing — a discovery pass with no record is indistinguishable from no pass.
- Identity provider: review application consent grants and third-party sign-ins for the period; every unfamiliar application becomes a candidate row.
- OAuth consents are the fastest-growing shadow channel: a user 'signing in with' the company account enrolls the business in a service nobody approved.
- Finance: scan corporate-card statements and expense reports for recurring software charges; small monthly amounts are the signature of departmental SaaS.
- Network: review DNS, firewall, or secure-web-gateway logs for high-volume SaaS domains not in the inventory.
- People: ask each department head what tools their team actually uses to get work done — phrased as a help question, not an audit, or the honest answers stop.
Decisions and follow-ups
Every unsanctioned row and every UNKNOWN data-types cell lands here. Discovery without a decision is surveillance, not management.
Open decisions
| Service | Decision (formalize / migrate / shut down / investigate) | Owner | Complete by |
|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or compliance lead |
| Approval authority | Executive sponsor |
| Review frequency | Quarterly full review; new services added within a week of discovery or procurement |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain at least the last eight quarterly snapshots (two years); the record of when each service was discovered, sanctioned, or shut down is the trail a reviewer follows. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.