Your Critical App Isn't Yours: Building a SaaS Dependency Inventory

Step 3: Record what you will need at hour two

The inventory is most useful when each field answers a question someone will ask during the outage. Keep one row per critical service:

Two fields deserve extra attention. Identity cuts both ways: SSO is a security win, but it makes your identity provider a dependency of every application behind it. For the few services you could not live without, ask whether the vendor supports a break-glass local administrator, and keep those credentials in an offline vault with a named custodian.

Integrations are where quiet failures live. The SaaS is up, but the nightly sync stopped because an API token expired, or because the integration was created under an employee's personal account and was switched off along with that account when they left. Record the account each integration runs under. If it is a person, fix that before it becomes an incident.

The NIST Cybersecurity Framework treats this kind of record as basic hygiene: CSF 2.0 asks organizations to maintain inventories of the services their suppliers provide (subcategory ID.AM-04).

Step 4: Test the export, not the export button

Most SaaS terms leave responsibility for your data with you. The vendor protects against its own infrastructure failing, not against a bad bulk import, a malicious insider or your own deletions once its retention window closes, and it cannot help at all while it is down. An export is your only independent copy, and it counts only once you have tested four things:

1. Can you get it, and how fast? Time a full export. Some services queue large exports for hours or limit how often you can request one; learn that on a quiet afternoon.
2. Is it complete? Check attachments, comments, history, custom fields, audit logs and the relationships between records. A CSV export can flatten a relational system into tables that no longer connect, because the IDs that linked records are missing.
3. Can a person use it without the vendor's product? Pick a real question, such as "which customers are due a delivery tomorrow?", and answer it from the export in a spreadsheet, against the clock. If nobody can, you have an archive, not a fallback.
4. Where does it land? An export saved to another SaaS file share behind the same SSO shares a dependency with the thing it protects. Keep at least one copy somewhere reachable when the identity provider is down.

Set the export cadence from the business's tolerance for data loss. If the team can reconstruct a day of changes, a nightly export may be enough. If it cannot, look at continuous API-based backup, which several third-party tools offer for the major productivity and CRM platforms.

Step 5: Plan the day without it

Take a hypothetical 200-person industrial distributor running order management in a SaaS CRM. At 8:05 on a Tuesday, reps cannot log in. The plan has four checkpoints.

By 8:20, confirm it is the vendor. Check the status page and your own synthetic monitor, try a second network, and rule out your identity provider. Open a vendor ticket and note the reference.

At 8:30, declare manual mode. The sales operations lead, the named business owner, makes the call. Reps get a short message saying where the manual order form and last night's export are, and what to tell customers.

From 8:30, take orders by hand. Reps use a spreadsheet form with the same fields as the CRM order screen. Manual orders get their own numbering (M-0001 onward) so they cannot collide with system numbers. Customer details and open orders come from last night's export, kept on a file share that does not sit behind the CRM's login.

When service returns, reconcile. Two people re-key the manual orders, one entering and one checking. Watch for duplicates: orders submitted just before the outage may be sitting in a vendor queue and appear after recovery. Re-entry is real work, so budget time for it; it may run into the next morning.

None of this is sophisticated. It works only because the form, the export location, the numbering rule and the decision owner were settled in advance and practiced once.

Payroll needs the same treatment: ask the provider what an off-cycle or repeat run looks like if its platform is down on a pay date.

Step 6: Watch status pages like an operator

Status pages lag: vendors post after confirming a problem, and your users usually notice first. Make it work harder:

• Subscribe by component and region, not to the whole page, and route alerts by email, RSS or webhook into the channel your on-call team watches rather than one administrator's inbox.
• Add your own synthetic checks. A scripted login or API call from outside your network every few minutes tells you when the service is broken for you, which is the only question that matters at 8:05.
• Note where the vendor posts when its status page is down. Not every status page is hosted independently of the product. Record the backup channel, often a social media account.
• Keep vendor contacts current. Incident and security notices go to whatever address is on the account; make it a role mailbox someone still reads.

Keep the inventory alive

An inventory built once is out of date within a quarter. Spend an hour on it every three months:

• Rerun discovery: card spend, OAuth grants, DNS records, gateway logs
• Confirm owners for every critical service and reassign any who have left
• Test one export end to end for each critical service, on a rotation
• Practice one manual fallback for an hour with the people who would run it
• Check that status alerts still reach the on-call channel
• Move any integration still running under a personal account

Then adopt one rule with procurement: no critical SaaS contract renews unless its export has been tested in the past twelve months and its manual fallback has a named owner.