What the EU AI Act compliance checklist requires and when
The EU AI Act compliance checklist is an ordered set of steps: inventory and classify each AI system, rule out prohibited practices, meet the AI literacy duty, check transparency duties, and then complete the duties for your role. The dates depend on the step. Prohibitions and AI literacy have applied since 2 February 2025, the general-purpose AI model rules since 2 August 2025, and most remaining duties from 2 August 2026, while the high-risk rules for Annex III systems now apply from 2 December 2027 and for Annex I product systems from 2 August 2028 under the 2026 amendment. A customer or regulator asking about compliance should therefore be asked which step they mean and which date applies to it. The organization owns its controls and decides its classification. An implementation partner can prepare systems, records and evidence for each step, but only an independent auditor, assessor or certification body issues reports or certificates. Be clear on this split when you scope outside help, because a partner cannot sign off that a system is compliant. Confirm with counsel or your market surveillance authority which role you hold for each system, since the answer changes the checklist. Ask any provider you buy from for its written role position, its classification and the date it plans to be ready.
The answer differs by role and by whether any system is high-risk. A deployer that only uses a limited-risk chatbot has a short list: AI literacy, transparency and records of the inventory. A provider that places a high-risk system on the EU market carries the full set of provider duties, including the quality management system, technical documentation and conformity assessment. Organizations that build on a general-purpose model have their own question to answer, because the model provider's duties do not transfer to them automatically. Before you assume any step is out of reach, confirm your classification against Article 6 and the current draft Commission guidelines, since a system can move between risk tiers as its intended purpose changes.
Which AI Act dates drive the plan, step by step
The AI Act applies in phases, so each obligation has its own start date. The cards below follow those phases in order, from the prohibitions that already apply to the high-risk rules that the 2026 Digital Omnibus has now postponed. Read them as the sequence a compliance plan has to follow.
Prohibitions and AI literacy now apply
Chapters I and II have applied since 2 February 2025. They cover the definitions, the AI literacy duty and the prohibited practices. Article 4 is already in force and reaches providers and deployers of every AI system, not only high-risk ones, so an inventory and a literacy record should exist before any other step. Check each system in use against the prohibited list now, because the nine prohibitions carry the highest fines in the Act and no transition period applies to them.
Governance and general-purpose AI rules
The general-purpose AI, governance, notified body and penalty chapters have applied since 2 August 2025, except Article 101. If your organization builds or distributes a general-purpose AI model, these duties were already live. Confirm which of your teams owns the national authority contact and the AI Office relationship, and record who answers for each obligation, since enforcement can begin before your high-risk systems are covered.
Digital Omnibus moves high-risk dates
Regulation (EU) 2026/1744 amended the Act and moved the high-risk rules in Chapter III Sections 1 to 3. Annex III systems now face them from 2 December 2027, instead of 2 August 2026. Annex I product systems now face them from 2 August 2028, instead of 2 August 2027. Use these dates as the planning target for high-risk work, but treat the postponement as a change to the schedule rather than a reason to stop preparing.
Rest of the Act from August 2026
Obligations outside the postponed high-risk rules, including the Article 50 transparency duties for chatbots, synthetic content and deepfakes, were scheduled to apply from 2 August 2026. Check which of these duties your public-facing systems trigger and whether the Commission's 2026 transparency guidelines change the steps you need. Record the decision for each system so an assessor can see when the obligation attached.
Confirm dates in the amended text
Before fixing any deadline in a plan, read the consolidated text as amended by Regulation (EU) 2026/1744 on EUR-Lex. The amendment was published on 24 July 2026 and entered into force on 27 July 2026. Confirm each article's application date against that text rather than against earlier summaries, and log the version you relied on. Your legal or compliance counsel should sign off on the final dates for your organization.
The checklist in order, with the output of each step
The sequence starts with knowing what AI you run and how each system is classified, then rules out prohibited uses, then works through the duties that apply to each role. Each step closes with a record you can show an assessor or regulator.
Build the AI system inventory and classify each system
Start by listing every AI system your organization builds, buys, embeds or uses, including tools staff adopt without procurement. For each entry, record your role (provider, deployer, importer, distributor or other operator), the intended purpose, the business owner and the risk tier. Check each high-risk candidate against the Annex III categories and the Article 6 classification rules, and note the Article 6(3) reasoning for any system you conclude is not high-risk. The output is a dated inventory with a classification decision and rationale for every entry. Confirm the current draft Commission guidelines on classification with your counsel before you rely on any borderline call.
Rule out prohibited practices
Take each inventoried system and test it against the prohibited practices in Article 5. These cover uses such as manipulative techniques, exploitation of vulnerabilities, certain social scoring and some biometric uses. Because the Commission counts nine prohibited practices after the 2026 amendment, check the current list in the consolidated text rather than an older summary. Record for each system whether it falls outside every prohibition, and if a use is close to one, document the analysis and stop the use until counsel signs off. Prohibitions have applied since 2 February 2025, so this check is already overdue for any system in production. The output is a signed prohibited-practice screen for each system.
Confirm AI literacy measures under Article 4
Article 4 has applied since 2 February 2025 to providers and deployers of all AI systems, not only high-risk ones. Identify the staff and contractors who build, operate or oversee each system, and set training that fits their role and the context in which the systems are used. Document who was trained, on what, and when, and keep the material current as systems change. The Commission's AI literacy questions and answers explain how it reads the duty. Literacy is an organizational duty, so the owner of the program should be named in your AI governance policy. The output is a training register and course materials tied to the inventory.
Map transparency duties under Article 50
For each system, decide whether Article 50 applies. Providers of systems that interact directly with people must design them so users know they are dealing with an AI system, unless that is obvious in context. Other Article 50 duties cover synthetic content, deepfakes, emotion recognition and biometric categorization, and they fall on providers and deployers in different ways. Check the 2026 transparency guidelines and the Code of Practice on marking and labelling AI-generated content, and map each duty to the interface, output or notice that meets it. The output is a transparency register listing each duty, the system it applies to, the implemented measure and the test that proves it works.
Run provider steps for high-risk systems
If you provide a high-risk system, work through the Article 16 obligations in order. Establish a quality management system, maintain technical documentation and logs, complete the conformity assessment, and prepare the EU declaration of conformity. Affix the CE marking, register the system, put a corrective action process in place and keep the means to demonstrate conformity on request. Most Annex III systems use internal control under Annex VI, while some biometric systems and Annex I products involve a notified body. Note that Annex III high-risk rules now apply from 2 December 2027. The output is a conformity file containing the QMS records, technical documentation, log policy, declaration and registration evidence.
Run deployer steps for high-risk systems
If you deploy a high-risk system, use it according to the provider's instructions for use, using technical and organizational measures. Assign human oversight to people with the necessary competence, training, authority and support. Where Article 27 applies, which covers certain public bodies, public service providers and deployers of credit scoring and life and health insurance pricing systems, complete a fundamental rights impact assessment before first use. Keep the logs the Act requires you to retain and inform affected workers where the rules require it. The output is a deployer file with the instructions in use, the oversight assignments, the impact assessment and the monitoring records.
Check general-purpose model duties
If you provide a general-purpose AI model, check the Article 53 duties. Maintain Annex XI technical documentation for the AI Office, give Annex XII information to downstream providers, and adopt an EU copyright policy that respects text and data mining opt-outs. Publish a training content summary using the AI Office template. The Code of Practice is one route to showing compliance, and the AI Office supervises these rules. If you only build on or fine-tune a model, check whether you have become a provider. The output is a model file with the Annex XI documentation, the copyright policy, the published training summary and any Code of Practice commitments.
Which checklist steps apply to providers, deployers and model providers
A provider develops an AI system, or has it developed, and places it on the EU market or puts it into service under its own name or trademark. For a high-risk system, Article 16 sets out the provider's core duties, including compliance with the Section 2 requirements, a quality management system, technical documentation, log keeping, conformity assessment, the EU declaration of conformity, CE marking, registration, corrective action and accessibility. Most Annex III systems use internal-control conformity assessment, while some biometric systems and Annex I products involve a notified body under Article 43.
- Name and contact on the system: Article 16 requires the provider's name, registered trade name or trademark, and contact address on the system, its packaging or its documentation.
- Quality management system: Keep written policies, procedures and records that cover the full system lifecycle.
- Technical documentation and logs: Maintain the documentation needed to show conformity, and keep logs that the system generates automatically.
- Declaration, marking and registration: Prepare the EU declaration of conformity, affix CE marking and register the system.
- Article 6(4) documentation: A provider that relies on the Article 6(3) exemption must document its assessment before placing the system on the market or putting it into service, provide it on request, and register the system under Article 49(2).
Confirm your classification against Article 6 and the current draft guidance before relying on any exemption, and confirm the fixed dates in Article 113 that apply to your system.
A deployer uses an AI system under its own authority in the EU, even if someone else built it. Deployers of high-risk systems must follow the provider's instructions for use, assign human oversight to people with the necessary competence, training, authority and support, and keep the logs the system generates. Article 26(1) and (2) set these duties, and Article 27(1) adds a fundamental rights impact assessment before first use of certain Annex III systems.
- Use per instructions: Apply technical and organizational measures so the system runs as the provider's instructions for use describe.
- Human oversight: Name the people responsible, confirm their competence and training, and give them the authority to intervene.
- Fundamental rights impact assessment: Article 27(1) applies before first use by bodies governed by public law, private entities providing public services, and deployers of credit scoring and life and health insurance pricing systems (Annex III points 5(b) and (c)).
- Input data and monitoring: Where you control input data, confirm it is relevant to the intended purpose, and monitor operation for risks.
- Records: Keep the logs, impact assessments and any worker notices that your deployment requires.
Confirm whether your use falls under Article 27(1) and which Annex III point applies to it.
A provider of a general-purpose AI model is the organization that develops such a model and places it on the EU market. These duties sit in Chapter V and are supervised by the AI Office rather than national authorities. Article 53(1) requires every such provider to keep Annex XI technical documentation available for the AI Office, give Annex XII information to downstream providers, adopt an EU copyright policy that respects text and data mining opt-outs, and publish a training content summary on the AI Office template.
- Technical documentation: Maintain Annex XI documentation for the AI Office and update it as the model changes.
- Downstream information: Provide Annex XII information to providers who integrate the model into their systems.
- Copyright policy: Adopt a policy that respects text and data mining opt-outs.
- Training content summary: Publish a summary using the AI Office template.
- Code of practice: Consider the General-Purpose AI Code of Practice as a way to show compliance, and confirm its current status with the Commission.
If you build an AI system on your own general-purpose model, check whether you are also a system provider with separate duties.
Organizations that only use minimal-risk systems have no high-risk duties under the AI Act, but they still face baseline obligations. Article 4 has applied since 2 February 2025 to providers and deployers of all AI systems and requires them to take measures to ensure a sufficient level of AI literacy among their staff. If a system interacts directly with people, Article 50(1) requires the provider to design it so that people are told they are interacting with an AI system, unless this is obvious in context.
- AI literacy: Document the training and awareness activities for staff who use or oversee AI systems.
- Chatbot interaction notice: Confirm that any customer-facing chatbot informs users it is AI, or that the provider does so.
- Transparency duties: Check Article 50 for synthetic content, deepfakes and emotion recognition, which may apply even when the system is not high-risk.
- Inventory evidence: Record why each system is classified as minimal risk so the decision can be shown later.
- Role changes: Watch for uses that move a system into high-risk territory, such as a new purpose or a new Annex III context.
Confirm the transparency guidance dated 20 July 2026 for how Article 50 applies to your specific system.
Why the not-high-risk decision needs its own record
A system you classify as not high-risk still needs a written, dated classification decision. Silence is not a position. If a market surveillance authority, an assessor or a customer asks why a system sits outside Chapter III, the answer has to be on paper, tied to the system as it existed when the decision was made. Without that record, you cannot show that the classification was a considered judgment rather than an afterthought.
The record should show the system's intended purpose as documented in its instructions and marketing, the Article 6 reasoning that places it outside the Annex I and Annex III routes, and whether you relied on the Article 6(3) exemption. If you did rely on it, Article 6(4) requires you to document that assessment before the system is placed on the market or put into service, provide it on request, and register the system under Article 49(2). Record who approved the decision, the role they hold, the date, the version of the system it covers, and the trigger that forces a review, such as a new use case, a new user group or a material model change. Keep the record in the same repository as the AI inventory entry so the two cannot drift apart.
Check the reasoning against the Commission's draft guidelines on the classification of high-risk AI systems, published 19 May 2026, and note which parts of your analysis they affect. Because those guidelines are a draft, confirm their final status before you rely on them. For borderline cases, such as a system that supports rather than replaces a decision in an Annex III area, get written advice from counsel and record that advice alongside the decision. A reviewer will look for the reasoning, the evidence behind it and the sign-off, so plan the record to answer those three questions on one page.
What must be in place before you can tick each checklist item
Each checklist step depends on something that already exists: a register of systems, a recorded classification, training records, disclosure wording, design evidence for oversight and logging, and a named owner for the quality management system. The cards below set out how to check each item and who in the organization should confirm it.
Current inventory with a named owner
Every AI system in use, built, bought or embedded in a supplier product should appear in one register, with a single accountable owner for each entry. Check the register against procurement records, software licenses and engineering repositories, not only against what teams report. Ask the owner to sign the entry for their system each review cycle. The business unit lead and the compliance lead should confirm that no system is missing, because a system absent from the inventory cannot be classified or tested.
Classification record for each system
For each inventoried system, keep a written record that states its intended purpose, whether it is a prohibited practice, whether it falls under Annex III or Annex I, whether an Article 6(3) exemption is claimed, and the reasoning behind the outcome. The record should be dated and re-opened when the purpose changes. Legal or compliance should review the reasoning, and the system owner should confirm the stated purpose matches how the system is actually used.
AI literacy measures for staff
Article 4 has applied since 2 February 2025 to providers and deployers of all AI systems, so staff who operate AI need documented literacy measures now. Keep training materials, attendance or completion records, and role-specific notes showing that the training reflects the context in which each person uses AI. HR or the learning team should hold the records, and the managers of staff who operate AI should confirm that the people they supervise have completed the relevant measures.
Article 50 disclosure text and placement
Where a system interacts directly with people, the people must be told they are dealing with an AI system unless this is obvious to a reasonably well-informed, observant and circumspect person. Record the exact disclosure wording, the screens, pages, emails or audio prompts where it appears, and the reason any case is treated as obvious. Product or legal should approve the wording, and the team that ships the interface should confirm in a test run that the disclosure appears at the first point of interaction.
Logging and oversight design for high-risk systems
For a high-risk system, keep a design record showing which events are logged, how long logs are retained, who can read them, and how a human can stop, override or reverse the system's output. Deployers must assign oversight to people with the necessary competence, training, authority and support. Test the design by simulating a faulty output and checking that the log captures it and that the named reviewer can intervene. The technical lead and the risk owner should both sign the test result.
Named accountable owner for the QMS
Providers of high-risk systems must operate a quality management system, and the AI governance policy should name one person accountable for it across all systems. Check that the appointment is written, that the owner has authority over the release and change process, and that they hold the QMS records such as procedures, change approvals and corrective action logs. The executive sponsor should confirm the appointment in writing, and the owner should confirm that each high-risk system is covered by a documented procedure.
Who owns each checklist step, who prepares the evidence and who assesses it
Your organization owns the AI Act position. It decides whether each AI system is in scope, which risk tier applies, whether an Article 6(3) exemption is documented, and whether a system is placed on the market or put into service. Legal accountability for these decisions stays with you even when a consultant drafts the analysis. Internal teams also approve the quality management system, accept residual risk, sign the internal-control assessment where Annex VI applies, and decide who holds human oversight roles under Article 26.
- Classification decisions: the accountable owner records role (provider, deployer or other operator), intended purpose and risk tier for each system.
- Prohibited practice screen: legal and product leads confirm no Article 5 practice is in use before any build work begins.
- Sign-offs: named executives approve the declaration of conformity, the deployer instructions and any fundamental rights impact assessment under Article 27.
- AI literacy: HR and business owners assign training to staff who operate or oversee AI systems.
- Legal position: counsel confirms enforcement exposure, including the fines in Article 99.
Before engaging any partner, confirm in writing which of these decisions your own people will make and which will be reviewed by counsel.
An implementation partner such as DeployOpen prepares systems, documentation, logs, tooling and evidence that your organization then reviews and owns. Work is performed within a written scope with agreed deliverables and timelines. A partner can build the logging pipeline, set up model and dataset documentation templates, configure access controls and run internal testing. It cannot take over the decisions listed in the organization tab, and it does not issue reports, attestations or certificates.
- Evidence preparation: technical documentation, risk management records and test results are assembled in the format your team chooses.
- Logging and monitoring: event logs, retention settings and alerting are implemented inside your own infrastructure.
- Tooling: inventory, ticketing and documentation platforms are deployed and hardened in your environment.
- Internal testing support: security and quality tests are run to find gaps before an external review.
- Handover: runbooks and records are delivered so your staff can operate the controls after the engagement ends.
Ask any partner to state its scope in writing, including what it will not do, and confirm that its work product is reviewed by your accountable owners.
An independent assessor or certification body tests conformity and, where a certificate applies, issues it. For most Annex III high-risk systems, the provider follows the internal-control conformity assessment in Annex VI, so the provider performs the assessment and draws up the declaration itself. Notified bodies are involved for some biometric systems and for Annex I products under Article 43. Where a notified body is needed, it is an accredited third party that is separate from both your organization and your implementation partner.
- Annex VI route: most Annex III systems rely on internal control, so no external certificate is issued for them.
- Notified body route: some biometric systems and Annex I products require a notified body under Article 43.
- Independence: the assessor must not be the party that designed the controls it tests.
- Outputs: the assessor issues any report or certificate; your partner and your staff do not.
- Timing: confirm with the notified body its own scheduling and fees, since these are set by that body.
Before selecting an assessor, confirm whether your system falls under Annex VI or needs a notified body, and check the designation status of any body you are considering.
What usually delays the AI Act checklist and how to avoid each delay
Most delays in an AI Act program come from a few avoidable assumptions: outdated dates, incomplete inventories, and documentation left until the end. The cards below name each pitfall and give one check to run before it costs time.
Working from the original high-risk dates
Many plans still use 2 August 2026 as the deadline for every high-risk rule. The 2026 amendment moved the Annex III high-risk rules to 2 December 2027 and the Annex I product rules to 2 August 2028. Before setting milestones, confirm the amended text of Article 113 in the consolidated EUR-Lex version and re-date each workstream against the category your systems fall into.
Leaving shadow AI out of the inventory
Staff often adopt AI features in SaaS tools, browser extensions or personal accounts without any approval. If the inventory only lists systems procurement or IT approved, the classification starts from an incomplete base. Ask business units and finance for their software subscriptions, review expense claims for AI services, and add a short intake step so new AI uses are recorded before they go live.
Treating a low-risk label as no record
A system classed as minimal risk or as outside high-risk still needs a documented reason. Where the Article 6(3) exemption is relied on, the provider must document the assessment before placing the system on the market and provide it on request. Write a short classification memo for each non-high-risk decision, with the date, the reviewer and the trigger that would reopen the question.
Skipping AI literacy outside high-risk
Article 4 applies to providers and deployers of all AI systems, not only high-risk ones, and has applied since 2 February 2025. Teams that wait for a high-risk project before training staff leave a gap that already exists. Identify who builds, buys, operates and oversees AI in your organization, then set training for each group and keep attendance records and course content.
Underestimating provider documentation volume
Providers of high-risk systems must maintain a quality management system, technical documentation, log keeping, a conformity assessment, a declaration of conformity, registration and post-market actions. Teams often start writing these only after the system is built. Map each Article 16 duty to a named owner and an evidence location early, and estimate the documentation effort with your own engineering and compliance leads before committing to a launch date.
Leaving transparency text until launch
Article 50 duties apply to chatbots, synthetic content, emotion recognition and deepfakes, and they shape user interfaces, disclosure labels and content marking. Copy written at the last minute often misses the disclosure timing and wording the system needs. Draft notices and labels during design, test them with users, and check the current transparency guidelines and the code of practice on marking AI-generated content before release.
Questions buyers ask about the EU AI Act compliance checklist
Which step in the AI Act checklist takes the most effort?
For most organizations, the inventory and classification step takes the most effort, because it forces a complete list of AI systems and a defensible risk tier for each one. Teams often discover AI features inside vendor products, spreadsheets and internal tools that nobody has recorded. Classification then depends on the intended purpose and the Annex III or Annex I categories, which means reading use cases against legal text and documenting why a system is or is not high-risk. Once that list is settled, the high-risk provider or deployer steps are large but predictable. The effort drops sharply for organizations whose inventory is already maintained. Ask any partner to state in writing how many systems are in scope and who signs off on each classification.
Can an in-house team complete the AI Act checklist alone?
An in-house team can complete much of the checklist alone, especially the inventory, AI literacy and transparency items, if it has clear ownership and access to system owners. Work becomes harder where the team must interpret classification edge cases, build a quality management system, or produce technical documentation and logs for high-risk systems. Legal interpretation remains the organization's responsibility, and conformity assessment for some systems requires an independent notified body. An implementation partner can prepare systems, controls and evidence, but it does not issue reports or certificates. Decide early which steps you will keep in-house and which you will scope out to a partner.
What does the checklist require from the business beyond engineering?
The checklist requires named system owners who can describe each AI system's intended purpose, users and data, plus legal or compliance review of classification and transparency decisions. Procurement must collect provider documentation for third-party systems, HR or works councils may need to be consulted where deployers must give worker notices, and a senior owner must approve the governance decisions. Engineering time is needed for logging, human oversight design, testing and documentation, and that time recurs because systems change. Ask any partner to list each role, the hours expected from it and the decisions it must sign, in a written scope before work starts.
How did the 2026 Digital Omnibus change the AI Act timeline?
The 2026 amendment, Regulation (EU) 2026/1744, moved the high-risk deadlines. The high-risk rules in Chapter III Sections 1 to 3 now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, instead of 2 August 2026 and 2 August 2027. Other dates still apply: Article 4 AI literacy and the prohibitions have applied since 2 February 2025, and the general-purpose AI rules since 2 August 2025. Transparency and other remaining duties apply from 2 August 2026 under Article 113. Confirm each date against the consolidated text as amended before fixing your plan, because the dates for each duty depend on its article and role.
Does completing the checklist show that we comply with the AI Act?
No. A checklist shows that you have looked at each obligation and recorded a decision, but compliance rests on the evidence behind those decisions and, for some systems, on an independent assessment. A high-risk provider needs a quality management system, technical documentation, logs, a conformity assessment and an EU declaration of conformity, and each must exist and be maintained. Most Annex III systems use internal-control conformity assessment under Annex VI, which the provider performs and records itself, while some biometric systems and Annex I products involve a notified body under Article 43. Only an independent auditor, assessor or notified body issues conformity outcomes, so plan to show evidence, not a ticked list.
What changes if we use a general-purpose model from another provider?
Using a general-purpose AI model from another provider usually shifts some obligations to that provider, but it does not remove yours. The model provider carries the general-purpose AI model duties in Chapter V, including technical documentation and a copyright policy, and should give you downstream information under Annex XII. Your organization remains responsible for the AI system you build on that model, including its intended purpose, classification, transparency to users, and, if it is high-risk, the provider or deployer duties that apply to your role. If you substantially modify or put your own name on the system, your role may change to provider. Ask the model vendor for its documentation package and confirm in writing which duties it covers.
When should we bring in an implementation partner or an independent assessor?
Bring in an implementation partner when the inventory is incomplete, when high-risk systems need technical controls, logging or documentation built into existing platforms, or when internal capacity cannot cover the work on your timeline. DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure and prepares systems and evidence for assessment, but it does not issue audit reports or certificates. Bring in an independent assessor or notified body when a conformity route requires one, and before you rely on your evidence externally. Most DeployOpen engagements are fixed-scope, so ask for a written scope with deliverables, responsibilities and dates before work starts.
How DeployOpen scopes the checklist and prepares evidence
DeployOpen works on the EU AI Act checklist as an implementation partner: we help prepare the systems, records and evidence that each step needs. Your organization owns its classification decisions and obligations, and an independent assessor or notified body issues any report or certificate where the Act requires one.
How we scope
- Agree the written scope first, listing which AI systems and roles (provider, deployer or model provider) the checklist covers.
- Record which systems need a classification decision and which steps apply to each, before any build work starts.
- Confirm with your legal and compliance team which dates in the Act apply to each system, using the official EUR-Lex text.
How we build
- Set up the AI system inventory, logging and oversight records that each applicable checklist step depends on.
- Prepare transparency notices and disclosure wording for chatbots and synthetic content, reviewed by your legal owners.
- Test technical controls such as logging, access and human oversight paths against the requirements in scope.
How we hand over
- Deliver a step-by-step checklist mapped to your systems, with the owner, evidence location and status of each item.
- Document configurations, runbooks and records in your own repositories so your staff can maintain them after handover.
- Provide an evidence index that your independent assessor or notified body can review, without DeployOpen issuing any certificate.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Review the checklist when the Commission publishes new guidance, harmonised standards or changes to application dates.
- Ask us for a quote based on your written scope, since DeployOpen does not publish a price list.
