RegTech Glossary & Standards

RegTech Glossary & Standards is a structured reference for regulatory technology terms, standards, workflows and implementation concepts used in regulated SaaS products.

Oct

2026

The 10^25 FLOP threshold: what the AI Act never says

Article 51(2) of the EU AI Act (Regulation (EU) 2024/1689) presumes a general-purpose AI model has high-impact capabilities once the cumulative compute used to train it, measured in floating-point operations, exceeds 10^25. What the Act never spells out is how to actually count that number. Do earlier versions of a model contribute their compute to a later one’s tally? If a model is branched, is each branch’s compute counted separately or added together? A threshold this consequential, sitting with no counting methodology attached to it, is the whole story here.

What the threshold is and isn’t

Article 51(1) classifies a general-purpose AI model as presenting systemic risk if it meets either of two conditions: it has high-impact capabilities established through appropriate technical tools and methods, or the Commission has designated it as comparable, ex officio or following a qualified alert from the scientific panel, based on the criteria in Annex XIII. The 10^25 FLOP figure in Article 51(2) only speaks to the first route — it’s a rebuttable presumption that high-impact capabilities exist, not a definition of systemic risk itself, and not the only way a model ends up in scope. Article 51(3) lets the Commission adjust the threshold by delegated act to reflect the state of the art, including algorithmic improvements and more efficient hardware — so even the number itself isn’t fixed forever, only fixed until the Commission decides otherwise.

The contradiction at the centre

Recital 111 defines high-impact capabilities relative to the frontier: capabilities that match or exceed those recorded in the most advanced general-purpose AI models. That’s a moving target by design — as the frontier advances, the bar for “high-impact” moves with it. The 10^25 figure Article 51(2) actually operationalises this with is nothing of the sort: it’s fixed, absolute, and doesn’t move on its own between one delegated act and the next.

The practical consequence is exactly the one the Act’s own drafting implies but never resolves: a model that clears the relative, frontier-based bar this month may not clear it next month once competitors release something more capable, while the absolute FLOP number attached to that same model never changes at all. There’s a second problem sitting underneath this one — most frontier models are proprietary, so the actual comparator Recital 111’s test asks you to measure yourself against usually isn’t measurable at all. The relative definition and the absolute number were clearly meant to approximate each other. Nothing in the text guarantees they track.

The counting questions the text leaves open

Three practical questions decide whether a lot of real models sit above or below the line, and the Act answers only one of them.

Fine-tuning — this one has a real answer. Recital 111 states that the cumulative compute input used for training includes the total compute used for activities to improve the model’s capabilities prior to deployment, explicitly naming pre-training, synthetic data generation, and fine-tuning. So fine-tuning compute counts toward the cumulative total, at least for the fine-tuning that happens before a model’s initial deployment. What that doesn’t resolve is the harder version of the same question: whether fine-tuning or continued training applied after an earlier version was already placed on the market gets added to that version’s original tally, or starts a new count.

Prior iterations — genuinely unresolved. Nothing in the text says whether compute spent on earlier versions of a model contributes to a later version’s cumulative figure, which matters enormously for any provider that iterates on the same underlying architecture across releases rather than training each version from nothing.

Branches — also unresolved. If a single training run forks into multiple variants, nothing says whether each branch’s compute is counted independently or whether the branches’ compute is summed as one cumulative figure against the threshold.

Annex XIII gives the Commission its own set of proxies for the designation route — estimated training cost, time, or energy consumption, as alternatives to a direct FLOP count — but it’s unclear whether a provider doing its own self-assessment under Article 51(2) has to use the same criteria, and none of these proxies answer the iteration or branching questions regardless of which measure you use.

The other Annex XIII numbers

The FLOP threshold gets all the attention, but Annex XIII gives the Commission six other criteria to weigh when designating a model as comparable under Article 51(1)(b), and one of them is rarely quoted at all:

the number of parameters in the model;
the quality or size of the training dataset, for example measured in tokens;
the amount of compute used to train it, measured in FLOPs, or expressed through a combination of other variables such as estimated cost, time, or energy consumption;
the model’s input and output modalities — text-to-text, text-to-image, multimodal — along with advanced thresholds for high-impact capabilities specific to each modality, and the particular type of input or output involved, such as biological sequences;
benchmarks and capability evaluations, including the number of tasks the model performs without additional training, its adaptability to learn new distinct tasks, its degree of autonomy and scalability, and the tools it can access;
whether it has a large impact on the internal market because of its reach — which is presumed once the model has been made available to at least 10,000 registered business users established in the EU;
the number of registered end-users.

What you do when you cross it

If a model meets the Article 51(1)(a) condition, the provider notifies the Commission without delay, and in any event within two weeks of the condition being met or of it becoming known that it will be met. The notification has to include the information needed to demonstrate the condition is satisfied. Providers aren’t limited to reporting the fact, either — in that same notification, a provider can put forward sufficiently substantiated arguments that, despite meeting the threshold, the model exceptionally doesn’t present systemic risks because of its specific characteristics, and therefore shouldn’t be classified as a systemic-risk model. If the Commission decides those arguments aren’t sufficiently substantiated, it rejects them, and the model is treated as a systemic-risk model regardless.

The appeal loop

The self-notification route comes with a built-in argument mechanism. The Commission’s own ex officio designation route, under Article 51(1)(b), doesn’t have an equivalent express provision letting a provider make its case before the decision is made — which pushes toward providers over-notifying rather than risk being designated without having had the chance to argue first.

Once a model has been designated this way, though, there is a path back. A provider can submit a reasoned request for reassessment, and the Commission will consider whether the model, measured against the Annex XIII criteria, is still properly considered a systemic-risk model. That request has to rest on objective, detailed, and new reasons that came to light after the designation decision — not a restatement of the original case — and the earliest a provider can make it is six months after the designation. If the Commission reassesses and decides to maintain the designation anyway, the provider has to wait another six months before trying again. There’s no cap on how many times this can repeat, only the six-month cooldown between each attempt.

Frequently asked questions

Is 10^25 a hard line?

No, in either direction. Above it, a provider can still argue its way out under Article 51(2) and 52(2)-(3) if it can substantiate that the model’s specific characteristics mean it doesn’t actually present systemic risk. Below it, the Commission can still designate a model under Article 51(1)(b) if it finds comparable capabilities or impact using the Annex XIII criteria. The number sets a presumption, not a verdict.

Who publishes the list of systemic-risk models?

The Commission does. Article 52(6) requires it to publish and keep an up-to-date list of general-purpose AI models with systemic risk, though that duty is itself qualified by the need to respect intellectual property rights and protect confidential business information and trade secrets under EU and national law.

Does the Omnibus change Articles 51-55?

No. This is one of the more consistently confirmed points across current commentary: the Digital Omnibus reform is squarely focused on the Annex III and Annex I high-risk timeline, registration, and related provisions. The general-purpose AI rules in Articles 51 through 55 have applied since 2 August 2025 and remain untouched by the reform.

What if we don’t know our own FLOP count?

The Act doesn’t offer a substitute self-certification route for this situation — the cost, time, and energy proxies in Annex XIII exist for the Commission’s own comparable-capabilities designation under Article 51(1)(b), not explicitly as an alternative counting method a provider can rely on for its own Article 51(2) self-assessment. A provider without confident compute accounting is sitting in exactly the gap this article describes, without a clearly signposted way out of it.

Can we be designated without ever notifying?

Yes. Article 52(1) states plainly that if the Commission becomes aware of a general-purpose AI model presenting systemic risks that it hasn’t been notified about, it can decide to designate that model as one anyway. Notification is the expected route in; it isn’t the only route the Commission can use to get there.

Aug

2026

What Is Regulatory Risk in Product Management?

Definition

Regulatory risk in product management is the risk that a product decision, feature, workflow, data process, claim, integration, or release may fail to meet applicable legal, regulatory, contractual, or industry requirements. For product, compliance, and SaaS teams, it means identifying where product choices can create exposure for the company or its customers, then designing controls, evidence, and governance into the product lifecycle.

Regulatory risk is not limited to legal interpretation. It appears in product discovery, data modeling, permissions, UX, API behavior, third-party integrations, documentation, monitoring, incident handling, and go-to-market messaging.

Why It Matters for Product Teams

Regulatory risk in product management matters because many SaaS products operate in environments where mistakes can block enterprise deals, delay launches, trigger rework, weaken customer trust, or create audit and reporting problems.

Product teams need to understand regulatory risk when building features that involve personal data, financial workflows, healthcare data, AI outputs, legal documents, government reporting, payments, employment decisions, sustainability claims, chemical data, or cross-border data transfers.

A strong product approach turns regulatory risk into practical product questions:

What obligation affects this workflow?
Who is responsible for the action or submission?
What data is collected and why?
What evidence must be retained?
What happens if the system fails?
What can the customer prove later?
Which claim should sales and marketing avoid?

The goal is not to make product teams act as lawyers. The goal is to ensure that legal and compliance requirements are translated into product controls before risk becomes expensive.

Common Implementation Questions

What should teams assess first?

Start with the regulated workflow. Identify the user action, data involved, customer obligation, jurisdiction, applicable rule, third-party dependency, evidence requirement, and failure scenario. Then map which product controls are needed.

Is regulatory risk only a compliance responsibility?

No. Compliance teams interpret obligations, but product and engineering teams implement the actual controls. Regulatory risk depends on permissions, validation rules, audit logs, data retention, deletion workflows, reporting logic, integrations, notifications, and support processes.

What product features reduce regulatory risk?

Common controls include role-based access control, approval workflows, validation rules, audit trails, version history, consent capture, data minimization, retention settings, deletion workflows, monitoring, exception handling, incident workflows, and customer-facing documentation.

How should teams handle regulatory uncertainty?

When rules are unclear or evolving, product teams should document assumptions, involve compliance early, design configurable workflows, avoid over-specific hardcoding, maintain change monitoring, and keep customer-facing claims precise.

What is the biggest implementation risk?

The biggest risk is discovering regulatory requirements after the product architecture is already built. Late-stage compliance review often leads to rework, manual workarounds, weak evidence, unclear ownership, and features that are difficult to operate safely.

Can a vendor say the product is “fully compliant”?

Use caution. “Fully compliant” is risky unless the vendor defines the regulation, jurisdiction, customer role, product scope, evidence model, controls, and date of assessment. Stronger wording explains what the product supports: access controls, audit trails, reporting, approvals, data governance, retention, monitoring, or compliance evidence.

Related Standards

Regulatory risk in product management often overlaps with broader risk, compliance, security, and governance frameworks. Relevant references include ISO 31000 for risk management principles and guidelines, ISO 37301 for compliance management systems, and ISO/IEC 27001 for information security management systems. (ISO)

Other relevant frameworks may include SOC 2, NIST Cybersecurity Framework, GDPR, privacy-by-design principles, internal control frameworks, records management policies, and sector-specific regulations.

These frameworks do not create one universal product risk model. They help teams structure risk identification, control ownership, documentation, monitoring, audit readiness, and continuous improvement.

Aug

2026

“Safety component” after the Omnibus: a narrower test

The Digital Omnibus narrows the definition that decides whether AI embedded in a regulated product counts as high-risk under the EU AI Act (Regulation (EU) 2024/1689). AI used solely for user assistance, performance optimisation, service efficiency or automation, or convenience or quality control no longer makes a component a “safety component” — and doesn’t trigger high-risk classification by virtue of sitting inside a regulated product — unless its failure or malfunction would actually endanger health or safety. Separately, the Machinery Regulation moved out of Annex I Section A into Section B entirely, so AI-enabled machinery now complies with sectoral safety rules instead of both regimes at once. Every guide written before May 2026 is describing a test that no longer applies.

The old test and why it swept too wide

Article 6(1) classifies an AI system as high-risk when two conditions are both met: it’s intended for use as a safety component of a product, or is itself a product, covered by the Annex I Union harmonisation legislation; and that product requires third-party conformity assessment under that legislation before it can be placed on the market. Whether an AI function counts as a “safety component” in the first place decides whether this whole test even applies.

The original definition of safety component covers a component that fulfils a safety function for a product or AI system, or whose failure or malfunction endangers the health and safety of persons or property. That second limb is where the trouble sits. Read expansively, almost any function embedded in a regulated product can be argued into it — an optimisation model inside a lift or a boiler doesn’t itself perform a safety function, but a sufficiently loose reading of “failure… endangers health and safety” could sweep it in anyway, on the theory that anything going wrong inside safety-regulated machinery carries some attenuated safety implication.

What the new test asks

The narrowed definition collapses this to one question: could the component’s failure or malfunction actually endanger health or safety? If the answer is no, and the function is assistance, optimisation, efficiency, automation, convenience, or quality control, it isn’t a safety component — regardless of what product it happens to sit inside.

Two examples on either side of the line. A predictive-maintenance model that flags when industrial machinery needs servicing is squarely an optimisation function: if it fails, the direct consequence is a missed maintenance window, not an immediate safety event, so it’s a strong candidate for falling outside the safety-component definition under the new test. A torque-limiting or collision-avoidance function built into the same machinery is a different case entirely — its failure directly creates a safety risk, which is exactly what the carve-out was never meant to exempt. The label attached to a function matters far less than what actually happens when it fails.

Annex I Section A vs Section B

This distinction decides how much of the Act applies at all. Section A covers New Legislative Framework legislation — medical devices, toys, personal protective equipment, gas appliances, and, until this reform, machinery. Section B covers other Union harmonisation legislation, including aviation security, agricultural and forestry vehicles, motor vehicle type-approval, marine equipment, and rail interoperability. For systems in Section B, only Article 6(1) itself, Articles 102 to 109, and Article 112 apply — essentially none of the Act’s substantive high-risk apparatus, the conformity assessment procedures, or the registration duties reach them at all.

The Omnibus moved only the Machinery Regulation from Section A to Section B. That’s a narrower outcome than what was actually on the table during trilogue: the deadlock that briefly collapsed negotiations centred on a Parliament proposal to exclude far more broadly — medical devices, toys, connected cars, and industrial machinery all together. The final compromise pulled back to Machinery alone. It isn’t a deregulation of industrial AI, either — the Commission is empowered to adopt delegated acts under the Machinery Regulation itself, not the AI Act, adding AI-specific health and safety requirements for systems that would otherwise have been high-risk. Oversight doesn’t disappear; it moves into the sectoral regime.

The other overlap relief, and its condition

Products that stayed in Section A — medical devices and toys among them — get a different, conditional form of relief instead of a full carve-out. Where the sectoral legislation already contains AI-specific requirements equivalent to or higher than the AI Act’s own, the Commission may, by implementing act, limit how far Articles 9 to 15 and 17 to 25 actually apply to those systems. That’s a genuinely different legal instrument from the Machinery-specific delegated acts, and it comes with its own timing: implementing acts addressing this general sectoral overlap are expected by 2 August 2027, while the Machinery-specific delegated acts are expected by 2 August 2028, tied to when Annex I obligations actually start binding. Both dates are worth putting on a calendar. Neither is a rule you can rely on today — nothing is actually limited until the Commission acts.

When any of this binds

Annex I high-risk obligations now apply from 2 August 2028 rather than 2 August 2027, under the same Digital Omnibus reform that deferred Annex III obligations to 2 December 2027. As with every date in this reform, it binds only once the amending regulation is published in the Official Journal and enters into force — as of this writing, formal adoption and publication were still pending, with the original 2 August 2026/2027 calendar remaining the legally operative one until that happens.

Frequently asked questions

Is a predictive maintenance model a safety component?

Generally not, under the narrowed test — unless the specific machine’s failure mode makes a missed service interval itself a direct safety event rather than an efficiency loss. That’s genuinely fact-specific: the same category of model can land on either side depending on what actually happens when the maintenance flag is missed.

Does the Medical Devices Regulation change?

Not in the same way. Medical devices remain in Annex I Section A — they didn’t get the Machinery-style move to Section B. What they get instead is the conditional relief described above: if the Commission determines, by implementing act, that the sectoral legislation already imposes equivalent AI-specific requirements, application of the relevant AI Act articles can be limited. Until that happens, the full parallel regime still applies.

What about toys and lifts?

Both stay in Section A, on the same footing as medical devices — eligible for the conditional implementing-act relief if the Commission acts, but not moved to Section B the way Machinery was. Lifts in particular sit under their own directive, separate from the Machinery Regulation, and nothing in this reform touched that separately.

Does “quality control” cover visual inspection?

Often, but not automatically. A visual-inspection model that flags defective units for human review before they’re used is a strong fit for the quality-control carve-out — its failure means a defect goes unflagged, not an immediate safety event. But if that inspection is the only safeguard standing between a genuinely dangerous defective unit and its use, the “failure would endanger health or safety” test can still catch it. The function’s name doesn’t decide the answer; the actual consequence of it failing does.

Who decides — us or the notified body?

The provider makes the initial classification call, consistent with how Article 6 works generally — nobody else does it for you upfront. Where third-party conformity assessment still applies, a notified body’s scope determination matters downstream, but a market surveillance authority retains the ordinary power to review a provider’s classification later and require correction if it disagrees, the same oversight mechanism that applies to Article 6(3) classification calls elsewhere in the Act.

Jul

2026

What Is a LegalTech API?

Definition

A LegalTech API is an application programming interface that allows software products to connect with legal technology systems, data, workflows, and services. It can enable contract automation, e-signature, identity verification, document generation, matter management, legal intake, compliance checks, audit logging, e-discovery, legal research, or contract lifecycle management.

For product, compliance, and SaaS teams, a LegalTech API is not just a technical connector. It is a controlled interface for handling legally sensitive workflows, confidential documents, regulated data, approvals, evidence, and records that may need to be reviewed, audited, or produced later.

Why It Matters for Product Teams

LegalTech APIs matter because legal workflows increasingly sit inside SaaS products rather than separate legal tools. Product teams may need to embed contract signing, policy acceptance, consent capture, document review, regulatory checks, or legal approval workflows directly into customer-facing software.

Legal technology broadly refers to software and digital tools that support, streamline, or automate legal work, including contracts, matters, legal entities, compliance processes, and document workflows. (Dilitrust)

For SaaS teams, the product risk is not only whether the API works. The system must preserve confidentiality, access control, auditability, version history, jurisdiction-specific requirements, evidence integrity, and customer trust.

A weak LegalTech API integration can create hidden risk: missing audit trails, unclear consent records, broken approval workflows, poor document retention, weak permission models, or overbroad claims about legal validity.

Common Implementation Questions

What does a LegalTech API usually support?

Common use cases include:

contract generation and redlining
e-signature workflows
document storage and retrieval
matter and case management
legal intake and approval routing
identity verification
compliance screening
audit logs and evidence records
e-discovery and document review
policy acceptance and consent tracking

The exact scope depends on the product, customer type, jurisdiction, and legal workflow.

Is a LegalTech API only for legal teams?

No. LegalTech APIs often support workflows used by sales, procurement, HR, finance, compliance, customer success, and operations. For example, a contract workflow may start in a sales CRM, pass through legal approval, require finance review, trigger e-signature, and then sync metadata back to a billing or ERP system.

What should product teams define before integration?

Teams should define the legal workflow before choosing the endpoint. Key questions include:

What legal event is being captured?
Who has authority to approve or sign?
What document version is authoritative?
What evidence must be stored?
What data is confidential or privileged?
What retention rules apply?
What happens if the API fails?
Which system is the source of truth?

What matters most for e-signature APIs?

For e-signature use cases, teams should understand signature levels, identity assurance, audit trails, timestamps, document integrity, signer authentication, and jurisdiction-specific requirements. In the EU, eIDAS defines three levels of electronic signature: simple, advanced, and qualified. (European Commission)

What is the biggest implementation risk?

The biggest risk is treating a legal workflow like a generic automation task. Legal processes often depend on evidence, authorization, retention, confidentiality, and procedural correctness. If those requirements are not designed into the product, the API may create efficiency while weakening legal reliability.

Can a vendor claim a LegalTech API is “fully compliant”?

Use caution. “Fully compliant” is risky unless the vendor defines the jurisdiction, workflow, legal effect, data scope, security controls, customer role, and date of assessment. Stronger wording explains what the API supports: audit trails, access controls, document integrity, e-signature evidence, retention workflows, approval routing, or secure data exchange.

Related Standards

LegalTech API implementations often overlap with security, privacy, identity, and legal trust frameworks, including:

GDPR for personal data protection
eIDAS for EU electronic identification and trust services
ISO/IEC 27001 for information security management
ISO/IEC 27701 for privacy information management
SOC 2 for security and operational controls
NIST Cybersecurity Framework for security risk management
ESIGN Act and UETA for US electronic signature context
PAdES and related standards for PDF signature validation
internal retention and legal hold policies

These frameworks do not create one universal LegalTech API standard. They help teams structure security, privacy, identity, evidence, auditability, and operational controls around legal workflows.

Jul

2026

What Is REACH Compliance Software?

Definition

REACH compliance software is a digital system that helps companies manage obligations under the EU REACH Regulation: Registration, Evaluation, Authorisation and Restriction of Chemicals. REACH applies to chemical substances manufactured, imported, placed on the market, or used in the EU, and requires companies to identify and manage risks related to substances, communicate chemical safety information, and meet applicable registration, authorisation, restriction, and supply chain duties.

For product, compliance, and SaaS teams, REACH compliance software turns chemical regulatory requirements into operational workflows: substance tracking, supplier data collection, document management, risk monitoring, customer communication, and audit evidence.

Why REACH Compliance Software Matters

REACH compliance software matters because chemical compliance depends on accurate, current, and traceable product data. Many companies need to manage substances across suppliers, materials, formulations, articles, safety data sheets, declarations, and regulatory lists.

For SaaS teams serving manufacturers, retailers, distributors, or supply chain operators, the product challenge is not only storing chemical data. The system must support changing regulatory requirements, supplier evidence, restricted substances, substances of very high concern, customer requests, and internal accountability.

A strong implementation helps teams reduce manual spreadsheet work, improve data quality, prepare customer and authority responses, and maintain a clearer compliance record.

Common Implementation Questions

What does REACH compliance software usually do?

Common capabilities include substance inventory management, supplier declaration workflows, safety data sheet management, restricted substance screening, SVHC monitoring, authorisation and restriction tracking, document storage, audit trails, customer request management, and reporting.

The exact scope depends on the company’s role: manufacturer, importer, downstream user, distributor, article supplier, or software provider supporting those organizations.

Is REACH only about chemical manufacturers?

No. REACH affects many companies that manufacture, import, distribute, sell, or use chemical substances, mixtures, or articles in the EU. The European Commission notes that substances above one tonne per year per company generally need registration with ECHA, while other duties can apply through authorisation, restriction, and supply chain communication.

What data should teams manage first?

Start with a structured product and substance inventory. Key data may include product identifiers, material composition, supplier declarations, substance names, CAS or EC numbers, tonnage bands, use cases, SDS files, exposure information, restriction status, SVHC status, and customer-facing compliance statements.

How does software support supply chain communication?

REACH requires chemical information to move through the supply chain. Software can help collect supplier declarations, manage evidence, track missing data, send questionnaires, update records, and respond to customer or consumer requests with consistent information. The Swedish Chemicals Agency notes that REACH includes requirements for users of chemicals and rules about information that must be given to customers.

What is the biggest implementation risk?

The biggest risk is treating REACH as a static checklist. Substance lists, supplier data, product compositions, restrictions, and authorisation requirements can change. A useful system needs ownership, review cycles, change monitoring, version control, and clear escalation when a substance or product becomes affected.

Can a vendor claim REACH compliance?

Use caution. “Fully compliant” is risky unless the vendor defines the product scope, company role, substances covered, regulatory obligations, evidence sources, and date of assessment. Stronger wording explains what the software supports: substance inventory, supplier workflows, SVHC tracking, restriction screening, document control, audit trails, or customer response management.

Related Standards and Frameworks

REACH compliance software often connects with broader product compliance and chemical management frameworks, including CLP Regulation, safety data sheet requirements, restricted substance list management, supplier due diligence processes, product lifecycle management, ERP systems, and material declaration standards such as IEC 62474 for electrotechnical products.

These frameworks do not replace REACH obligations, but they help structure product data, hazard communication, supply chain evidence, and compliance workflows.

Jul

2026

What Are DORA IT Controls?

Definition

DORA IT controls are the governance, security, monitoring, testing, incident response, and third-party risk management measures used to meet the Digital Operational Resilience Act requirements. DORA, Regulation (EU) 2022/2554, is the EU framework for digital operational resilience in the financial sector. It has applied since 17 January 2025 and is designed to ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions such as cyberattacks, system failures, and third-party service outages.

For product, compliance, and SaaS teams, DORA IT controls are not only internal security policies. They define how systems are designed, operated, monitored, tested, documented, and supported when serving regulated financial customers.

Why DORA IT Controls Matter

DORA IT controls matter because financial entities must manage ICT risk in a consistent and auditable way. This affects banks, insurers, investment firms, payment institutions, crypto-asset service providers, and other financial entities covered by DORA.

For SaaS vendors serving financial customers, DORA can influence procurement, contractual requirements, service-level expectations, incident reporting workflows, audit rights, resilience testing, subcontractor management, and evidence requests. A product may be technically strong but still create customer risk if it cannot support operational resilience expectations.

Core Areas of DORA IT Controls

ICT risk management

Teams need policies, processes, and technical controls to identify, protect, detect, respond to, and recover from ICT risks. This may include asset inventories, access management, vulnerability management, backup and recovery, encryption, logging, change management, business continuity, and disaster recovery.

ICT incident management

DORA requires structured handling of ICT-related incidents. Product and SaaS teams should define incident classification, escalation paths, customer notification workflows, root cause analysis, evidence retention, and communication responsibilities.

Digital operational resilience testing

Resilience controls must be tested. This can include vulnerability assessments, scenario testing, penetration testing, business continuity tests, failover tests, backup restoration tests, and, for certain entities, advanced threat-led penetration testing.

Third-party ICT risk management

DORA places strong emphasis on ICT third-party risk. SaaS teams should expect customers to ask for information about hosting providers, subcontractors, critical dependencies, data locations, exit plans, security controls, and contractual safeguards.

Information sharing and governance

DORA also supports structured governance and, in some contexts, information sharing on cyber threats. Internally, teams need clear ownership, board-level accountability where applicable, documented policies, control evidence, and regular review cycles.

Common Implementation Questions

Are DORA IT controls only relevant to financial institutions?

No. DORA directly applies to covered financial entities, but SaaS vendors and ICT providers may be affected through customer contracts, due diligence, outsourcing requirements, oversight expectations, and requests for evidence.

What should SaaS teams prepare first?

Start with a control inventory mapped to DORA-relevant areas: ICT risk management, incident response, resilience testing, third-party dependencies, access control, logging, business continuity, and data protection. Then identify which controls are already documented and which need stronger evidence.

What evidence do customers usually request?

Common evidence may include security policies, SOC 2 or ISO certifications, penetration test summaries, business continuity plans, disaster recovery test results, incident response procedures, subcontractor lists, data processing locations, access control policies, audit logs, and service-level documentation.

Can a vendor claim DORA compliance?

Use caution. “Fully compliant” is risky unless the vendor clearly defines its role, scope, services, customer type, contractual obligations, and evidence base. Stronger wording explains what the vendor supports: resilience testing, incident workflows, audit evidence, third-party risk documentation, access controls, logging, and continuity planning.

Related Standards and Frameworks

DORA IT controls often overlap with established security and resilience frameworks, including ISO/IEC 27001, ISO/IEC 22301, SOC 2, NIST Cybersecurity Framework, NIST SP 800-53, CIS Controls, and COBIT. These frameworks do not replace DORA, but they can help structure control design, evidence collection, and audit readiness.

Jul

2026

What Is Digital Product Passport (DPP) Implementation?

Definition

Digital Product Passport (DPP) implementation is the process of creating, managing, and sharing structured digital product data across a product’s lifecycle. A DPP links a physical product, component, or material to a digital record containing information such as composition, origin, repairability, sustainability data, compliance documentation, and end-of-life instructions.

In the EU, Digital Product Passports are a core part of the Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781, which entered into force in 2024. The ESPR establishes a framework for future product-specific requirements, including DPP requirements for relevant product groups.

Why Digital Product Passport Implementation Matters

Digital Product Passport (DPP) implementation matters because product transparency is becoming a compliance, supply chain, and market-access requirement. For product, compliance, and SaaS teams, a DPP is not just a QR code or database. It is an operational system for collecting, validating, updating, and exposing product information to the right stakeholders.

A DPP can support:

regulatory compliance
product traceability
sustainability reporting
circular economy workflows
repair, reuse, and recycling
supply chain due diligence
customer and partner transparency
customs and market surveillance checks

For software teams, the main challenge is not only storing product data. It is designing a reliable data model, access-control system, integration layer, and governance process that can survive changing regulatory and product-specific requirements.

Common Implementation Questions

What data should a DPP include?

The exact data requirements depend on the product category and applicable regulation. A DPP may include product identifiers, manufacturer information, material composition, carbon footprint data, repair instructions, spare parts information, conformity documentation, durability data, recycling guidance, and supply chain information.

Teams should avoid assuming one universal DPP template. The ESPR sets the framework, while specific requirements are expected to be defined through product-specific rules and delegated acts.

Which products are affected first?

Batteries are one of the clearest early examples. Under the EU Battery Regulation, certain batteries will require a battery passport from 2027. Broader DPP requirements under the ESPR will be phased in by product category, with priority areas defined through the Commission’s working plans and future implementing measures.

Is a DPP just a QR code?

No. A QR code or other data carrier is only the access point. The real implementation includes product identifiers, data governance, system integrations, access rights, data validation, hosting, interoperability, lifecycle updates, and auditability.

A weak DPP implementation treats the passport as a static product page. A strong implementation treats it as a controlled product data infrastructure.

Who owns DPP implementation?

DPP implementation usually requires collaboration between product, compliance, sustainability, supply chain, engineering, legal, and data teams. In SaaS organizations, product teams often own the user workflows and system requirements, while compliance teams define obligations and evidence needs.

What is the biggest implementation risk?

The biggest risk is starting too late with fragmented product data. Many companies already hold some required information, but it may sit across ERP systems, supplier documents, spreadsheets, PLM tools, certification files, and sustainability reports. DPP readiness depends on turning that scattered data into structured, verified, accessible records.

Can a vendor claim DPP compliance?

Use caution with broad claims. “Fully compliant” is risky unless the vendor specifies the product category, applicable regulation, required data fields, technical standard, access model, and date of assessment. Stronger wording explains what the system supports: product identity, data collection, supplier workflows, access control, audit trails, lifecycle updates, or regulatory reporting.

Related Standards and Frameworks

DPP implementation is closely linked to product identification, data exchange, lifecycle information, and interoperability standards. Relevant areas include:

product identifiers and data carriers
GS1 Digital Link and related identification standards
ISO standards for product lifecycle data
circular economy and sustainability data frameworks
EU ESPR requirements
EU Battery Regulation requirements
future European harmonised standards for DPP interoperability

The regulatory and technical standards landscape is still developing, so teams should design DPP systems to be modular, interoperable, and adaptable.

Jun

2026

What Is EU AI Act Compliance?

Definition

EU AI Act compliance is the process of ensuring that an AI system is designed, deployed, documented, monitored, and governed in line with the European Union’s Artificial Intelligence Act. The EU AI Act is a risk-based regulatory framework: it sets stricter obligations for AI systems that create higher risks, while applying lighter requirements to lower-risk systems. The Act entered into force on 1 August 2024, with most rules applying from 2 August 2026 and some obligations applying earlier or later depending on the AI system type.

For product, compliance, and SaaS teams, EU AI Act compliance means understanding how AI is used in the product, what risk category applies, which obligations are triggered, and what evidence the organization must maintain.

Why EU AI Act Compliance Matters

EU AI Act compliance matters because AI governance is becoming part of product readiness, enterprise procurement, and market access. A product that uses AI may need clear answers about risk classification, transparency, data governance, human oversight, technical documentation, monitoring, and accountability.

For SaaS teams, this affects product discovery, roadmap planning, release management, customer documentation, vendor due diligence, and sales claims. Compliance cannot be added only at the end of development if the product architecture, user experience, data flows, or model behavior create regulatory exposure.

Common Implementation Questions

What should teams do first?

Start with an AI system inventory. List where AI is used, what each system does, who uses it, what data it processes, what outputs it produces, and whether it affects decisions, access, rights, safety, employment, education, finance, healthcare, or other sensitive contexts.

How is risk classified?

The EU AI Act uses a risk-based approach. Some AI practices are prohibited, high-risk systems face detailed requirements, certain AI systems have transparency obligations, and many lower-risk uses face limited or no specific AI Act obligations. Prohibited-practice rules started applying from 2 February 2025, while transparency and many high-risk rules apply later in the implementation timeline.

Is this only a legal task?

No. Legal teams interpret obligations, but product and engineering teams define how the system actually works. Compliance depends on product design, data quality, model evaluation, user controls, logging, monitoring, incident handling, documentation, and customer-facing communication.

What evidence is usually needed?

Teams may need risk assessments, technical documentation, model and data records, transparency notices, human oversight procedures, testing results, monitoring plans, incident response processes, and governance records. The exact requirements depend on the role of the organization and the AI system’s risk category.

Can a vendor say it is “fully compliant”?

Use caution. “Fully compliant” is often too broad unless the vendor can specify the system, role, jurisdiction, risk category, obligations, evidence, and date of assessment. Stronger wording explains what the product supports: inventory, classification, documentation, transparency, audit trails, oversight workflows, or risk management.

Related Standards

Relevant frameworks include ISO/IEC 42001, an AI management system standard, and ISO/IEC 23894, which provides guidance on AI risk management. The NIST AI Risk Management Framework is also commonly used to structure AI risk governance, although it is not an EU law. European harmonised standards are expected to support AI Act conformity in areas such as risk management, transparency, human oversight, cybersecurity, and quality management.