SaaS management became a legal obligation in January 2025. Not a best practice. Not a governance recommendation. A direct legal requirement - enforceable, auditable, and with personal liability attached for senior management in regulated industries.
The question organisations should be asking is not whether they track their SaaS applications. Most do, in some form. The question is whether what they have would withstand a supervisory review. For the majority, the honest answer is no, because the registers they maintain were built for operational convenience, not regulatory compliance. Those are different instruments, and the gap between them is where enforcement risk sits.
Three regulatory frameworks now impose explicit obligations on organisations to maintain a complete, accurate inventory of every software application they use. DORA has been in force since 17 January 2025. GDPR has required a record of processing activities since 2018. The EU AI Act's high-risk system obligations take effect in August 2026. None of these frameworks treats SaaS governance as optional, and none of them accepts a partial inventory as compliance.
What The Regulations Actually Require
Each of the three major EU frameworks imposes a distinct but overlapping inventory obligation. Understanding what each requires, at article level - is the starting point for understanding why a finance-focused tracking approach is insufficient.
DORA: The ICT Third-Party Register (Article 28.3)
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) requires every in-scope financial entity to maintain a register of all ICT third-party service providers. Article 28.3 is explicit: the register must document every ICT service arrangement, distinguish between arrangements supporting critical or important functions and those that do not, and be made available to competent authorities on request.
The definition of ICT services under DORA is deliberately broad. Article 3(21) defines ICT services as digital and data services provided through ICT systems on an ongoing basis, which encompasses every SaaS application an organisation uses, including those adopted informally by employees. There is no de minimis threshold. A tool adopted by one employee on a free tier is an ICT service arrangement under DORA if it is being used in connection with the organisation's operations.
Where organisations tend to get this wrong is scope. The instinct is to read DORA as applying to the formal vendor relationships - the cloud providers, the core banking platforms, the managed services contracts. Those are in scope. But so is the SaaS tool three people in operations adopted six months ago because it solved a workflow problem. DORA does not distinguish between tools that went through procurement and tools that did not. The register obligation is the same for both.
DORA applies to all licensed financial entities; credit institutions, payment institutions, investment firms, insurance undertakings, and over a dozen other categories, with no size threshold. A 60-person fintech holding a payment institution licence has the same Article 28.3 obligation as a 50,000-person bank.
GDPR: The Record of Processing Activities (Article 30)
GDPR (Regulation (EU) 2016/679) Article 30 requires every data controller to maintain a record of processing activities - a RoPA, covering every operation involving personal data. The RoPA must document the purposes of processing, the categories of data and data subjects, the recipients of data, retention periods, and the technical and organisational security measures in place.
Every SaaS application that processes personal data is a processing activity that belongs in the RoPA. Every SaaS vendor that processes personal data on the organisation's behalf is a processor under Article 4(8) and requires a data processing agreement under Article 28. An incomplete SaaS inventory means an incomplete RoPA, and an incomplete RoPA is the first document a supervisory authority asks for.
The misreading I encounter most often is that Article 30 applies to the obvious data systems; HR platforms, CRM tools, customer databases, and stops there. It does not. It applies to every processing activity, which means every SaaS tool that touches personal data in any capacity: the project management platform where employee names appear in task assignments, the document tool where HR correspondence is drafted, the analytics platform where customer identifiers are processed. The RoPA is only as complete as the SaaS inventory it is built on.
EU AI Act: AI System Inventory (Articles 16, 26, and 49)
The EU AI Act (Regulation (EU) 2024/1689) creates separate obligations for AI providers and deployers. For organisations deploying AI systems, which includes using any third-party AI tool in a business context, Article 26 imposes obligations including human oversight, logging, and ensuring the system is used in accordance with its intended purpose and instructions. Article 49 requires deployers of high-risk AI systems to register those systems in the EU database before putting them into service.
You cannot satisfy either obligation without first knowing which AI systems the organisation is using. Shadow IT is the primary mechanism through which AI systems enter organisations without being registered, assessed, or governed - and it is why an organisation that has not completed a systematic SaaS and AI inventory is, by definition, not in a position to demonstrate Article 26 or Article 49 compliance.
The practical challenge here is that many organisations are discovering they are already deployers of high-risk AI systems without having made a deliberate decision to be. A SaaS tool adopted for one purpose has added AI functionality. A CRM has introduced automated scoring. A document platform now offers AI-generated outputs that inform decisions. The August 2026 deadline for high-risk system obligations is not a future problem, for organisations that have not started their inventory, it is already a present one.
Why A Spreadsheet Fails Each Obligation
The most common form of SaaS management in mid-market organisations is a spreadsheet, maintained by IT or Finance, updated when someone remembers to update it. This is not a criticism of the people maintaining it, it reflects the tools that were available and the priorities that existed before these regulatory frameworks came into force. The problem is that a spreadsheet-based approach fails the specific compliance tests that DORA, GDPR, and the EU AI Act now apply.
DORA's Article 28.3 register is not a static document. It must be kept current, made available to regulators on request, and must cover all ICT arrangements, including those that were never formally procured. A spreadsheet updated quarterly, covering only the tools IT knows about, does not satisfy this. Shadow IT, the applications employees adopt outside formal procurement, is precisely the gap that a manually maintained register cannot close, because the information needed to fill it never reaches the person doing the updating.
GDPR's Article 30 RoPA has the same completeness problem from a different direction. A RoPA entry for a SaaS tool must include the data categories being processed, the legal basis, the recipient details, and the security measures. A spreadsheet row that records the tool name and renewal date does not contain this information. The RoPA and the SaaS inventory are different instruments, but they are built on the same foundation: knowing what applications exist and what they do with data.
For the EU AI Act, the failure is one of classification. A spreadsheet can list tools. It cannot classify them against the Act's risk pyramid, identify which fall into Annex III high-risk categories, flag prohibited practices under Article 5, or generate the documentation that Article 26 deployer obligations require. Classification requires information about what the tool does, what data it processes, what decisions it influences, and how it was trained, none of which a standard software inventory contains.
The Completeness Problem: Why Shadow IT Makes Compliance Impossible
Every register obligation assumes a complete inventory. A DORA ICT register that covers 70% of the organisation's SaaS estate is not a compliant register, it is a partial register with 30% of the compliance exposure undocumented. A GDPR RoPA that omits the tools employees adopted informally is not a defensible record of processing activities.
Shadow IT is the mechanism that makes completeness hard to achieve. When employees adopt SaaS tools outside formal IT governance; through free trials, personal credit cards, or sign-ups using personal email addresses, those tools do not appear in procurement records, expense systems, or SSO logs. They process work data without appearing in any register. They are ICT service arrangements that DORA requires to be documented, and processing activities that GDPR requires to be recorded, but they are invisible to the instruments organisations use to build those records.
Gartner estimates that 30% or more of SaaS spend in a typical enterprise represents waste, licences paid for tools that are not actively used or are duplicated across departments. That figure is worth reading as a compliance indicator, not just a financial one. The visibility gap that produces licence waste is the same visibility gap that produces an incomplete ICT register and an incomplete RoPA. An organisation that does not know what it is paying for does not know what it is using, and an organisation that does not know what it is using cannot satisfy the register obligations that DORA, GDPR, and the EU AI Act impose.
What A Compliant SaaS Inventory Actually Needs To Contain
The content requirements of a compliant SaaS and AI inventory are determined by the obligations it needs to discharge. Drawing from DORA Article 28, GDPR Article 30, and EU AI Act Article 26, a register that satisfies all three frameworks needs to capture, at minimum:
- Application identity: vendor name, product name, version or service tier, and the category of service (SaaS, cloud infrastructure, AI tool)
- Business function: which business processes the application supports and whether those functions are critical or important under DORA's classification
- Data processing details: what categories of personal data are processed, the legal basis under GDPR Article 6, and whether a data processing agreement is in place under GDPR Article 28
- Data residency: where data is stored and processed, and whether cross-border transfer mechanisms (Standard Contractual Clauses, adequacy decisions) are in place for non-EEA processing
- AI classification: for AI tools, the risk tier under the EU AI Act risk pyramid, whether the system falls into Annex III high-risk categories, and whether Article 5 prohibited practice indicators are present
- Access and ownership: which employees have access, who the internal owner is, and the date of the last access review
- Contractual and renewal information: contract value, renewal date, notice period, and whether the contract contains the Article 30 mandatory provisions required by DORA
This is materially different from what a finance-focused SaaS management tool tracks. The finance view; renewal dates, spend, licence counts, is necessary but not sufficient for regulatory compliance. A cost management instrument tells you what you are spending. A governance instrument tells you what you are using, what it does with data, and whether your use of it is defensible to a regulator. Most organisations have the first. Very few have the second.
The most common mistake that I always see is not a misunderstanding of the regulation, it is a misunderstanding of scope. Organisations assume that their IT asset register and their DORA ICT Third-Party Register are the same document, which they are not. When I ask a compliance team to compare both, the gap is almost always significant. The GDPR misreading I encounter most often is the belief that Article 30 only applies to the obvious data systems such as HR, CRM, and customer databases, which it does not. Every SaaS tool that touches personal data belongs in the Record of Processing Activities. The moment of realisation comes only when a supervisory authority asks for the RoPA, and the compliance team has to explain why half the tools currently processing personal data are not in it. - Namita Razdan, Co-founder, Montro |
The Audit Trail Requirement: A Register Is Not Enough
Regulatory frameworks do not only require that a register exists. They require evidence that it is maintained. The distinction matters because a register that was accurate six months ago and has not been updated since does not satisfy a continuous obligation.
DORA's Article 28.3 requires that the ICT register be kept current and made available to competent authorities on request, implying that it reflects the current state of ICT arrangements, not the state at last year's audit. GDPR's supervisory authorities, in assessing Article 30 compliance, examine not only whether a RoPA exists but whether it is accurate, which requires evidence of a process for keeping it updated when new tools are adopted or existing tools change their data processing activities.
This creates a maintenance obligation that a point-in-time inventory cannot satisfy. When a new SaaS tool is adopted, whether through formal procurement or through an employee signing up independently, it should appear in the register immediately, not at the next quarterly review. When an existing tool enables a new AI feature, the AI classification fields need updating. When an employee leaves and their access is not revoked, the register should reflect the access control gap.
A regulator reviewing your ICT register or your RoPA is not assessing your intentions. They are looking at whether the document reflects current reality. A register that was accurate at the last annual audit and has not been touched since is not a compliant register, it is a historical record. The organisations that pass supervisory reviews are not the ones with the most sophisticated tools. They are the ones that built a process for keeping the register current and can demonstrate that the process ran.
Frequently Asked Questions
Does DORA apply to SaaS tools adopted informally by employees?
Yes. DORA defines ICT services broadly under Article 3(21) as digital and data services provided through ICT systems on an ongoing basis. There is no requirement that the arrangement be formally procured or governed by a written contract for it to fall within scope. An employee using a SaaS tool in connection with the organisation's operations is an ICT service arrangement that the Article 28.3 register must document, which is precisely why shadow IT creates a structural compliance gap under DORA, not merely an operational one.
Is our IT asset register the same as a DORA ICT third-party register?
Not necessarily, and the distinction matters. A traditional IT asset register tracks hardware and software assets owned or licensed by the organisation. A DORA ICT third-party register documents service relationships with external providers; including SaaS tools, cloud services, and AI platforms adopted by any part of the organisation. The content requirements differ significantly: DORA Article 28.3 requires documentation of service criticality, contractual terms, concentration risk, and exit strategies, none of which a standard asset register captures. Many organisations have both and assume they overlap. In practice, the gaps between them tend to be where the enforcement risk sits.
What happens if our GDPR Article 30 RoPA is incomplete?
An incomplete RoPA is itself a demonstrable compliance failure under GDPR, independent of whether any data breach has occurred. Supervisory authorities across the EU treat the RoPA as the primary evidence of an organisation's data governance - it is typically the first document requested in any investigation or audit. A RoPA that omits SaaS tools processing personal data is incomplete by definition, and that incompleteness is attributable to the absence of a complete SaaS inventory. Fines for Article 30 failures fall under GDPR's lower tier, up to €10 million or 2% of global turnover, but the greater risk is that an incomplete RoPA signals broader governance failures that attract further scrutiny.
How does shadow IT affect EU AI Act compliance?
Shadow IT is where the EU AI Act's deployer obligations break down first. Article 26 requires human oversight, logging, and use in accordance with the system's intended purpose, but those obligations only apply to systems you know you are using. An AI tool that arrived through shadow IT has had none of that applied to it. From August 2026, a high-risk AI system being used without Article 26 controls in place is not a gap on a remediation list, it is active non-compliance. The enforcement risk sits not with organisations that assessed a tool and made a considered decision, but with those that were using one without knowing it.
Do we need separate registers for DORA, GDPR, and the EU AI Act?
Not necessarily, but the content requirements of each framework need to be satisfied within whatever structure you use. A single, well-structured SaaS and AI inventory can serve as the foundation for all three, provided it captures the right fields for each. Where organisations go wrong is building one instrument that satisfies the finance team's renewal tracking needs and then assuming it covers the regulatory obligations too. It rarely does. The better question to ask is: if a competent authority requested our ICT register tomorrow, and a supervisory authority requested our RoPA next week, would both documents reflect current reality? If the answer to either is uncertain, the register needs work.
