How to Inventory Your SaaS Dependencies: A Practical Template for European Organisations
Most organisations cannot list every SaaS tool they depend on. This post provides a structured template for inventorying your entire stack, categorising each dependency, and identifying where your sovereignty exposure actually sits.
Ask any IT manager how many SaaS tools their organisation uses and you will get a number. It will be wrong. Usually by a factor of two or three.
The average European organisation with 20 to 50 employees uses between 40 and 120 SaaS applications. The IT department knows about perhaps half of them. The rest were adopted by individual teams, paid for on corporate credit cards, connected via OAuth, and never documented anywhere.
This matters because you cannot assess what you do not know about. NIS2 requires documented supply chain risk management. DORA requires a register of ICT third-party arrangements. Both regulations assume you know what you depend on. Most organisations do not.
This post provides a structured template for building a complete SaaS dependency inventory. The template is designed to be practical: you can fill it in with your team in a few hours and produce something genuinely useful, not a compliance artifact that sits in a drawer.
Why Existing Asset Inventories Fall Short
Most organisations have some form of IT asset management. A spreadsheet of laptops, a list of software licences, maybe a procurement database. These inventories are typically missing three things:
Shadow IT. Tools adopted by employees without going through IT procurement. A marketing team using Canva, a sales team using Calendly, a developer using GitHub Copilot. Each one is a dependency. Each one may process company data. None of them are in the official inventory.
Integration dependencies. The Zapier connections, webhook endpoints, and API integrations that link your tools together. These are often more critical than the tools themselves, because they automate business processes that break silently when a tool changes or disappears.
Control-plane dependencies. The underlying services that your visible tools depend on. Your CRM runs on AWS. Your email runs through Google’s infrastructure. Your website uses Cloudflare for DNS. These are dependencies on dependencies, and they are the ones that matter most for sovereignty.
The Inventory Template
For each SaaS dependency, capture the following fields. The template works as a spreadsheet, a Notion database, or a plain table. The format matters less than the completeness.
Section 1: Basic Information
| Field | Description | Example |
|---|---|---|
| Tool name | Product name | Google Workspace |
| Vendor | Legal entity | Google Ireland Limited (contracting entity); Alphabet Inc. (parent, US) |
| Category | Functional category (see list below) | Productivity Suite |
| Primary users | Which teams use it | All employees |
| User count | How many people have active accounts | 28 |
| Monthly cost | What you pay | €336/month (€12/user) |
| Contract renewal | When the agreement renews | 1 April 2027 |
| Procurement path | How it was acquired | IT-approved, enterprise agreement |
Section 2: Dependency Depth
| Field | Description | Example |
|---|---|---|
| Business functions | What workflows depend on this tool | Email, calendar, file storage, video conferencing, identity (SSO) |
| Data types processed | What data flows through it | Employee PII, client correspondence, contracts, financial documents |
| Integration count | How many other tools connect to it | 14 (SSO), 6 (API), 3 (Zapier) |
| Automation count | Scripts, workflows, or automations built on it | 8 Apps Scripts, 2 Google Forms workflows |
| Criticality | What happens if this tool disappears tomorrow | Critical: all operations stop |
Section 3: Sovereignty Assessment
| Field | Description | Example |
|---|---|---|
| Vendor HQ jurisdiction | Country of ultimate parent company | United States |
| Data storage location | Where your data physically resides | EU (Belgium, Netherlands) |
| Subject to CLOUD Act | Is the vendor a US company or US subsidiary? | Yes |
| Subject to FISA 702 | Does the vendor qualify as an electronic communication service provider under US law? | Yes |
| Encryption key control | Who holds the encryption keys? | Google (default). Client-side encryption available but not enabled. |
| Data export capability | Can you export your data? In what format? | Google Takeout (MBOX for email, various formats for Drive). Metadata loss on export. |
| Alternative exists | Is there a viable EU-jurisdictional alternative? | Yes: Proton (email), Nextcloud (files), Keycloak (identity) |
Section 4: Risk and Action
| Field | Description | Example |
|---|---|---|
| Replaceability | Easy / Medium / Hard / Currently not replaceable | Hard (identity layer deeply embedded) |
| Lock-in mechanisms | What makes switching difficult | Identity (SSO hub), data gravity (500K files), Apps Script automations, institutional knowledge |
| Exit strategy status | Documented / Partial / None | None |
| Priority action | Next step for this dependency | Document exit strategy. Evaluate Keycloak for parallel identity. |
| Risk owner | Named person accountable | CTO |
Functional Categories
Use these categories to organise your inventory. Every organisation will have tools in at least 8 of these 15 categories:
- Identity and Access Management (Azure AD, Google Workspace, Okta, Auth0)
- Email and Calendar (Exchange, Gmail, Proton, Fastmail)
- File Storage and Collaboration (SharePoint, Google Drive, Dropbox, Nextcloud)
- Communication (Teams, Slack, Zoom, Google Meet)
- CRM and Sales (Salesforce, HubSpot, Pipedrive)
- Project Management (Jira, Asana, Monday.com, Linear, Notion)
- Finance and Accounting (Xero, QuickBooks, Exact, invoicing tools)
- HR and Payroll (Personio, BambooHR, payroll processors)
- Marketing (Mailchimp, HubSpot Marketing, analytics tools)
- Development (GitHub, GitLab, CI/CD, cloud hosting)
- Security (endpoint protection, SIEM, vulnerability scanning)
- DNS and Infrastructure (Cloudflare, AWS, domain registrars)
- Payment Processing (Stripe, Mollie, Adyen, PayPal)
- Legal and Compliance (contract management, e-signature, audit tools)
- Design and Creative (Figma, Canva, Adobe Creative Cloud)
How to Discover What You Are Actually Using
The hardest part of the inventory is finding tools that nobody documented. Here are five practical discovery methods:
1. Financial records. Pull 12 months of credit card and bank statements. Every SaaS subscription shows up as a recurring charge. This is the most reliable discovery method because it catches everything that costs money.
2. SSO and OAuth audit. Check your identity provider’s connected applications list. In Google Admin Console: Security → API controls → Third-party app access. In Azure AD: Enterprise Applications. These lists show every application that has been granted access to your organisation’s accounts. You will find tools you forgot about.
3. Browser extension audit. Ask employees to check their browser extensions. Many extensions connect to cloud services and process company data. Password managers, screenshot tools, grammar checkers, and AI assistants all qualify.
4. DNS and network audit. Review your DNS records (MX, CNAME, TXT) for third-party service integrations. SPF records alone often reveal email services, marketing platforms, and transactional email providers.
5. Employee survey. Send a simple survey: “List every web application you use for work, including ones you signed up for yourself.” Frame it as a security exercise, not a compliance audit. People are more forthcoming when the goal is protecting them, not policing them.
Scoring Your Inventory
Once the inventory is complete, score each dependency on two dimensions:
Sovereignty exposure (1 to 5):
- 1: EU vendor, EU data, EU jurisdiction. No CLOUD Act exposure.
- 2: EU vendor with some US sub-processors. Limited exposure.
- 3: US vendor with EU data residency. CLOUD Act applies but data is in the EU.
- 4: US vendor with data potentially outside the EU. Full jurisdictional exposure.
- 5: US vendor with identity or control-plane authority over your organisation.
Replaceability (1 to 5):
- 1: Drop-in replacement available. Migration takes days.
- 2: Good alternatives exist. Migration takes weeks.
- 3: Alternatives exist but with feature gaps. Migration takes months.
- 4: Few alternatives. Significant feature or ecosystem gaps. Migration is a major project.
- 5: No viable alternative currently. Deeply embedded with circular dependencies.
The combination of these two scores tells you where to focus. A tool that scores 5/5 (high sovereignty exposure, hard to replace) is your highest-priority risk. A tool that scores 1/1 is already in a good position.
What to Do With the Completed Inventory
The inventory is a foundation, not an end product. Once complete, it enables three things:
1. NIS2 compliance documentation. The inventory, with the sovereignty and risk assessments, forms the core of the supply chain risk register that NIS2 Article 21 requires.
2. DORA register of information. For financial entities, the inventory maps directly to the register of ICT third-party arrangements that DORA Article 28(3) requires.
3. Migration prioritisation. The sovereignty exposure and replaceability scores tell you which dependencies to address first. Start with high-exposure, high-replaceability tools (the quick wins), then work toward the high-exposure, low-replaceability ones (the strategic projects).
The inventory will also surprise you. Every organisation we work with discovers tools, integrations, and data flows they did not know existed. That alone makes the exercise worthwhile.
Sovereign Shift builds this inventory as the first phase of every dependency audit, with full sovereignty scoring and migration prioritisation. See how the audit works →