Article 22 Authorised representatives of providers of high-risk AI systems

A non-EU provider cannot put a high-risk AI system on the EU market without an EU-established authorised representative under a written mandate. This page explains what that mandate must cover, how an assessor tests it, and what evidence holds up.

On this page

What an authorised representative under Article 22 must do for a non-EU provider

A non-EU provider of a high-risk AI system must appoint an EU-established authorised representative by written mandate before the system is made available on the EU market. That is the core answer to the page question: no appointment, no lawful availability. The risk this addresses is practical. When a market surveillance authority finds a problem, it needs an accountable contact inside the EU who can produce documents, answer questions and open access to logs, without waiting for a provider in another time zone. Under Article 22(3), authorities may address the representative instead of, or alongside, the provider on any compliance issue, so the representative has to be reachable and genuinely able to act.

The mandate has to give the representative real powers. It must authorise the representative to verify the EU declaration of conformity, the technical documentation and the conformity assessment, to keep contact details and the declaration, documentation and any certificate for 10 years, to provide information and log access on request, to cooperate with authorities and to handle registration. Confirm with counsel that the mandate text covers each of these items, that it names the system or systems it covers and that it is signed and dated. Ask the representative to show how it would retrieve a 10-year-old technical file on short notice. Keep this record in the same controlled repository as the rest of the file, with version history, so the mandate and its amendments can be produced on request.

The role is hard to staff and document in practice because the representative takes on liability it cannot fully control. Under Article 22(4), it must terminate the mandate if it has reason to consider the provider is acting contrary to its obligations, and immediately inform the market surveillance authority and any notified body. Breach carries fines of up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, or whichever is lower for SMEs. Before signing, a representative will expect evidence that the provider's quality management and documentation are current. Plan for that review as part of your readiness work, and ask any candidate representative what documents it will need from you, how often it will review them and how quickly it can escalate.

Which non-EU providers need an authorised representative under Article 22

Article 22 applies only when a non-EU provider makes a high-risk system available on the EU market, but the scope of that trigger depends on how many systems are involved, which Annex route they follow and where the technical file sits. The cards below set out the decisions that change the work and the points to confirm with counsel before a mandate is signed.

The placing on the market trigger

Article 22(1) requires a provider established outside the EU to appoint an authorised representative before it makes a high-risk system available on the EU market. The obligation attaches to the act of making the system available, so a provider that has not yet offered the system to EU customers should record the date of its first EU offer. Confirm with counsel how pilots, free trials and demonstrations to EU prospects are treated under the definitions in the Act.

Article 2 reach to non-EU outputs

Article 2 extends the Act to non-EU providers and deployers whose AI output is used in the EU, even where the system is not placed on the market in the usual sense. A provider whose system runs outside the EU but whose results are used by EU customers should assess whether it falls within Article 2 and, if it does, whether its high-risk systems trigger the Article 22 mandate. Map which customers receive outputs and where those outputs are used.

Annex III versus Annex I routes

The route a system follows changes the timing and the conformity path that the representative must verify. Annex III systems are subject to the rules from 2 December 2027 under the 2026 amendment, while Annex I product systems follow 2 August 2028. Most Annex III systems use internal control under Annex VI, and some Annex I products involve a notified body, so the mandate must cover whichever assessment records apply to each system.

Number of systems in scope

Each high-risk system needs its own declaration, technical documentation and conformity records, and the representative must be able to verify all of them on request. A provider with several systems should build a register that lists each system, its Annex category, its conformity route and its EU customers before drafting the mandate. The register also shows whether the mandate covers the whole portfolio or only named systems.

Who holds the technical file

The representative must be able to verify the technical documentation and the declaration, which only works if it can reach them. Decide whether the file sits with the non-EU provider, with a group entity or with a hosting partner, and grant the representative access under agreed terms. If the file is held in a jurisdiction where access is slow or restricted, the mandate and the provider's internal procedures should set response expectations.

Authorised representative and importer roles

The authorised representative is appointed by the provider and acts for it, while the EU importer under Article 23 checks the system before it is placed on the market and holds records in its own right. The same organization can sometimes hold both roles, but the duties and liability differ. Confirm the role split with counsel before signing, and record which entity answers authority requests for each system.

What the written mandate must empower the representative to do

Article 22(3) requires the written mandate to empower the authorised representative to carry out five tasks, and each one should appear in the mandate as an operational duty rather than a general statement of cooperation. The first is to verify the EU declaration of conformity, the technical documentation and the conformity assessment, which means the representative must be given access to the documents and the authority to ask the provider for what it cannot review. The second is to keep the representative's contact details, the declaration, the technical documentation and any certificate available for 10 years. The third is to provide information and log access to authorities on request, so the mandate should name where the logs sit and how fast they can be produced. The fourth is to cooperate with competent authorities, and the fifth is to handle registration.

Authorities may address the representative instead of, or alongside, the provider on any compliance issue. A mandate that only names a contact point will not survive that scenario. The representative needs the documents, the log extracts and a named technical contact at the provider before a request arrives, so the reader should test the mandate with a tabletop exercise: pick a hypothetical information request (illustrative) and time how long it takes the representative to answer from the materials it actually holds. Confirm with the provider how the representative receives updates to the technical file and the risk management records.

Before signing, take the wording to counsel and check four points: whether each of the five empowerments is stated in terms the representative can act on, whether the 10-year retention period is tied to the provider's own record keeping (including if the provider ceases trading), whether the provider commits to supplying documents within a set period, and whether the mandate allows the representative to terminate under Article 22(4) without a dispute with the provider. Check the consolidated text of the Act on EUR-Lex when drafting, since the 2026 amendments changed surrounding provisions.

How an assessor tests the authorised representative mandate and records

This table sets out how an assessor typically tests each part of the Article 22 duties, what evidence they ask for, and where representatives most often fall short. Read each row as a question the assessor will ask and the document or log that should answer it. The main takeaway is that a signed mandate alone does not pass; the representative must be able to show working access to the records it is responsible for.

Area testedHow the assessor tests itEvidence requestedCommon findings
Written mandateChecks that a written mandate exists, is signed by the provider, and names the EU representative before the high-risk system is placed on the EU marketSigned mandate, date of appointment, proof the representative is established in the EUMandate is unsigned, undated, or signed after the system was already offered in the EU
Scope of the mandateCompares the mandate's wording with each Article 22(3) task: verifying the declaration, technical documentation and conformity assessment, registration, and cooperationMandate text with a task-by-task mapping to the representative's proceduresMandate covers registration but not verification of the declaration or the technical documentation
Access to the technical fileAsks the representative to produce the declaration, technical documentation and any certificate on request, without waiting for the provider to forward themIndex of the stored documents, access rights, and a sample retrieval test with a timestampDocuments are held only by the provider, so the representative cannot produce them when an authority asks
Contact and retention registerChecks that contact details of the provider and the representative are kept, and that the declaration, documentation and certificates are retained for 10 yearsRetention schedule, storage location, deletion controls and the date each record was filedRetention period set to a shorter term, or the clock is tied to system withdrawal instead of the 10-year period
Log access on requestTests whether the representative can provide information and access to logs when an authority asksLog access procedure, named contact, and a dated record of a dry-run requestLogs sit in the provider's systems with no agreed route for the representative to obtain them
Authority request handlingWalks through a sample request from a market surveillance authority, including who receives it, who answers, and how fast the answer is sentRequest log, response templates, escalation path to the provider, and sign-off recordsRequests reach the representative but no one is authorised to answer, or responses depend on an email inbox nobody monitors
Termination under Article 22(4)Tests whether the representative has a documented trigger for ending the mandate and a process to notify the authority and any notified body immediatelyTermination criteria, decision record, and notification templates to the authority and notified bodyNo defined trigger, no named decision-maker, or notification steps that depend on the provider agreeing
Competent authority contactChecks that the representative can be addressed by authorities on all compliance issues, alongside or instead of the providerContact details published to authorities, and proof that these details are currentContact details are outdated or point to a generic mailbox without a responsible person

How to appoint and run an authorised representative step by step

This sequence takes a non-EU provider from confirming that Article 22 applies to a fully documented, EU-based representative who can answer for the system when authorities ask. Each step ends with a named record that you can show an assessor.

  1. Confirm the trigger and scope

    Start by confirming that the system is a high-risk AI system under the Act and that your organization is a provider established outside the EU that will make it available on the EU market. Legal or compliance owners should record the classification rationale, the Annex reference and the intended EU markets in a short scoping memo. The step is complete when the memo is approved and names every system that needs a representative. Confirm the current application dates for Annex III and Annex I systems in the Act as amended in 2026, since they drive when the appointment must be in place.

  2. Select an EU-established representative

    Shortlist candidates established in the EU that can accept the tasks listed in Article 22(3), including verifying the declaration and technical documentation, keeping records and cooperating with authorities. Ask each candidate how it will handle record retention for 10 years, how it will receive authority requests, and what it does if it must end the mandate. The output is a selection file with the candidate's contact details, its capacity assessment and the decision record. Confirm the candidate's own legal and professional status with the candidate directly, because the Act does not supply a registry for this role.

  3. Draft and sign the written mandate

    Draft a written mandate that gives the representative the powers Article 22(3) requires: verification of the declaration, technical documentation and conformity assessment, retention of contact details, declaration, documentation and any certificate for 10 years, provision of information and log access on request, cooperation with authorities and handling of registration. Have counsel review it, then sign it on both sides and store the executed copy with a version number. The output is a signed mandate that names the systems covered and the effective date. Confirm with the representative that its acceptance is recorded in writing.

  4. Give the representative access to core documents

    Define an access matrix that lists each document the representative must be able to verify, such as the EU declaration of conformity, the technical documentation, the conformity assessment record and any certificate, along with the owner, storage location and access method for each. Provision read access through a controlled repository and confirm the representative can open and review each item. Your team should log the access grants and confirm them in a dated handover note. The step is complete when the representative confirms in writing that it can reach every item in the matrix.

  5. Set up the contact and retention register

    Build a register that holds the representative's contact details, the mandate reference, the system identifiers, and the location and retention end date of every record the representative must keep. Assign an owner for each entry and schedule a periodic check that contacts are still reachable and records are intact. Version control and role-based permissions in a self-hosted wiki or document system can keep this register auditable, provided the permissions are reviewed. The output is the register itself plus a retention calendar that shows when each 10-year period starts and ends.

  6. Define the authority request and log access process

    Write a runbook that explains how an authority request reaches the representative, how it is routed to the provider's technical and legal owners, who approves the response, and how the answer is returned. Cover requests addressed to the representative instead of the provider, requests for log access and cooperation on compliance issues. Set internal response roles and test the path with a tabletop exercise using an illustrative request. The output is a tested runbook and a log of the exercise, showing who acted and what gaps were fixed.

  7. Set the termination and notification procedure

    Agree with the representative the conditions under which it must terminate the mandate under Article 22(4), including where it has reason to consider the provider is acting contrary to its obligations. Document how the representative informs the market surveillance authority and any relevant notified body, and how the provider is told first, where the mandate allows. Prepare a replacement plan so that the system is not left without a representative. The output is a termination clause in the mandate, a notification template and a replacement contingency record reviewed by counsel.

Evidence that proves the representative arrangement is working

An authorised representative arrangement is only as credible as the records behind it. The cards below cover the artifacts a market surveillance authority is likely to request, how each one is kept current between audits, and which tools can hold them. Each item should be reviewed on a fixed schedule so that the file reflects the arrangement as it actually operates.

Signed written mandate

The mandate is the legal basis for the representative's role. It must be in writing, signed by the provider, and must empower the representative to verify the declaration, technical documentation and conformity assessment, keep records, provide information on request, cooperate with authorities and handle registration. Check that the signed version on file matches the version in force, that the scope still covers every high-risk system placed on the EU market, and that any amendment is dated and signed. Confirm the wording with counsel, since the Article sets the minimum content.

Contact register

The representative must keep the contact details of the provider it represents, and the provider must be able to give authorities a current route to both parties. Maintain a register listing each provider, each high-risk system covered, named contacts with roles, and the authority or notified body contact points. Review it whenever a contact leaves or a system is withdrawn, and record the date of each review so an assessor can see how current it is.

Ten-year retention archive index

The declaration, technical documentation and any certificate must be kept for 10 years, and the representative must hold the contact details for the same period. An index lists each retained document, its version, its date of issue, its storage location and its retention end date. Test retrieval periodically by pulling a sample document from the archive, since an index that points to unreadable files does not satisfy a request. Confirm with the provider how it will hand over the archive if the mandate ends.

Access and log request records

When an authority asks for information or access to logs, the representative must respond, so each request needs a record: who asked, the legal basis stated, what was requested, what was supplied, when, and who approved the release. The same log should show requests the representative had to pass to the provider and the response times involved. Review the log at each audit cycle to confirm that requests were answered and that no request sat unanswered without an explanation.

Authority correspondence log

Competent authorities may address the representative instead of, or alongside, the provider on any compliance issue. A correspondence log records every inbound letter, email or notice, the reply sent, the person who handled it and the follow-up owner. Keep the originals with the log entry. The log lets an assessor see that cooperation happened in practice, not only on paper, and it shows whether the representative handled matters promptly and consistently.

Termination decision record

Under Article 22(4), the representative must end the mandate if it has reason to consider the provider is acting contrary to its obligations, and it must immediately inform the market surveillance authority and any notified body. The decision record documents each concern raised, the evidence reviewed, the decision reached, the date of notification and the copies sent. Even a decision to continue should be recorded with reasons. Consider the decision record a control, and test it through a tabletop exercise before an incident occurs.

When the representative must terminate the mandate and what follows

Article 22(4) obliges the authorised representative to terminate its mandate as soon as it has reason to consider that the provider is acting contrary to its obligations under the Act. The representative must also immediately inform the market surveillance authority and any notified body involved. The trigger is the representative's own reasonable judgment, not proof of a breach, so the duty can arise before the provider has been formally found non-compliant. In practice a reason can be a conformity assessment gap the representative cannot verify, technical documentation that is missing or contradicts the system as deployed, a declaration of conformity that is not current, a provider that stops answering information or log requests, or a serious incident the provider has not reported. Each of these should be logged as a finding with the date it was raised, the evidence reviewed and the decision taken.

The representative's internal assessment is only defensible if it is written down. Keep a dated record for every review: which documents were checked against the mandate tasks in Article 22(3), what was missing, what the provider was asked to supply, the deadline given, and whether the answer was adequate. Store these records with the declaration, documentation and certificate the representative already holds for 10 years. The provider's corrective action plan should pick up each finding as a tracked item with an owner and a closure date, so that the provider can show authorities it responded before the representative had to walk away. A provider that treats representative findings as routine tickets rather than compliance signals is likely to reach termination with no record of having acted.

The escalation path belongs in the written mandate, agreed before any dispute. Ask the representative to confirm in the mandate who on each side receives findings, how many days the provider has to respond, what counts as an unresolved finding, who approves termination, and who sends the notices to the market surveillance authority and notified body. Confirm with your counsel and the representative how these terms interact with the mandate's termination and notice provisions, since the Act sets the duty but not the commercial mechanics. Also agree how the provider will be told that termination is under consideration, because the representative cannot wait for a negotiated outcome if it has reason to act. A mandate that leaves these points open will leave the provider with no product on the EU market and no representative to answer for it.

What an authorised representative arrangement costs to run

This table breaks the running cost of an Article 22 mandate into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to compare written quotes on like terms, since DeployOpen does not publish a price list and no fee or duration for these components is set by the Act.

Cost componentWho is paid and for whatOne-time or recurringWhat drives it up or downWhat to ask for in a quote
Representative service feeThe EU-based authorised representative, for holding the mandate and carrying the Article 22(3) tasksRecurringNumber of high-risk systems covered, number of Member States where the systems are placed, and how often authorities contact the representativeFee basis (per system, per year or retainer), what is included, and the fee for handling authority requests outside normal scope
Legal review of the written mandateExternal counsel, to check the mandate covers verification, documentation, log access, cooperation and registrationOne-time, with review when the mandate changesLength and number of existing contracts, and whether the mandate must be translated or aligned with other agreementsNamed lawyer or firm, scope of review, and whether a revised mandate review is included
Internal staff time for document accessYour own staff, who make the declaration, technical documentation and conformity assessment records available to the representativeRecurring, with a peak at first setupDocument volume, how many systems share one file set, and whether records are stored in one controlled locationYour internal estimate of hours per system, agreed with the representative before work starts
Internal staff time for authority requestsYour own staff, who answer information and log access requests passed through the representativeRecurringFrequency of requests, speed of response the representative expects, and how well logs are indexedResponse times the representative needs from you, and the escalation route for urgent requests
Archive storage for 10-year retentionYour own storage team or a cloud or data center provider, for keeping contact details, the declaration, documentation and any certificate for 10 yearsRecurring storage, with one-time migration workVolume of technical documentation and logs, format of records, backup and integrity controls, and where the data must be hostedStorage location, retrieval time, backup and restore approach, and what happens to records if the provider ceases trading
Periodic reviews of the arrangementThe representative and your compliance lead, checking the mandate, contact details and whether the provider still meets its obligationsRecurring, at a set interval you agreeNumber of changes to systems, new Member States, and changes in regulator guidanceReview frequency, who attends, and whether a change to a system triggers an extra review
Termination and handoverYour legal team and the representative, if the representative must end the mandate under Article 22(4)One-time, if it occursSpeed at which a replacement representative can be appointed and how quickly records transferNotice period, handover obligations and who pays for transferring records

Who does what: the provider, the representative, an implementation partner and the auditor

The non-EU provider remains responsible for its high-risk AI system. It decides whether to place the system on the EU market, signs the written mandate that appoints the authorised representative, and owns the technical documentation, the EU declaration of conformity and the conformity assessment route that applies. Under Article 22, the provider must make the arrangement real: the representative needs documents and access it can actually use, and the provider must keep them current.

  • Mandate ownership: The provider signs a written mandate before the system is made available in the EU, and it must be able to produce that mandate on request.
  • Technical file: The provider holds the technical documentation, the declaration and any certificate, and it keeps them available to the representative.
  • Market decision: The provider decides whether a version may be placed on the market, and it stays accountable for that decision even when a representative handles registration.
  • Information flow: The provider gives the representative the information, log access and contact details needed to answer authorities.

Before signing, confirm with counsel which provider obligations sit outside the mandate and which the representative may act on alone.

Where non-EU providers usually fall short on the representative duty

Most gaps in the authorised representative duty come from treating the appointment as a signature on a letter rather than a working role. The cards below cover the mandate, access to evidence, retention, log requests and the walk-away path, each with a closure step you can check before the system reaches the EU market.

Mandate missing an empowerment

Article 22(3) requires the written mandate to cover five empowerments: verifying the declaration, technical documentation and conformity assessment, keeping records, providing information and log access, cooperating with authorities, and handling registration. A mandate that names only some of these leaves the representative unable to act on the missing item when a regulator asks. Check the mandate line by line against all five, and have counsel confirm the wording matches the Article.

No access to the current technical file

A representative cannot verify documentation it has never seen, and an outdated copy is almost as weak as none. The fix is a standing access arrangement: a named document repository the representative can read, with each release of the technical file and conformity assessment record shared on the same day it is approved internally. Confirm in writing which version the representative holds and who is responsible for sending updates.

Retention that ends with the contract

Article 22 requires the representative to keep contact details, the declaration, documentation and any certificate for 10 years. Many agreements tie retention to the length of the engagement, which ends long before that period. Write the retention period into the mandate as 10 years from the relevant dates, state what happens to records if the representative ceases trading, and agree a handover process for records before any termination.

Log requests with no response route

Authorities can ask the representative for information and log access at short notice, and the provider has to supply what the representative cannot produce alone. Without a documented procedure, requests stall between the two parties. Define an intake contact, a internal owner for each log source, a target internal turnaround that you set yourself, and a written record of every request and what was sent.

No walk-away path defined

Under Article 22(4), the representative must end the mandate if it has reason to consider the provider is acting contrary to its obligations, and must immediately inform the market surveillance authority and any notified body. A representative that discovers a problem without a path to act on it may hesitate or leave late. Agree in advance the triggers the representative will watch for, the information it will receive, and the notice sequence, so termination is a planned step rather than an emergency.

Questions buyers ask about the Article 22 representative

How much does an EU authorised representative cost?

No fixed price applies, because the cost depends on the scope of the mandate, the number of high-risk systems and the volume of documentation the representative must verify and hold. The representative is a paid role, and the fee is usually recurring because the mandate runs for as long as the system is on the EU market and the records must be kept for 10 years. Ask each candidate to quote separately for the appointment and onboarding, the annual or per-system service, documentation requests, authority cooperation and any registration work. Also ask who pays for the time spent answering authorities during an investigation, since that work can be unplanned. DeployOpen does not publish a price list. A quote follows from a written scope, and DeployOpen is not an authorised representative itself.

How long does it take to appoint an authorised representative?

The appointment must be in place before the high-risk system is made available on the EU market, so the timeline is set by your launch date. The duration depends on how quickly you can agree a written mandate, confirm the representative's EU establishment, and exchange the contact details and documentation the representative needs to verify. Start negotiating early, because the mandate has to cover specific powers under Article 22(3), including verification of the declaration, technical documentation and conformity assessment. Ask candidates for their onboarding steps and expected lead time in writing before you sign anything. No duration is set out here, so confirm the timeline with each candidate and against your own release plan.

What does the provider's team need to supply to the representative?

The representative can only verify what it receives, so your team must prepare a complete, current evidence pack before the mandate starts. That pack typically includes the technical documentation, the EU declaration of conformity, any certificate issued by a notified body, the contact details of the responsible person, and access routes for the logs the authorities may request. Your team also needs to name a contact who can answer questions quickly, and to agree how updates to the system are shared. Keep these records in a controlled repository with version history so the representative sees the correct version. Confirm the exact list with your candidate, because each mandate sets its own working procedures.

Can our company act as its own authorised representative?

Only if your company is established in the EU. Article 22 requires the representative to be established in the EU, so a non-EU provider cannot fill the role itself from outside the Union. An EU-established subsidiary or affiliate may be able to take the role if it can meet every mandated task, including terminating the mandate and informing authorities under Article 22(4). Check the legal basis for your structure with counsel before relying on an affiliate. Note that an external party can also be appointed, and the mandate does not transfer your own legal duties. DeployOpen can prepare the systems, evidence and records a representative will use, but DeployOpen is not an authorised representative and does not issue declarations or certificates.

Is the authorised representative the same as an importer?

No. An authorised representative is appointed by a non-EU provider under Article 22 and holds a written mandate covering verification, record keeping, cooperation with authorities and registration. An importer is a separate role under Article 23, which covers checks an EU importer makes before placing a non-EU provider's high-risk system on the market. The two roles can be held by the same organization in some cases, but they carry different duties, and holding one does not satisfy the other. Confirm with counsel which roles apply to your supply chain, and write each duty into the relevant agreement so neither party assumes the other covers it.

What does the 10-year retention requirement mean in practice?

The representative must keep its contact details, the EU declaration of conformity, the technical documentation and any certificate for 10 years, as set out in Article 22(3). In practice, this means the records must remain retrievable and readable for the full period, even after the system is withdrawn or the provider stops trading. Plan storage, access control and format migration now, not at the end of the system's life. Use version control so you can show which documentation applied at each point in time, and assign ownership of the archive in the mandate. Your team should also confirm what happens to the records if the representative's appointment ends early under Article 22(4).

What fines apply if the provider or representative breaches Article 22?

Breach of the Article 22 obligations is subject to fines of up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, under Article 99(4). For SMEs, including start-ups, the rule reverses: the fine is up to the lower of the two amounts, as set by Article 99(6). Because the representative is answerable to authorities, it may also be contacted directly, so the mandate should record who responds to requests and within what internal timeline. Confirm your enterprise classification and the current figures with counsel before setting risk appetite, because the Act has been amended and the penalty chapters apply on their own dates.

When must an authorised representative end its mandate?

Under Article 22(4), the representative must terminate the mandate if it has reason to consider the provider is acting contrary to its obligations under the Act. It must then immediately inform the market surveillance authority and any relevant notified body. Because the representative is legally bound to act on this, build a process that flags concerns early, including a clear route for raising issues about documentation gaps, unfixed non-conformities or missed corrective actions. Agree in writing how the representative receives this information and how quickly it can escalate. Ask candidates how they handle termination, since a sudden loss of representation can halt your EU market access.

How DeployOpen works on this

DeployOpen prepares the systems, documentation and records that an EU authorised representative needs to verify, retain and produce for a non-EU provider's high-risk AI system. We plan and build that evidence inside your own infrastructure, and an independent authority, not DeployOpen, decides whether the provider complies.

How we scope

  • Written scope lists the high-risk systems, provider entities and EU market channels covered by the mandate.
  • Scope maps each Article 22(3) task to a named system, owner and evidence source in your environment.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

  • We deploy a version-controlled repository for the declaration, technical documentation and conformity records.
  • Role-based access limits who can edit mandate records, contact details and retained documents.
  • We configure retention so the 10-year period under Article 22(3) is enforced and documented, not assumed.

How we hand over

  • Handover includes an evidence index linking each mandate task to its document, log source and owner.
  • Runbooks describe how to answer authority requests and provide information or log access on demand.
  • Documentation covers the termination trigger in Article 22(4) and the notification steps that follow it.

How we support

  • Ongoing support and upgrades of the platforms can be arranged as a retainer after handover.
  • Periodic reviews confirm that retained records remain complete, readable and attributable over time.
  • Confirm with your legal counsel and the independent assessor which parts of the arrangement they will review.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.