What harmonised standards and the presumption of conformity mean for AI Act compliance
A provider of a high-risk AI system must show that the system meets the Act's requirements, and a harmonised standard offers a faster route than proving each point from scratch. Under Article 40(1), a high-risk system or general-purpose AI model that conforms with a harmonised standard is presumed to meet the requirements or obligations that the standard covers, provided the standard's reference has been published in the *Official Journal of the European Union*. The presumption attaches only to the requirements the standard actually addresses. Where no standard exists, Article 41 lets the Commission adopt common specifications by implementing act, and providers that depart from them must justify an equivalent solution. Article 42 adds two narrower presumptions: one for the data governance duty in Article 10(4) where systems are trained on setting-specific data, and one for the cybersecurity requirement in Article 15 where a system holds a certificate under a Cybersecurity Act scheme or, since 2026, meets the conditions of the Cyber Resilience Act.
The first harmonised standard for high-risk systems is EN 18286:2026 on quality management. Commission Implementing Decision (EU) 2026/2274, published on 14 October 2026, cited it as the only standard in its annex. That standard covers the quality management system only. It does not presume conformity for risk management, data quality, technical documentation, logging, transparency, human oversight, accuracy or robustness. Providers should map each Article 8 to 15 requirement to the standard that covers it, if one has been cited, and record which requirements still rest on their own evidence. Confirm the current list of cited references in the Official Journal before relying on any presumption, because the standardisation request C(2025) 3871 covers more topics than have been cited so far.
The presumption is partial, and it does not transfer the provider's duty to a standard body. A provider that claims conformity with a cited standard still needs a documented quality management system, technical files, test results and the conformity assessment route that Annex VI or the applicable notified body procedure requires. Assessors and market surveillance authorities will ask for the evidence that the standard was applied in practice, including who approved the design, how changes were tracked and where test results are stored. Plan to keep version-controlled records of each requirement and its evidence, and to revisit the mapping whenever a new reference is published.
Which systems and providers can rely on the presumption
The presumption of conformity under Article 40 applies only to certain systems and only to the requirements a published standard covers. Before planning any standards-based route, providers should settle which product type they are dealing with, which legislation applies alongside the AI Act, and whether a notified body or a cybersecurity certificate changes the path.
High-risk systems versus general-purpose models
Article 40(1) presumes conformity for high-risk AI systems and for general-purpose AI models, but only where the system or model conforms with harmonised standards whose references are published in the Official Journal. A provider must first decide which of the two it is placing on the market, because the requirements it has to map to a standard differ. Confirm the classification in writing before selecting standards, since a system built on a general-purpose model can carry duties from both sides.
Annex I product systems and joint compliance
AI systems that are safety components of, or products under, the Annex I product legislation follow a different timeline and a different conformity route than Annex III systems. The amended Article 40(2) requires the Commission to request standards that support joint compliance with the AI Act and that product legislation. Teams should ask their product notified body and their standards advisor whether a single technical file can serve both regimes before duplicating documentation.
Biometric systems and the notified body route
Most Annex III high-risk systems rely on internal control, but some biometric systems require the involvement of a notified body under Article 43. In that case the presumption still depends on the standard, yet the notified body assesses conformity and the provider cannot close the file internally. Ask any notified body which harmonised standards it will assess against and whether it accepts evidence prepared under them.
Cybersecurity Act certification and CRA conditions
Article 42 presumes conformity with the cybersecurity requirement in Article 15 for systems certified under a Cybersecurity Act scheme, and, since 2026, for systems that meet Cyber Resilience Act conditions. A provider that already holds a qualifying certificate or runs a product under the Cyber Resilience Act should map that evidence to Article 15 before commissioning new cybersecurity work. Confirm with the certification body exactly which certificate version and scope are recognized.
Coverage limited to the standard's scope
The presumption applies only to the requirements that a cited standard actually addresses, and only to the extent it covers them. Requirements left out of a standard, such as parts of the data or human oversight obligations if the standard does not reach them, still need their own evidence. Read the standard's scope clause and list each Article 8 to 15 requirement it covers before treating any gap as closed.
How an assessor tests a claimed presumption of conformity
This table walks through the four checks an assessor applies when a provider says a harmonised standard, common specification or certification gives it a presumption of conformity. Read each row as a question the assessor will ask, the evidence they will request, and where claims typically fail.
| Assessor check | What the assessor tests | Evidence requested | Common finding |
|---|---|---|---|
| Reference in the Official Journal | Whether the cited standard's reference is published in the Official Journal, and for which requirement, as Article 40(1) requires before any presumption applies | Copy of the Official Journal notice, the Commission implementing decision that cites the standard, and the provider's mapping of the standard to each requirement claimed | Provider relies on a standard that is requested or drafted but not yet cited, so no presumption exists |
| Scope of the standard | Whether the standard's scope and clauses actually cover the requirement claimed, such as a data, logging or accuracy duty rather than a general management system | Clause-by-clause mapping showing which parts of the standard address each Article 8 to 15 requirement, with gaps identified | Provider cites a quality management standard to cover technical requirements such as robustness or record keeping that it does not address |
| Implementation fit | Whether the provider's processes, documents and technical controls match what the standard describes, not just its title | Quality management documentation, risk management records, test results and version-controlled procedures showing the standard is operated in practice | Policies exist on paper, but records, owners or review cycles do not match what the standard requires |
| Equivalent solutions | Where no harmonised standard or common specification applies, or the provider departs from one, whether the alternative is documented and proven to meet the same requirement | Written justification of the equivalent solution, test evidence, and the link to the Article 41 common specification or Article 42 presumption being set aside | Provider departs from a common specification without any justification, or the justification does not show equal protection |
| Cybersecurity and data presumptions | Whether an Article 42 presumption, such as a Cybersecurity Act certificate or Cyber Resilience Act conformity, covers the specific Article 15 or Article 10(4) claim | Certificate or conformity documents with their scope statement, and evidence that the certified system is the same system placed on the market | Certificate covers a different product version, deployment or scope than the high-risk system being assessed |
| Currency of the claim | Whether the cited standard version and the provider's evidence are current at the time of assessment and after any substantial modification | Change log of the standard version in use, review dates, and records showing the system was reassessed after changes | Provider keeps citing a superseded version or does not reassess after a substantial change |
How to build a conformity claim on harmonised standards
This sequence turns the AI Act's requirements into a documented claim that a harmonised standard, common specification or justified equivalent solution covers each obligation. The output is a dated mapping that an auditor or notified body can test and that the organization keeps current as standards change.
List the requirements that apply to your system
Start from the obligations that apply to your system's role and risk class, such as the Chapter III Section 2 requirements for high-risk systems or the general-purpose AI model duties in Chapter V. Your compliance lead or legal counsel confirms the list, and a product owner confirms the system's intended purpose and deployment context. The output is a requirement register with one row per obligation, the article it comes from, and the owner who answers for it.
Map each requirement to requested standards
Match each row of the register to the standards in the Commission's standardisation request C(2025) 3871 of 23 June 2025, which asks CEN and CENELEC for work on risk management, data, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, quality management and conformity assessment. Record which standard is drafted or published for each topic, because a request is not the same as a citable standard. The output is a requirement-to-standard map that marks each row as covered, partly covered or not yet covered by a standard.
Check Official Journal citation status
Only standards whose references are published in the Official Journal give a presumption of conformity under Article 40(1). Check the current list against the Commission's standardisation pages and the Official Journal, and confirm the exact version and date of each citation. Commission Implementing Decision (EU) 2026/2274 cited EN 18286:2026 on quality management systems on 14 October 2026 and is the only standard in its annex, so most other rows may still lack a citation. The output is a citation status column with the Official Journal reference and a date you verified.
Gap-assess what cited standards leave uncovered
For each row with a cited standard, compare the standard's scope against the actual obligation, including any part of the requirement the standard does not address and any deployment context it does not cover. Note the gaps in the register and assign an owner to each. Your internal audit or an independent assessor can review the reasoning, but the organization decides whether the gap is acceptable. The output is a gap log that states, for every uncovered element, the evidence you will produce instead.
Choose standard, common specification or equivalent solution
For each row, document which route you follow: a cited harmonised standard, a common specification adopted under Article 41 where standards are not requested, delivered on time, adequate or published, or a justified equivalent solution. Article 41 requires providers that do not follow a common specification to justify equivalent solutions, so the record must show the technical reasoning and the evidence that it meets the requirement. The output is a decision record per row that names the route, the reason and the approver.
Assemble the conformity evidence file
Collect the evidence that shows each chosen route works in practice, such as quality management records, technical documentation, logs, test results and risk assessments. Link each artifact to its register row so an assessor can trace a requirement to its proof in a few steps. Where your system relies on Article 42 presumptions, such as cybersecurity certification under a Cybersecurity Act scheme or Cyber Resilience Act conditions, keep the certificate or assessment record in the same file. The output is an indexed evidence file where every row points to at least one current artifact.
Keep the mapping current as standards change
Standards, citations and the Commission's requests change over time, and the 2026 amendment shifted several dates, so the map needs a named owner and a review trigger. Recheck the Official Journal when a new citation appears, when the standardisation request is revised, or when your system changes materially. Version the register in a controlled wiki or document system so you can show what changed, when and by whom. The output is a dated revision history that shows the claim was current at each assessment or audit point.
Where the standards stand after the October 2026 citation
The first harmonised standard for high-risk AI systems is EN 18286:2026 on quality management systems, and it is the only standard cited so far. Commission Implementing Decision (EU) 2026/2274, of 12 October 2026 and published on 14 October 2026, cites it in its annex. The citation matters because Article 40(1) gives a presumption of conformity only for requirements the cited standard actually covers. A provider that builds its quality management system to EN 18286:2026 can presume conformity for that part of the obligations. Every other requirement, including risk management, data governance, record keeping, transparency, human oversight, accuracy, robustness and cybersecurity, has no cited standard in the Official Journal under this decision.
The work behind those remaining requirements is set out in the Commission's standardisation request C(2025) 3871 of 23 June 2025, which replaced the 2023 request. It asks CEN and CENELEC to produce standards on risk management, data, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, quality management and conformity assessment. A request is not a citation. Until a standard appears in the Official Journal, the presumption does not apply to it, and the provider must demonstrate conformity by other means, including the common specifications route in Article 41 where it is triggered.
Before relying on any harmonised standard, confirm its status yourself. Check the Official Journal for the current citation list, read the implementing decision that cites the standard, and confirm the exact version and any restrictions or exclusions it carries. Record the date you checked and the version you relied on in your technical documentation. Standards are revised and citations can be amended, so a reference that was valid at design time may need review before placing on the market. Ask your notified body or assessor, where one is involved, how it will treat standards that are not yet cited.
Evidence that supports a presumption of conformity
A presumption of conformity only holds if the provider can show which standard was applied, which version was cited, and how each clause maps to a requirement. The cards below cover the records an assessor or market surveillance authority will ask for, and how to keep them current between audits.
Standard reference and version record
Record the exact standard, edition and year you applied, such as EN 18286:2026 for quality management, together with the date you adopted it. Confirm that the reference you rely on is the one listed in the Official Journal citation, because a presumption attaches to the cited standard and not to a later draft. Keep a note of any part of the requirements the standard does not cover, since the presumption only extends to the extent covered.
Official Journal citation record
Keep a dated copy of Commission Implementing Decision (EU) 2026/2274 and the publication details that show the standard was cited. Note the decision date and the publication date separately, and check the Commission's standardisation pages for any later citation or withdrawal. Assessors will ask which version of the citation your conformity claim relied on at the date of placing on the market.
Clause-to-requirement mapping
Build a table that links each clause of the cited standard to the AI Act requirement it supports, such as quality management and the Article 17 obligations. Mark clauses that are not applicable and state why. Ask your auditor whether they want the mapping at clause level or section level, and confirm that every gap in the mapping has a documented compensating control.
Quality management system documentation
For EN 18286:2026, keep the policy, objectives, process descriptions, roles, and records that show the quality management system runs in practice. Include the change log for design, data and model updates, and evidence of management review. Because the standard is the first cited for high-risk systems, confirm with your notified body or internal assessor how they will read each clause before you build the records around it.
Common specification or equivalent-solution records
Where no harmonised standard applies, Article 41 common specifications stand in its place. If you depart from a common specification, keep a written justification that shows your solution achieves an equivalent level of compliance, with test results and a rationale an assessor can review. Store these records with the version of the specification they were tested against, so they remain traceable when the specification is replaced.
Cybersecurity certificates and scheme references
For a presumption under Article 42 on the cybersecurity requirement of Article 15, keep the certificate, the scheme name, the certification body and the scope statement that covers the AI system. Check the certificate expiry date and the scope against the deployed configuration, since a certificate for a different build does not support your claim. Where you rely on Cyber Resilience Act conditions instead, keep the evidence that those conditions are met.
What relying on harmonised standards costs
This table breaks down the cost components of using harmonised standards, common specifications or cybersecurity certification to presume conformity under Articles 40 to 42. It marks each component as one-time or recurring and names the factors that move it up or down. Use it to structure a quote request, since no fee or duration is supplied for these items and each must be confirmed with the vendor, standards body or assessor.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Standards access and purchase | Standards bodies (CEN, CENELEC or national members) | One-time per standard, plus updates when revised | Number of standards cited for your system, licensing terms, and whether your organization needs multi-user access. Confirm current pricing with the standards bodies. |
| Gap assessment against cited standards | Internal engineers or an implementation partner | One-time, repeated after major system changes | Number of high-risk systems in scope, how mature existing quality and risk processes are, and how much documentation already exists. |
| Mapping upkeep between standards and controls | Compliance staff or tooling administrators | Recurring, tied to each standard revision or Commission update | Number of frameworks mapped, how often the Official Journal citations change, and whether mappings are maintained in a tool or by hand. |
| Quality management system work under EN 18286:2026 | Internal quality, engineering and legal staff, plus any consultant or auditor | One-time build, then recurring maintenance and internal audits | Size of the organization, number of products and systems under one QMS, and how many existing processes can be reused. |
| Equivalent-solution justification | Internal technical and legal staff, sometimes outside counsel | Per system, and again when the design or the standard changes | Whether a relevant standard exists for the requirement, how novel the design is, and how much testing evidence supports the alternative. |
| Notified body or cybersecurity certification fees | Notified bodies or certification bodies under a Cybersecurity Act scheme | One-time per assessment, with recurring surveillance where the scheme requires it | Whether the system falls under a notified body route, the certification scope, and the number of product versions. Request the fee basis in writing. |
| Internal monitoring of cited standard versions | Compliance and engineering owners | Recurring | Frequency of Official Journal updates and the number of systems that depend on each cited standard. |
Open-source tools that hold the mapping and version history
CISO Assistant is the tool in this stack built for holding requirements, controls and assessments in one place. Its README describes more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, along with audits, compliance assessments and automatic mapping between frameworks. For Article 40 work, the practical question is whether the AI Act requirements and the standards that support them can be loaded as a framework of their own, so each requirement links to its controls, owners and evidence.
- Requirement entries. Record each requirement in Chapter III Section 2 that a harmonised standard is expected to cover, along with the standard clause that addresses it.
- Assessments. Store each assessment of whether a standard covers a requirement, with the date, the assessor and the result.
- Mapping records. Keep the link between a standard clause and an internal control, and mark any mapping that is only partial.
- Evidence links. Attach the policy, test result or log that supports each control, so a reviewer can follow the chain from requirement to proof.
Check whether the release you deploy includes an AI Act or harmonised standard library, or whether you must create a custom framework and maintain its mappings yourself.
XWiki keeps a version history for every page, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. That history matters for presumption of conformity because a reviewer may ask which standard edition a justification relied on and when the team changed its reasoning. The XWiki document version control overview describes these features, and the wiki is where the prose rationale for each mapping decision lives while CISO Assistant holds the structured records.
- Justification pages. Write why a standard clause covers a requirement, including its limits and any gaps that remain.
- Change history. Use the recorded authorship and timestamps to show when a rationale changed and who made the change.
- Version comparison. After a new standard edition is cited, compare revisions to see exactly what changed in the reasoning.
- Rollback scope. Rolling back restores page content, so keep approvals and sign-offs in a system that records them separately.
- Exact references. Link each page to the specific standard, edition and Official Journal citation used, not only to the standard's title.
Check the wiki's audit trail, backup and retention settings with your platform team, because version history alone may not meet your own record retention rule.
BookStack organizes content into shelves, books, chapters and pages, and user abilities come from the roles assigned to them. Permissions can be overridden per role at the shelf, book, chapter or page level. For the standard references that a presumption of conformity depends on, this means edit rights can be limited to the people who own the mapping while reviewers keep read access. The BookStack roles and permissions documentation explains how these overrides combine.
- Role design. Create roles such as standards owner, reviewer and reader, and assign them to named people rather than to shared accounts.
- Page-level restrictions. Limit edit rights on the page that lists each cited harmonised standard and its edition.
- Shelf scoping. Keep draft standard analysis on a separate shelf with wider editing rights than the approved standards register.
- Approval discipline. Pair BookStack permissions with a formal review step, because the tool controls who can edit but does not record sign-off on its own.
- Access reviews. Review role assignments on a schedule your compliance lead sets, and remove access when people change roles.
Check that each role override works as intended on every page you plan to lock, because inherited permissions can differ from what the shelf view suggests.
The three tools carry different licenses, and the license determines what your organization must do if it modifies them or offers them to others. CISO Assistant is licensed under AGPL-3.0-only, XWiki under LGPL-2.1-or-later and BookStack under MIT. These are legal questions as well as technical ones, so have counsel confirm them against your deployment model before rollout, especially if you change the code or host it for third parties.
- AGPL-3.0-only (CISO Assistant). A modified version made available to users over a network can carry source disclosure duties for those modifications under the license terms.
- LGPL-2.1-or-later (XWiki). The library-level copyleft applies to the licensed code and its modifications, and the obligations depend on how components are linked and distributed.
- MIT (BookStack). A permissive license that generally requires the copyright notice and license text to accompany copies of the software.
- Framework content. Mapping data you create may be your own material, but confirm how any framework content bundled with a tool is licensed before you reuse it elsewhere.
- Dependencies. Each tool pulls in other packages with their own licenses, so the review should cover the full stack and not only the three top-level projects.
Check the license texts in the repositories you deploy and record the exact versions you run, so the license review matches the code in production.
None of these tools gives an organization presumption of conformity. Under Article 40(1), the presumption applies to high-risk systems and general-purpose AI models that conform with harmonised standards whose references are published in the Official Journal, and only to the extent those standards cover the requirement. Commission Implementing Decision (EU) 2026/2274, which cites the first harmonised standard for high-risk AI systems, cited EN 18286:2026 on quality management systems on 14 October 2026, and it is the only standard in its annex. The software records how you argue conformity. The standard and the conformity process decide whether that argument holds.
- Standard status. Confirm that each standard you cite is referenced in the Official Journal and covers the exact requirement, since a draft or uncited standard gives no presumption.
- Coverage gaps. Record which requirements a standard does not address, and document the other evidence you use for them.
- Conformity route. Keep the assessment route set by Article 43 and Annex VI in the plan, because a software mapping does not replace it.
- Tool output. Assessments, mappings and wiki pages are internal records, not certificates or assessor reports.
- Independent review. Where the Act requires an independent body, that body issues the report or certificate, and the tools only organize the evidence it reviews.
Check the Official Journal entry for each standard before the tool marks a requirement as covered.
Common mistakes when claiming the presumption
A provider can only rely on the presumption of conformity for the requirements a published harmonised standard actually covers. The mistakes below share one root cause: the claim outruns the standard's scope, status or citation. Each card names a gap and the check to run before the claim goes into a technical file.
Citing a standard that does not reach the requirement
Article 40(1) gives the presumption only to the extent a harmonised standard covers the corresponding requirement. A standard on quality management does not establish that a training dataset was relevant or representative, or that a logging design meets record-keeping duties. Map each Article 8 to 15 requirement to a specific clause of the cited standard and mark any requirement left uncovered. Check every requirement against a written clause, not against the standard's title.
Relying on a draft or uncited standard
A standard under development, or one that has been requested but not cited, gives no presumption of conformity. Teams sometimes cite a CEN or CENELEC draft in a conformity file because it reflects the expected direction of the work. Confirm that the reference appears in the Official Journal through the implementing decision that cites it, and record the citation date and edition in the file.
Missing changes in Official Journal citations
The presumption depends on the citation status at the time of conformity, and citations can be amended or withdrawn. A file that was compliant against a standard when it was assessed can lose its presumption if the reference changes later. Assign an owner to track the Official Journal and the Commission's standardisation page, and schedule a review of each cited standard before major releases and after any new implementing decision.
Skipping documented equivalent solutions under Article 41
Where no harmonised standard applies, or a provider departs from a common specification, Article 41 requires the provider to justify an equivalent solution. Engineering teams often adopt an internal control set and assume it counts as equivalent without showing how it meets the same requirement. Write a comparison that maps each requirement to the alternative control, the evidence it produces and the reason the outcome is at least as protective.
Treating EN 18286:2026 as the full quality system
EN 18286:2026 is cited as a standard on quality management, which supports the quality management duties in Article 17. It does not, on its own, cover the full Article 17 quality system, including the technical documentation, post-market monitoring, incident handling and data governance that the regulation expects to be run in parallel. Read the standard's scope clause against the full list of Article 17 elements, then document which parts sit in other standards, in internal procedures or in the conformity assessment.
Overlooking cybersecurity certification conditions
Article 42 links the cybersecurity presumption to certification under a Cybersecurity Act scheme or, since 2026, to meeting Cyber Resilience Act conditions. A certificate that covers only part of the system, or a certificate that expired or does not name the AI component, does not carry the presumption. Confirm the certificate's scope, validity period and the specific Article 15 elements it addresses, and keep the certificate with the technical file.
Questions buyers ask about harmonised standards and the AI Act
Does following a harmonised standard remove the need for evidence?
No. Under Article 40(1), a high-risk system or general-purpose AI model that conforms with a harmonised standard whose reference is published in the Official Journal is presumed to meet the requirements or obligations that the standard covers, and only to that extent. The provider still has to show that its system was built to the standard, keep the documentation that proves it, and handle any requirement the standard does not reach. Assessors will ask for the records behind the claim, so treat the presumption as a shortcut to a conclusion you must still evidence, not as a replacement for evidence.
How do we check whether a standard is cited in the Official Journal?
Check the Official Journal reference first, not the standard's title or a vendor's marketing. The Commission's Implementing Decision (EU) 2026/2274 cited EN 18286:2026 on quality management systems on 14 October 2026, and it is the only standard in that annex. Confirm the current list against the Commission's standardisation pages and the consolidated text of the Act, because later decisions may add or change references. Record the date you checked and the reference you relied on, since the presumption applies only to standards whose references are published.
What happens if no harmonised standard exists for a requirement?
Article 41 lets the Commission adopt common specifications by implementing act where standards are not requested, not delivered on time, not adequate, or not published. Providers that do not follow a common specification must justify in their documentation that their equivalent technical solution meets the requirements. In practice, this means the gap is covered by engineering evidence you produce yourself: a documented rationale, test results and a reasoned comparison against the requirement text. Expect this route to take more review effort than following a published standard, and plan the time for it.
How can cybersecurity certification help with Article 15?
Article 42 presumes conformity with the cybersecurity requirements in Article 15 for a high-risk system certified under a scheme adopted under the EU Cybersecurity Act. Since the 2026 amendment, the presumption also applies where the system meets the conditions of the Cyber Resilience Act. Check the scope of the certificate against your system boundary, because a certificate for a platform component may not cover the model, the data pipeline or the deployment environment. Certification shortens the evidence trail for the covered part of Article 15 but does not cover the rest of the Act.
How much effort and time does the standards mapping take, and what must our team supply?
The effort depends on the number of requirements in scope, how many systems you run, and how well your existing management system already covers risk, quality, logging and security. The work usually falls into four parts: mapping each requirement to a clause or control, identifying which standards are cited, finding gaps, and collecting evidence. Your team must supply the system inventory, the intended purpose, the training and test data descriptions, the architecture and logs, and the named people who own each control. Ask any partner for a written scope and an effort estimate that lists those inputs, and confirm the timeline against the dates in Regulation (EU) 2026/1744.
Can an outside partner prepare the evidence while we keep the declaration of conformity?
Yes, a partner can prepare systems, controls and evidence, but the provider remains responsible for the EU declaration of conformity and for the decision to place the system on the market. The partner's role is to build and document the controls, test them and assemble the evidence pack. Where the Act requires a notified body, only that body issues the certificate, and an independent auditor or certification body issues any audit report. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue reports, attestations or certifications, so the written scope should name who signs each artifact.
Which parts of the evidence work can our own team do without outside help?
Most organizations can handle the inventory, the intended-purpose statement and the first pass of the requirement mapping with their own staff, provided those people understand both the system and the Act. Outside help is most useful for the technical evidence: test design, logging configuration, cybersecurity testing and the hosting of records in a controlled system. Keep the decisions that define your risk position, such as classification and accountability, under internal ownership. Self-hosted tools such as CISO Assistant can track frameworks and assessments, and wiki or documentation platforms with version history can hold the evidence trail, so the team can keep the records current after the project ends.
How DeployOpen prepares standards-based evidence
DeployOpen plans, implements and documents the systems and evidence that a provider would point to when claiming presumption of conformity, and it does so inside the client's own environment under a written, fixed scope agreed before work starts. In practice that means the work product is a set of prepared artifacts: a mapping from the requirements a harmonised standard covers to the controls, configurations and records the provider actually runs, the technical documentation those controls rest on, and system-level evidence such as access settings, logging configuration and change records exported from the client's own platforms. The provider owns its quality management system and its conformity claim. DeployOpen does not decide which standard applies, does not declare conformity, and does not issue reports or certificates. Those remain with the provider's own sign-off and, where the Act requires it, with an independent notified body.
Before committing to a scope, the provider should confirm three things in writing. First, which harmonised standards and common specifications are relevant to each high-risk system, given that the first harmonised standard cited in the Official Journal, EN 18286:2026 on quality management, covers only one part of the picture. Second, which requirements the provider intends to claim by presumption and which it will demonstrate by other means, since the presumption applies only to the extent a standard covers the requirement. Third, whether any cybersecurity claim under Article 42 rests on a Cybersecurity Act certification or on Cyber Resilience Act conditions, because the evidence set differs for each route. A fixed-scope agreement should list these decisions, the documents and system exports to be delivered, and the client's named reviewers.
Because standards and the amended dates may change, DeployOpen recommends that the provider keep the mapping under version control, so each revision records what changed, when and by whom. The provider's compliance and legal teams should check the current status of each standard against the Official Journal and the Commission's standardisation pages before relying on it. Ask any implementation partner to show how the mapping will be maintained after delivery, who approves changes to it, and how it will be handed to the independent body that assesses the system.
