An EU compliance platform can help an organisation reuse information about systems, suppliers and evidence across GDPR, NIS2, DORA and the AI Act. The buying question is whether it preserves each regime’s legal requirements while reducing duplicated work. Four module names on a proposal do not establish that the organisation needs all four, that the required outputs are available, or that a single subscription costs less overall.
Start with your legal entities, regulated activities and operating processes. Then evaluate the platform against decisions your teams must actually make. This guide addresses that buying exercise. The wider EU compliance stack describes the surrounding tool landscape; a platform still needs to work with the systems that produce operational evidence.
Confirm scope before comparing modules
GDPR scope is not simply “anyone processing EU personal data”. Articles 2 and 3 distinguish material and territorial scope, including processing in the context of an EU establishment and certain offering or monitoring activities concerning people in the Union. Nationality alone is not the trigger. Identify whether each entity acts as controller, processor or both for different operations, then determine the obligations attached to those roles.
NIS2 is a directive implemented through national law. Its sector and size rules contain exceptions, including categories reached irrespective of size, and its jurisdiction rules need separate attention. A group’s business label is not enough to classify every subsidiary. Country implementation also matters: as checked on 28 September 2026, France’s parliamentary dossier still records the bill at first reading in the National Assembly, with debate scheduled for 7 October. Software should distinguish a preparatory French requirement from an enacted national obligation.
DORA has applied since 17 January 2025 to financial entities within its scope, subject to the regulation’s exclusions and differentiated rules. ICT suppliers designated as critical face a specific oversight framework. A technology supplier does not become a financial entity merely because a bank is its customer. The customer may nevertheless require contractual terms, information and support that the supplier must be able to provide.
For financial entities covered by the relevant NIS2 relationship, DORA is a sector-specific Union legal act under NIS2 Article 4. Do not configure duplicate NIS2 risk-management and incident-reporting duties where the sector-specific regime displaces the corresponding requirements and supervision. The DORA and NIS2 comparison provides context; the scope decision should remain recorded for the actual entity and obligations.
The AI Act also depends on roles, systems and intended purposes. Providers, deployers, importers and distributors do not have interchangeable duties, and general-purpose AI models have their own framework. An internal inventory helps establish those facts, but the Act does not impose the same mandatory register, logging and serious-incident obligations on every organisation using any AI feature. Ask the supplier to demonstrate how it distinguishes an ordinary deployment from a use that requires a different assessment.
Use the current AI Act timetable
The original statement that all high-risk duties start in August 2026 is no longer an adequate buying assumption. Regulation (EU) 2026/1744, the AI Omnibus, amended the timetable. Its official legislative text sets 2 December 2027 for the relevant high-risk provisions concerning Article 6(2) and Annex III systems, and 2 August 2028 for Article 6(1) and Annex I systems. These dates concern the specified high-risk provisions, not a suspension of the entire AI Act.
The Commission’s current implementation timeline separately identifies prohibitions, general-purpose model duties and transparency requirements. Article 50 transparency rules began applying in August 2026, with a specific transition for certain systems already marketed before that date. A procurement team should therefore ask which version of the law drives each workflow and how amendments affect existing assessments. A fixed “AI Act compliant” status is less useful than a dated, reviewable applicability decision.
Our AI Act software guide focuses on these evaluation questions. Where personal data is involved, the GDPR and AI Act platform discussion helps distinguish the assessments that may coexist. Neither an AI classification nor a GDPR assessment automatically answers the other regime’s questions.
Establish the outputs you actually need
A GDPR record of processing activities describes processing, purposes, categories, recipients, retention and other Article 30 information. It is not a list of every software licence. The exemption for organisations with fewer than 250 employees is qualified: non-occasional processing, processing likely to result in a risk to rights and freedoms, and processing involving Article 9 categories or Article 10 criminal data exclude the exemption for the relevant activities. Do not let a headcount field disable all records automatically.
The Article 30 data model helps specify a usable output. A legal-basis field is valuable for accountability and related notices, but is not expressly listed in Article 30’s minimum contents. A procurement specification should distinguish statutory fields, information required elsewhere and internal management fields. That distinction makes a missing field easier to assess instead of treating every template preference as a legal defect.
DORA’s register of information concerns contractual arrangements for ICT services, with the required entity and consolidation levels and distinctions for services supporting critical or important functions. It is not limited to suppliers already designated critical by the European supervisory authorities. Article 28 and the implementing templates require relationships between entities, arrangements, providers, services and functions. The register of information guide supports the mapping exercise; the export must still be checked against the applicable official templates and reporting instructions.
NIS2 Article 21 requires cybersecurity risk-management measures; it does not establish a universal ROPA-style register with the same fields as GDPR. Documenting systems, risks, controls and decisions can help demonstrate those measures, while national and sector rules determine additional details. Likewise, an AI inventory is a useful discovery tool, but does not replace the documentation, registration or logging required for a particular role and system. The platform should show the actual output associated with an obligation, not rename one spreadsheet four times.
Share supplier facts while preserving different relationships
Consider a hypothetical cloud provider used by a financial subsidiary and a manufacturing subsidiary. Its legal identity can be recorded once. The services, contracts, locations and dependencies may differ. Its role as a GDPR processor must be assessed for the personal-data operations concerned; its importance to the financial subsidiary’s continuity and its relevance to the manufacturer’s NIS2 supply chain answer different questions.
For GDPR processing, Article 28 requires a written contract or another binding Union or Member State legal act, including electronic form. In an ordinary commercial procurement, review the relevant contract, instructions, security terms, assistance and subprocessor arrangements. A DORA contract assessment then examines the applicable ICT terms, with additional requirements for services supporting critical or important functions. A green status on the GDPR agreement should not silently approve those separate conditions.
The controller and processor distinction is especially useful when a supplier performs several functions. Ask the platform to link a role to a specific activity or service rather than assigning it permanently to the supplier’s name. If the provider processes some information for its own purposes, a single global “processor” label may give reviewers the wrong instructions.
Change a supplier’s support location during the demonstration. The system should identify potentially affected records and assign reviews. It should preserve previous decisions instead of overwriting them or declaring every connected framework compliant. Check whether the trigger comes from a real integration, a manual entry or a periodic questionnaire, and who investigates an incomplete response.
Reuse evidence without reusing every conclusion
A penetration-test report may support several assessments, but its relevance depends on the tested service, scope, date and limitations. A report covering one region does not automatically cover a newly acquired subsidiary. A policy proves that an instruction exists; it does not establish that every access review occurred. Ask the vendor to distinguish a document, an implemented control, a verification result and an accountable decision.
Risk models also differ. A GDPR DPIA examines risks to individuals and the necessity and proportionality of processing. DORA assesses ICT risks in the financial entity’s operations. NIS2 concerns network and information-system risks, including effects on services and other persons. AI classifications and assessments follow their own criteria. Shared facts can inform these analyses, but a single numerical score is not a substitute for their legal reasoning.
Use a hypothetical supplier outage to test this distinction. One team may conclude that customer services face severe disruption; another may find no personal-data breach on the evidence currently available. Both conclusions can be coherent. A platform should link them to the same incident facts while retaining their reasons, reviewers and uncertainty. Automatically copying “high” into every legal risk field would obscure the question each team answered.
Test incident handling against separate triggers
A common intake is useful when it records what happened, when it was detected and when each relevant threshold became known. It must not assume that a technical alert starts every regulatory clock. A personal-data breach, a significant NIS2 incident and a major DORA ICT incident have different definitions. The NIS2 and GDPR comparison explains why the same event can produce different reporting decisions.
Under GDPR Article 33, a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours after awareness of a personal-data breach, unless it is unlikely to result in a risk to individuals’ rights and freedoms. Reasons accompany a late notification; information can be supplied in phases without further undue delay. All personal-data breaches must be documented. Article 34 communication to affected people uses the separate high-risk test and its statutory qualifications. A dashboard must not treat “not notified” as “no record required”.
NIS2 Article 23 generally requires an early warning without undue delay and within 24 hours after awareness of a significant incident, followed by an incident notification without undue delay and within 72 hours. An intermediate report may be requested; the final report is due within one month after the incident notification. For trust-service providers, the notification otherwise due within 72 hours is due within 24 hours for significant incidents affecting provision of their trust services. If the incident remains ongoing at the final-report stage, a progress report is followed by a final report within one month after handling the incident.
DORA uses its own classification and reporting framework. Delegated Regulation (EU) 2025/301 links the initial deadline to classification and awareness, then sets deadlines for intermediate and final reports. It also addresses later classification and qualified weekend or public-holiday treatment. A generic “72-hour breach module” does not demonstrate these functions. Have the supplier work through the applicable branches rather than copying a GDPR deadline into the DORA screen.
The cross-regime incident reporting guide can support the exercise. Confirm who approves each submission, which authority receives it, how acknowledgements are stored and what happens if the platform is unavailable. Shared intake should reduce repeated fact gathering while maintaining distinct decisions and reliable fallback arrangements.
Evaluate integration and access in the proposed package
A connector can mean several different things: importing a supplier name, retrieving evidence, synchronising tasks or performing actions in another system. Record the actual direction, frequency and error handling. If an import fails, the platform should reveal stale information; a green status based on an old snapshot can mislead the reviewer. An integration demonstration should include a failed connection and a reconciliation after recovery.
The GRC integration workload analysis helps estimate ongoing maintenance rather than only installation. Include source-system ownership, account changes, permissions and changes to data formats. A common integration can reduce retrieval work while still requiring separate entity reviews. Those reviews should remain visible in the operating budget.
Apply the same scrutiny to access. A privacy reviewer may need the facts supporting an assessment without unrestricted access to security investigation material or employee complaints. Demonstrate entity boundaries, role changes, external reviewers and export permissions. Review the platform provider’s own processing terms, support access, hosting arrangements, retention and incident commitments. Consolidating evidence can increase its sensitivity and the consequences of excessive permissions.
Compare total cost and rollout risk
Company size is a useful input, not a complete buying rule. A small regulated entity may need specialised reporting; a large group may already have effective systems it should retain. Compare three realistic options: improve the existing tools, connect selected specialist tools, or adopt a broader platform. Price each against the same outputs, users, entities, evidence volumes and service commitments.
Include subscription charges, implementation, migration, integrations, administration, training, regulatory-content updates and exit assistance. A quoted module may require a separate licence or professional services. Ask who maintains mappings after a legal amendment and how the customer validates them. There is no reliable universal saving from replacing several subscriptions with one if the new configuration introduces more maintenance or weakens a required output.
Sequence the rollout by the most urgent obligations and operational dependencies. A financial entity with a defective DORA register should not postpone it merely because a vendor recommends starting with GDPR. Choose one representative process, reconcile its imported data and verify the export before expanding. Set acceptance criteria around outputs and decisions, not an unverified promise of becoming audit-ready within a fixed number of weeks.
Make the exit demonstration part of the purchase
Export a completed record with its linked evidence, reviews, timestamps and version history. Then ask someone unfamiliar with the platform to reconstruct the decision. Check whether identifiers still connect the files and whether dates, qualifications and open issues remain understandable. A collection of PDFs may be readable while failing to preserve relationships needed for future maintenance.
Also test a changed and a retired record. The organisation may need the history of why a requirement was considered applicable at a particular time, without continuing to collect unnecessary personal data. Agree the export format, assistance, deletion or return arrangements, and responsibilities at termination. These details are easier to resolve before the organisation depends on the platform for several regulatory processes.
FAQ
Can one platform support all four regimes?
It can, if the required functions are available in the contracted package and demonstrated for the organisation’s scope. Shared facts and evidence are useful. Separate statutory triggers, outputs and accountable judgments must remain visible, and no software purchase establishes compliance by itself.
Does every framework require the same register?
No. GDPR records, DORA contractual information, NIS2 security documentation and AI Act records serve different purposes. An internal inventory can connect them, but should not be presented as a universal statutory register that replaces their specific requirements.
Is consolidation automatically cheaper?
No. Compare implementation, operation, integration and exit costs against your current arrangements. A broader platform is valuable when it solves demonstrated coordination problems while producing the required outputs. Two applicable regimes alone do not establish that business case.