What Article 13 manufacturer obligations ask a company to prove
A manufacturer placing a product with digital elements on the EU market must be able to show, before the product leaves its hands, that Article 13 duties are met. Article 13 sits alongside the Annex I technical requirements and covers the paperwork, supply chain checks and after-sale conduct that regulators will ask to see: due diligence on third-party and open-source components, technical documentation, the conformity assessment, the EU declaration of conformity and CE marking, identification and contact details, user information, corrective action and record retention. The risk it addresses is simple to state. A product can meet every technical requirement on the day it ships and still fail an inspection if the manufacturer cannot show how it reached that state, which components it trusts, and who to contact when something goes wrong.
These duties are hard in practice because they span teams that rarely share records. Engineering holds the component inventory and SBOM, procurement holds supplier terms, product security holds the vulnerability process, legal holds the declaration and labelling, and support holds the user information. Article 13(5) asks for due diligence on third-party components, including free and open-source components not supplied in a commercial activity, and the Commission's FAQ lists concrete checks such as CE marking status, security update history, known vulnerabilities, support period and the supplier's security posture. Each check needs a dated record, and a component that cannot be traced to a current SBOM entry is a gap an assessor will find. Decide early who owns each record and where it is kept.
The timeline is the first decision to make. The Article 14 reporting obligations apply from 11 September 2026, and the regulation applies from 11 December 2027, so a product launched in the interim must already support incident and vulnerability reporting while its full Article 13 file is being built. Technical documentation and the EU declaration of conformity must be kept for at least 10 years or for the support period, whichever is longer, so retention systems should be chosen for that horizon rather than for the next audit. Confirm with your notified body or conformity assessment provider which module applies to your product class, and confirm the current status of the harmonized standards with the Commission's CRA pages before you rely on them as presumption of conformity.
Which products, components and teams fall under Article 13
Article 13 applies to whoever places a product with digital elements on the EU market as its manufacturer, so the first decisions are about role, timing and what is inside the product. Each card below is a separate decision that changes how much documentation, due diligence and evidence the organization must produce.
Manufacturer or importer role
Article 13 duties sit with the manufacturer. If your company puts its own name or trademark on the product and places it on the market, you carry those duties. If a non-EU manufacturer's product reaches the EU through your company, the importer duties in Article 19 apply instead, and you should confirm which role your company holds for each product line. Check contracts, labels and distribution agreements before assuming either role.
Products placed before 11 December 2027
Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. The Article 14 reporting obligations, however, apply to all in-scope products whenever they were placed on the market. Map your installed base and record the date each version was first placed on the market, since that date drives both scope and the support period.
Substantial modification triggers
A later substantial modification can bring an older product into scope, so release engineering needs a documented test for what counts as substantial. Major architecture changes, new network-facing functions or altered security features are the changes most likely to matter. Ask your legal or product compliance team to confirm the criteria against the Commission's guidance, and log each release decision as evidence.
Third-party and open-source components
Article 13(5) requires due diligence when you integrate third-party components, including free and open-source components that were not supplied in a commercial activity. Every library, container base image and embedded package becomes part of your compliance surface. Inventory them in an SBOM, check their security update history and known vulnerabilities, and confirm each component's support period before you ship.
Teams that hold the documentation
Technical documentation, the EU declaration of conformity and user information must be kept available to authorities for at least 10 years after placing on the market or for the support period, whichever is longer. Engineering, product security, legal, support and procurement each produce parts of that record. Name an owner for each artifact and agree who signs off, because a gap in any one team can leave the file incomplete.
How an assessor tests the Article 13 duties
This table sets out each Article 13 manufacturer duty, how a market surveillance authority or conformity assessment body would test it, the evidence it will ask for, and the findings that most often delay a file. Use it to check your own records before an assessor does, and confirm with your conformity assessment body which of these tests apply to your product class.
| Duty | How it is tested | Evidence requested and common findings |
|---|---|---|
| Design, development and production in line with Annex I Part I (Article 13(1)) | Assessor traces each Part I requirement to the manufacturer's cybersecurity risk assessment and checks that design decisions reflect it. | Risk assessment, requirement-to-control mapping, design records. Finding: requirements listed but no evidence they shaped the product. |
| Due diligence on third-party and open-source components (Article 13(5)) | Assessor samples components from the SBOM and asks for the checks made before integration, including known vulnerabilities and support status. | Component records, SBOM, software composition analysis output, support period checks. Finding: undocumented open-source components or no record of checks. |
| Effective vulnerability handling for the support period (Article 13(8)) | Assessor checks that the Annex I Part II process is running, not only written, and that it covers the declared support period. | Vulnerability handling procedure, triage and patch logs, advisories issued. Finding: a policy with no dated entries. |
| Technical documentation and conformity assessment before placing on the market (Article 13(12)) | Assessor requests the file and checks it is complete for the applicable module and dated before the product was placed on the market. | Technical documentation file, conformity assessment record, notified body certificate where applicable. Finding: documentation written after release. |
| EU declaration of conformity and CE marking (Article 13(12)) | Assessor checks the declaration names the product, cites the applicable requirements and that the marking is on the product or its documentation. | Signed declaration, marking photographs, product labels. Finding: declaration not updated after a substantial modification. |
| Type, batch or serial number, manufacturer name, contact details and single point of contact (Article 13(15) to (17)) | Assessor inspects the product, packaging and documentation for identifiers and checks that the contact channel is monitored. | Photographs of labels, contact page, support mailbox records. Finding: contact details that are outdated or go to an unmonitored address. |
| User information and instructions in an understandable language (Article 13(15) to (18)) | Assessor reads the Annex II information and instructions against the product as shipped and checks the language requirement. | Packaged user guides, translation records, online instructions. Finding: Annex II content missing from the version users receive. |
| Corrective action, withdrawal or recall (Article 13(21) and (23)) | Assessor asks for the log of cases where the manufacturer had reason to believe the product did not conform, and how authorities and users were informed. | Corrective action log, recall or withdrawal records, notices issued. Finding: issues closed without a recorded assessment of conformity. |
| Retention of technical documentation and declarations (Article 13(13) and user information under Article 13(18)) | Assessor checks that records can be produced on request and that the retention period runs for the longer of ten years or the support period. | Retention schedule, archive index, version history of documents. Finding: no retention period set, or records overwritten by later versions. |
Implementing Article 13 step by step, with the output of each step
The sequence moves from knowing what is inside the product to proving conformity, marking it and keeping the records that market surveillance authorities can request. Each step produces a document or register that the next step depends on.
Inventory every third-party and open-source component
Start by listing every component the product integrates, including libraries, container base images, firmware blobs, frameworks and open-source packages pulled in during build. Engineering owns the list, and the product security lead reviews it against the build manifests and lockfiles. The output is a component register that records name, version, supplier, license and where each component sits in the product. Generate an SBOM from the build where possible, for example with Trivy, so the register is reproducible rather than typed by hand. The step is done when the register matches what ships in the latest release candidate.
Run due diligence checks on each component
For each entry in the register, check the points Article 13(5) and the Commission's FAQ describe: whether the component carries CE marking where that applies, its security update history, its known vulnerabilities, its support period and the security posture of its manufacturer. Review the component's SBOM where one is published. Software composition analysis tools such as OWASP Dependency-Track can track vulnerabilities and license risk across the register over time. The output is a due diligence record per component, with the date, the checker and the decision to keep, replace or accept with a documented risk.
Assess risk and select the conformity route
Use the manufacturer's cybersecurity risk assessment to determine which Annex I requirements apply to the product and how each is met. Confirm the product's category under the scope and classification rules, because that category decides the conformity assessment route. Most products follow self-assessment under module A, while class I important products, class II products and critical products may require a notified body. Confirm the route with the national market surveillance authority guidance and the current harmonized standards before committing budget. The output is a signed risk assessment and a written route decision that names the module and, if relevant, the notified body.
Draft the technical documentation set
Compile the technical documentation that shows how the product meets Annex I, covering the product description, the risk assessment, the design and development records, the component register and due diligence records, test results, vulnerability handling procedures and the applied standards. Product engineering writes most of the content, while compliance and legal review the structure. Keep the documentation under version control, so each release can be tied to the exact evidence behind it. A wiki with page history, such as XWiki, can hold the narrative while build artifacts hold the test outputs. The output is a versioned documentation set with an owner for each section.
Complete conformity assessment and sign the declaration
Carry out the assessment module chosen in the previous step, either internally or with the notified body, and record the findings against each Annex I requirement. Where the assessment passes, draw up the EU declaration of conformity that names the product, the manufacturer and the standards or specifications applied. Only the manufacturer signs the declaration, and an independent notified body issues any certificate it is required to issue. The output is a signed EU declaration of conformity and, where needed, the notified body certificate filed with the technical documentation.
Affix CE marking and add identification and contact details
Affix the CE marking to the product, or to its packaging or documentation where the product is too small, and add the type, batch or serial number that identifies the individual product. Publish the manufacturer's name, registered trade name or trademark, postal address and email address, and name a single point of contact for users. Confirm the marking and labeling against the requirements for the product category before the first shipment. The output is a labeling specification and a sample unit or label proof that shows the marking and identifiers in place.
Prepare user information and corrective action procedures
Write the user information and instructions in a language that users and authorities can easily understand, covering the Annex II information, the support period end date and how to report vulnerabilities. Then set the corrective action procedure: how the team decides a product or process does not conform, who can order an immediate fix, withdrawal or recall, and how authorities and users are informed. Include the steps to inform authorities and users before ceasing operations. The output is an approved user information pack and a written corrective action and recall procedure with named roles.
Set the record retention schedule
Define how long each record is kept and where it is stored. Article 13(13) and 13(18) set a retention period of at least 10 years after placing on the market or for the support period, whichever is longer, for the technical documentation, the EU declaration of conformity and user information. Record the storage location, access controls, backup approach and owner for each item, and confirm that the records stay retrievable for market surveillance authorities. The output is a retention schedule that maps each record to its period, owner and storage location, reviewed whenever the support period changes.
Evidence that passes an Article 13 review and how to keep it current
Article 13 reviews come down to whether a manufacturer can produce current, dated records for each duty on request. The six artifacts below cover the technical file, the declaration, component diligence, identification, user information and corrective action, and each one needs a named owner and a retention plan that runs for at least 10 years or the support period, whichever is longer.
Technical documentation file
This is the central file a market surveillance authority asks for first, and it must show how the product meets Annex I Part I and how the conformity assessment route was applied. Keep it as a controlled set of documents with a version number tied to each released product version, and record the risk assessment, design decisions, test results and the reasons for any harmonized standard that was or was not applied in full. Check that every document names the product version it describes. Store each revision with its change history so a reviewer can see what changed, when and why.
EU declaration of conformity
The EU declaration of conformity is the signed statement that the product meets the applicable requirements, and it must be drawn up after the conformity assessment and before the product reaches the market. Keep one signed copy per product version, with the standards and common specifications referenced and the identity of the signatory. When a product is updated in a way that changes its conformity, review whether a new declaration is needed. Keep every superseded declaration on file, since authorities may ask what applied to a unit placed on the market at a given date.
Component due diligence register with SBOMs
This register records each third-party and open-source component, its version, its licence, its support period and the due diligence checks performed on it, including whether its manufacturer is identifiable and how it handles security updates. Keep an SBOM for each release, generated from the build rather than written by hand, and keep a dated log of vulnerability findings and the decision taken on each. Tools such as OWASP Dependency-Track can track components and known vulnerabilities across releases. Review the register whenever a component is upgraded or replaced.
CE marking and identification records
These records show that each product carries a type, batch or serial number, the manufacturer's name, registered trade name or trademark, postal address and electronic contact, and that the CE marking was affixed in line with the declaration. Keep a dated record of label and packaging artwork for each version, and a serial-number register that links every unit to its product version and build. Confirm that contact details stay valid, because a change of address or mailbox should be recorded and reflected on the product and in user materials.
User information and single point of contact record
This record holds the security instructions and information supplied with the product, in a language users and authorities can easily understand, and the designated single point of contact through which users report vulnerabilities and receive updates. Keep each version of the instructions with its release date and the product versions it covers. Log every change to the contact channel and test that it still reaches a staffed mailbox. Retain the material for the same 10-year or support period rule as the technical file, and confirm the information is accessible to users after the product is sold.
Corrective action and withdrawal log
This log records each occasion on which a manufacturer knew or had reason to believe that a product or process did not conform, the immediate corrective action taken, any withdrawal or recall, and the notices sent to authorities and users. Each entry should record the trigger, the decision, the people involved and the dates. Keep the log even when no action was needed, and link entries to the affected product versions and vulnerability records. Confirm with counsel how the log interacts with reporting duties under Article 14, which apply from 11 September 2026.
What meeting Article 13 costs in money and effort
This table breaks the cost of Article 13 compliance into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a request for quote, since no price list is published and every figure depends on the written scope of your product and your own environment.
| Cost component | One-time or recurring | Who is paid or who bears the cost | What drives it up or down |
|---|---|---|---|
| Tooling and licenses | Recurring | Tool vendors or your own staff; self-hosted open-source tools carry no license fee but still need hosting and administration | Number of products, tool choice, and whether SBOM and vulnerability tracking run on self-hosted open-source platforms |
| Engineering time for component due diligence | Recurring, with a large first-pass effort | Your engineers, or an implementation partner under a written scope | Number of third-party and open-source components, their support periods, and how often they change |
| SBOM creation and upkeep | Recurring with each release | Your build and security engineers, or a partner who sets up the pipeline | Release frequency, build complexity, and whether SBOMs are generated automatically in CI |
| Technical documentation | One-time per product version, then updates | Your product, security and compliance staff; a consultant if you outsource drafting | Product complexity, number of versions on the market, and how well design records already exist |
| Conformity assessment and notified body fees | One-time per assessment, plus re-assessment after substantial change | Notified body or conformity assessment body, only where the product class requires one | Product class under Annex III or Annex IV, and whether harmonized standards are applied in full |
| External testing or independent review | Recurring, usually tied to major releases | Independent testing firms or assessors chosen by you | Attack surface, release cadence, and how much testing is already done internally |
| Record retention for at least 10 years | Recurring storage and access costs | Your IT and records teams, or your document platform vendor | Support period length, which can extend retention beyond 10 years, and how records are versioned and archived |
| Support period maintenance | Recurring for the whole support period | Your engineering and vulnerability handling staff | Length of the support period you disclose, and how many product versions remain supported at once |
How self-hosted open-source tools produce Article 13 evidence
The most useful way to see open-source tooling for Article 13 is as a set of evidence producers. Each tool generates records that feed the technical documentation, the due diligence file and the compliance record, and the manufacturer decides what those records mean for its product. For the third-party and open-source component duties in Article 13(5), OWASP Dependency-Track (Apache-2.0) is the natural starting point. It consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component using SPDX license IDs. Its output gives you a dated view of each component's exposure, which supports the security update history and known vulnerability checks listed in the Commission's due diligence guidance.
Trivy (Apache-2.0) supports the SBOM side of the same trail. It identifies OS packages and software dependencies in a target and can produce them as an SBOM, and it can also scan SBOMs you already receive from suppliers. Use it to check that the SBOM you hold matches what is actually in the build, and keep the generated files with each release. CISO Assistant (AGPL-3.0-only) covers the assessment side. It runs audits and compliance assessments and tracks evidence against frameworks, so the controls you map to Annex I and to your own conformity process can be linked to the artifacts that show them. XWiki (LGPL-2.1-or-later) keeps the narrative record: every change to a page is versioned with what changed, when and by whom, and earlier versions can be compared or restored. That history matters because the technical documentation and EU declaration of conformity must be retained for at least 10 years after placing on the market or for the support period, whichever is longer.
These tools produce inputs. They do not replace the manufacturer's risk judgment, its decision on whether a component is acceptable, or the conformity assessment route, and they do not make a product compliant. An independent auditor or notified body will test whether the records are complete, consistent and tied to the product as placed on the market. Before relying on any of these tools, confirm with your own environment that they fit your build pipeline, data residency, retention and access controls, and that their outputs can be exported in the formats your auditor expects. Confirm licence terms with your legal team, since the AGPL-3.0-only and LGPL-2.1-or-later obligations apply differently depending on how you deploy and modify each tool.
Who does what: your team, an implementation partner and the assessor
Your organization remains the manufacturer under the regulation, so it owns every Article 13 duty. That includes deciding how the product is designed and produced, confirming that each third-party and open-source component has been checked, drawing up the technical documentation, choosing and completing the conformity assessment route, signing the EU declaration of conformity and affixing the CE marking. Outside parties can prepare material, but accountability does not move to them.
- Ownership of the declaration: Only the manufacturer can sign the EU declaration of conformity and decide to place the product on the market.
- Due diligence records: Your product or security team must document checks on each component, including its update history, known vulnerabilities and support period.
- Technical documentation: Your engineers and product managers own the content, even if a partner drafts sections.
- Corrective action and recall decisions: Your leadership must act when the product or its processes do not conform, and must inform authorities and users before ceasing operations.
- Record retention: Your organization keeps the documentation and declaration for at least 10 years after placing on the market or for the support period, whichever is longer.
Before engaging any outside party, confirm internally who holds each Article 13 duty and who will sign each record.
An implementation partner such as DeployOpen works on the systems and evidence that your team will rely on. In a self-hosted model, the work happens in your own cloud accounts, data centers or air-gapped networks, so the records stay under your control. The partner does not decide conformity, does not sign the declaration and does not issue any report or certificate. Its role is to make your controls observable and your evidence complete.
- SBOM tooling setup: A partner can install and configure tools such as Trivy for generating software bills of materials and OWASP Dependency-Track for tracking components, vulnerabilities and licenses.
- Documentation drafting: A partner can build the structure for technical documentation and draft sections from system facts, for review by your engineers.
- Testing and verification: A partner can run security testing of the product and record the results against your risk assessment.
- Evidence collection: A partner can configure version-controlled wikis, such as XWiki, so that changes to procedures and records are traceable by date and author.
- Hardening and upgrades: A partner can apply configuration changes and update tooling across the support period.
Before signing a scope, ask the partner to list each deliverable, the person on your side who accepts it and the records it will leave in your environment.
Where the conformity route requires it, an independent body makes the conformity determination. For most products, the manufacturer performs self-assessment under module A without a notified body. A notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II and critical products. Notified bodies are designated by Member States and listed in the Commission's NANDO system. Market surveillance authorities check products and enforce the regulation afterward.
- Independence: The assessor must not design, build or operate the product it evaluates, so partners cannot act as the assessor for the same product.
- Route selection: Confirm early whether your product falls in the self-assessment route or needs a notified body, based on its class in Annex III or Annex IV.
- Scope of review: The body reviews technical documentation and evidence against the requirements, not your internal design choices.
- Output: Only the assessor issues conformity results or certificates where the route requires them. A partner's test report is evidence, not a conformity result.
- Timing: Ask the assessor about its current queue and information requirements before fixing a launch date.
Before engaging a notified body, confirm that it is designated for the relevant product category in the NANDO listing.
Where manufacturers fall short on Article 13 and how to close each gap
Most Article 13 failures are not missing policies. They are stale inventories, unrefreshed due diligence, documentation that drifts from the shipped release, and records or user information that were never set up to survive the support period. Each card below names one gap and the remedy that closes it.
No inventory of open-source components
Without a current list of every third-party and open-source component in each shipped release, a manufacturer cannot show due diligence under Article 13(5) or respond to a new advisory quickly. Generate a CycloneDX SBOM from each build and store it with the release record. Use OWASP Dependency-Track to ingest those SBOMs and flag components with known vulnerabilities. Check that the inventory covers transitive dependencies and container base images, not only direct libraries.
Due diligence done once, never refreshed
Many teams assess a component when they first adopt it and never look again. Article 13(5) expects diligence that keeps pace with the product, and FAQ 4.4.2 lists checks such as the component's security update history, known vulnerabilities and support period. Set a recurring review tied to the release cadence, record the outcome for each component version, and re-check whenever the component's support status changes. Ask the component's maintainers what their support commitments are.
Documentation that does not match the shipped release
Technical documentation drifts when engineers update code but not the design notes, risk assessment or test reports. Article 13(12) requires the documentation to exist before the product is placed on the market, and Article 13(13) requires it to be kept for the support period. Tie each documentation set to a specific release identifier and store it under version control, so every change records what changed, when and by whom. Compare the document set against the SBOM before each release.
User information missing a single point of contact
Article 13 requires the manufacturer's name, contact details and a single point of contact where users can report vulnerabilities and receive updates. Teams often publish a generic support mailbox that nobody monitors for security reports. Name a role, not only a shared inbox, and confirm who triages messages and how quickly. Print the contact details on the product, in the packaging or the instructions, in a language users can easily understand, and include the type, batch or serial number so users can tie a report to a specific device.
No corrective action procedure for withdrawal or recall
Article 13(21) requires immediate corrective action, withdrawal or recall when the manufacturer knows or has reason to believe a product does not conform. Article 13(23) requires informing authorities and users before ceasing operations. Many organizations have no written trigger, owner or decision path for these steps. Write a procedure that names who can order a stop to distribution, how affected customers are notified, and how the authority is informed. Rehearse it with a tabletop exercise so the first real use is not the first test.
Records kept for less than the required period
Article 13(13) requires the technical documentation and EU declaration of conformity to be kept for market surveillance authorities for at least 10 years after placing on the market or for the support period, whichever is longer. Article 13(18) sets the same period for user information. Retention settings in ticketing, document and build systems often default to shorter periods. Set retention per product line to the longer of the two periods, verify that backups and archives carry the same rule, and test a restore of an old release record before you rely on it.
Questions buyers ask about Article 13 cost, time and effort
What does Article 13 compliance cost a manufacturer?
No supplied figure gives a total cost, so the honest answer is that cost follows the scope of your product portfolio. Costs fall into four groups: internal engineering time for the Annex I work and documentation, tooling for SBOMs and vulnerability tracking, fees for an independent assessor where one is required, and ongoing work to keep the file current for the support period. The one-time work includes building the technical documentation and the first conformity assessment, while the recurring work includes component due diligence, vulnerability handling and record upkeep. Cost rises with the number of products, the number of third-party and open-source components, and the number of product versions in the field. Ask any provider for a fixed-scope quote that lists the products, deliverables and exclusions in writing before work starts.
How long does Article 13 preparation take?
The timeline depends on how far your product development is from the Annex I requirements and how many products you must document. The regulation applies from 11 December 2027, and products placed on the market before that date are generally outside its scope unless they are substantially modified, so many manufacturers are planning backward from that date. Preparation time is driven by the state of your SBOM and vulnerability process, the number of components requiring due diligence, whether a notified body is involved, and how many internal reviews the technical documentation needs. Reporting duties under Article 14 apply earlier, from 11 September 2026, so your incident and vulnerability workflow may need to be ready before the wider Article 13 work is finished. Confirm each milestone against the written scope.
How much work does Article 13 need from our own staff?
Most of the work sits with your own staff because the manufacturer owns the controls, the design decisions and the declaration of conformity. Product management must define the intended purpose and support period, engineering must show that the product was designed and produced to the Annex I requirements, and security teams must run vulnerability handling and component due diligence. Legal or compliance staff should review the EU declaration of conformity and the user information. An implementation partner can prepare systems, pipelines, documentation templates and evidence, but it cannot sign the declaration or issue a certificate. Ask any provider to name which deliverables need your staff, how many hours they expect from each role, and who approves each document.
Can our team complete Article 13 without outside help?
A capable internal team can complete Article 13 work without outside help, provided it has engineering, security and compliance skills and enough time. The main risks are gaps in component due diligence for open-source code, missing or stale SBOMs, and technical documentation that does not match the shipped product. Self-hosted tools can produce much of the evidence: OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, Trivy can generate SBOMs and scan existing ones, and XWiki keeps a version history of each document. Outside help is most useful for gap assessments, tooling setup, and independent review before assessment. Decide based on your team's capacity, not only its skills, and check the written scope of any partner before engaging.
When is a notified body needed for Article 13 conformity assessment?
Most products follow self-assessment under module A, so a notified body is not needed for them. A notified body is required for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II important products and critical products. Your product's classification under Annex III or Annex IV therefore determines the route before anything else. Notified bodies are notified by Member States and listed in the Commission's NANDO system. Because the harmonized standards are still being developed under standardization request M/606, check whether the standards that apply to your product exist at the time you plan your assessment.
How long must Article 13 technical documentation be kept?
The technical documentation and the EU declaration of conformity must be kept for market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer. User information follows the same minimum period. Because the support period can extend beyond the minimum, many manufacturers set retention to the longer of the two dates for each product version. Plan storage that keeps every version of each document, records who changed it and when, and can produce it on request. Confirm the retention rules with your legal team and with your provider, and make sure the written scope states where records are stored and who can retrieve them.
What should we ask for in a written Article 13 scope?
A written scope should state which products and versions are covered, which Annex I requirements the work addresses, and which Article 13 duties are included, such as due diligence, technical documentation, CE marking support, user information and corrective action records. It should list every deliverable, the systems it will be built in, the roles that must sign off, and what the partner will not do. For a DeployOpen engagement, the scope is agreed in writing before work starts, and DeployOpen prepares systems, controls and evidence for assessment. It does not issue audit reports, attestations or certifications, and a quote follows from that written scope. Ask for acceptance criteria for each deliverable so you can tell when the work is finished.
How DeployOpen scopes and prepares Article 13 evidence
DeployOpen helps manufacturers prepare the systems, records and documentation that Article 13 obligations depend on, inside the client's own infrastructure. The manufacturer keeps ownership of its controls and its declaration, and an independent assessor or notified body issues any report or certificate that a conformity route requires.
How we scope
- Each engagement starts with a written scope that lists the products, components and release lines covered by the Article 13 work.
- We confirm which conformity assessment route applies, since it determines whether a notified body is involved.
- Scope documents name who owns each deliverable: the manufacturer, DeployOpen, or an independent assessor.
How we build
- We set up component due diligence records covering third-party and open-source components, including SBOM review and known vulnerability checks.
- We configure SBOM and vulnerability tooling such as Dependency-Track and Trivy so component evidence is produced on a repeatable basis.
- We structure technical documentation and version-controlled records so the manufacturer can show what was done, when and by whom.
How we hand over
- We deliver the technical documentation, due diligence files and corrective action procedures as documented artifacts the manufacturer owns.
- We walk the manufacturer's staff through how each record is produced, updated and retained for the required period.
- We list open items that the manufacturer, its legal counsel or an independent assessor must still confirm before placing the product on the market.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial work is handed over.
- Ask any provider, including DeployOpen, to confirm in writing which parts of Article 13 they prepare and which parts an independent party must perform.
