Annex I Part II (1) Vulnerability identification and SBOM

What the CRA SBOM requirement asks manufacturers to prove

If you are a manufacturer preparing a product with digital elements for CRA conformity, Annex I Part II (1) asks you to identify and document the vulnerabilities and components in your product, and to do so by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format. The SBOM must cover, at the very least, the top-level dependencies. In practice, you must be able to show a current, accurate list of what your software is built from, which of those parts you have checked for known weaknesses, and how that list is kept up to date for the whole support period. The requirement sits alongside the obligation to keep this record in the technical documentation, which Annex VII point 2(b) ties to the SBOM. Your assessor or a market surveillance authority will look for the file itself, not a description of a process. The risk this addresses is simple to state and hard to manage. A product rarely contains only code you wrote. It bundles libraries, container base images, runtimes, and packages pulled in by build tools, and each of those may carry a vulnerability that is published after you ship. Without a component inventory, you cannot tell whether a newly disclosed flaw affects a given release, so the search turns into guesswork. Most organizations find that the hard part is not generating a file but keeping it complete: transitive dependencies change with every build, vendored code rarely appears in package manifests, and components inherited from third-party suppliers are often invisible until someone looks inside a binary. Two decisions shape the work early. First, confirm which build artifacts the SBOM describes, because a file generated from a source manifest can differ from what actually ships. Second, decide who is allowed to see the SBOM. Sharing it with users is optional under Annex II point 9, but supplying it to a market surveillance authority on reasoned request is not, so your access controls and retention rules need to reflect that. The Commission may later set the SBOM format and elements by implementing act under Article 13(24), and that act does not appear in the Commission's implementation timeline as updated on 27 July 2026, so confirm its status with your assessor before fixing your format.

Which products, components and teams the SBOM duty reaches

The SBOM duty under Annex I Part II (1) is only as complete as the boundary drawn around it. The cards below cover the scoping decisions that change the work: which versions and software elements are in, how third-party and open-source code is counted, and who owns the component data once it exists.

Product versions and software elements in scope

Each released version of a product with digital elements needs its own component record, because a dependency upgrade in one version can leave another exposed. Start by listing the software elements that make up the product (firmware, services, agents, libraries, configuration bundles) and confirm which of them ship to users. Check whether a support branch still receives updates, since those versions remain in the duty for the support period.

Top-level dependencies as the minimum

The Annex I wording sets top-level dependencies as the floor for the SBOM, not the ceiling. Record every direct dependency your product declares, then decide whether transitive components are captured in the same record or in a later pass. Document that decision, because an assessor will ask why the SBOM stops where it does.

Third-party and open-source components

Components you did not write still belong in the SBOM when they are part of the shipped software. Include vendored code, copied snippets, container base images and open-source libraries pulled in at build time, and record the supplier or upstream project for each. Ask suppliers for their own component data where you cannot inspect the code yourself.

Build-time versus runtime dependencies

Some tools run only while the product is built, and others are packaged into the delivered artifact. Decide which category each one falls into and document the rule, because build tools that never reach users generally sit outside the product's software elements. Recheck the rule when the build pipeline changes, since a build step that starts bundling files moves a component into scope.

Firmware and cloud services built into the product

Firmware images, bootloaders and cloud backends that the product depends on are part of the question of what the product contains. For a connected device or SaaS-backed product, list the hosted services the product calls and the components they run, and mark which ones you control. Confirm with counsel and your own architecture reviews how the regulation treats services you operate versus services supplied by others.

Teams that own the component data

Component data is usually split across engineering, the build team, procurement and product security. Name one owner for the SBOM record of each product, and assign who updates it when a dependency changes and who answers when a market surveillance authority asks for it on reasoned request. Agree who decides whether the SBOM is shared with users, because that choice is optional under Annex II.

How an assessor tests the SBOM and vulnerability identification

This table sets out what an assessor is likely to check under Annex I Part II (1), from the technical documentation through to a sample of real builds and the vulnerability records. Read each row as a test step, the evidence the manufacturer should have ready, and the gap that most often causes a finding.

Test step	What the assessor checks	Evidence to prepare	Common finding
Technical documentation review	Whether the SBOM is included in the technical documentation required under Annex VII point 2(b) and is tied to a specific product version	Current SBOM file, version identifier, date of generation, and a note of the product release it describes	SBOM stored outside the technical file, or not linked to the released version
Format check	Whether the SBOM is in a commonly used, machine-readable format, such as CycloneDX or SPDX, and can be parsed by standard tools	Export of the SBOM in its native format and a record of the tool and schema version used to produce it	PDF or spreadsheet inventories presented as the SBOM
Top-level dependency coverage	Whether every top-level dependency of the product's software elements appears, with name, version and supplier where known	Reconciliation between the SBOM top-level list and the manifest files (for example, package lock or build descriptor) in the source repository	Direct dependencies missing because they were pulled in by a build step rather than a manifest
Sampling against the actual build	Whether the SBOM matches the artifacts shipped for a sample of products or releases, not only the source tree	Build logs, artifact hashes and the SBOM generated from the same build pipeline run that produced the shipped artifact	SBOM generated from source before the build, so bundled or vendored components are absent
Transitive component handling	Whether components pulled in indirectly are recorded where the manufacturer has chosen to include them, and whether the omission is documented	Documented scope decision for transitive dependencies and the tool settings that produced it	Transitive coverage silently absent, with no record of why, which weakens the top-level claim in practice
SBOM currency	Whether the SBOM was regenerated when dependencies changed, and whether each released version has its own record	Change history for the SBOM, regeneration triggers in the release process and records for past versions still in support	Stale SBOM still describing an earlier release after a dependency update shipped
Recording newly identified vulnerabilities	Whether vulnerabilities found in components are linked to the affected SBOM entries, with dates, status and the version where each was fixed	Vulnerability register or VEX-style records mapped to SBOM component identifiers, with triage decisions and fix references	Advisories tracked in email or tickets with no link to the component inventory
Access to the SBOM on request	Whether the SBOM can be produced to a market surveillance authority on reasoned request, within the timeframe the manufacturer has set internally	Named owner, storage location, retrieval procedure and a record of how the SBOM would be provided	No defined owner, so the SBOM cannot be produced quickly when requested

Building a repeatable SBOM and vulnerability identification process

The sequence below turns the Annex I Part II (1) duty into a routine that runs at every build and every review, so the manufacturer can show an assessor how components were identified, matched and recorded throughout the support period. Each step names what it produces so the output can go straight into the technical documentation.

Define product and component scope
Start by fixing the boundary of the product with digital elements: which firmware, applications, libraries, containers and bundled third-party software belong to it, and which cloud services are outside it. Product engineering and the product owner should agree this in writing, with the version or release train covered. The output is a scope record listing each software element and its owner. It is done when every shipped artifact maps to one named element and no element is left unassigned.
Generate SBOMs at every build
Configure the build pipeline to produce a software bill of materials for each release candidate, in a commonly used machine-readable format such as CycloneDX or SPDX, covering at least the top-level dependencies. Trivy is one open-source option that can generate SBOMs from images, filesystems and repositories, but the team should confirm which formats and depth their chosen tool produces. The output is a versioned SBOM file stored with the build record. It is done when every release has an SBOM that can be opened and parsed by a second tool.
Reconcile SBOMs with the component inventory
Compare each generated SBOM against the manufacturer's maintained component inventory, which may be kept in a CMDB or asset register such as GLPI. Investigate components that appear in the build but not in the inventory, and the reverse, then correct either the inventory or the build configuration. Record the reason for each discrepancy. The output is a reconciled inventory and a discrepancy log. It is done when the inventory and the SBOM agree or every difference has a documented explanation.
Match components against known vulnerabilities
Load each reconciled SBOM into a vulnerability management tool such as OWASP Dependency-Track, which consumes CycloneDX SBOMs and identifies components with known vulnerabilities, outdated components and license risk. The security team reviews the findings, separates confirmed exposure from false positives, and assigns an owner to each confirmed item. The output is a list of identified vulnerabilities per release, with status and owner. It is done when every finding has a disposition.
Record results in technical documentation
Write the identification results into the product's technical documentation and the vulnerability register, linking each finding to the SBOM version, the component, and the affected product release. Keep the SBOM itself in the technical documentation, since the regulation expects it there. The output is a traceable record that an assessor or market surveillance authority can follow from a product version to its components and findings. It is done when a reviewer can pick any release and reconstruct its components and their status without asking the engineering team.
Set a review cadence and triggers
Define when the process repeats: at every release, when a new vulnerability is published for a tracked component, when the scope changes, and on a fixed review interval the manufacturer sets and justifies. Confirm with the compliance lead how the review interval is decided and documented, since the regulation requires the process to hold through the whole support period. The output is a written procedure with named roles and triggers. It is done when the procedure has been run at least once end to end and the results are on file.

Who may see the SBOM and when it must be shared

The SBOM is part of the technical documentation that a manufacturer must keep for its product, and that documentation is the first place a regulator looks. Under Annex VII, the SBOM sits in the technical documentation, and a manufacturer must provide it to a market surveillance authority on reasoned request where the authority needs it to check compliance. The practical duty is therefore to keep a current, retrievable SBOM for every released version and to be able to hand it over in a usable format within the time the authority sets. Teams should confirm which person or function owns that request path, how requests are logged, and whether the SBOM is stored alongside the signed release it describes.

Sharing the SBOM with customers and other users is a choice, not a default duty. Annex II only requires the manufacturer to tell users where to access the SBOM if the manufacturer decides to make it available to them. If the company publishes it, for example on a support portal or with each release, the user information it provides must say where to find it. If the company keeps it internal, that decision should be recorded in the product's documentation and reviewed when customer contracts or procurement questionnaires ask for component lists. Legal and product teams should decide this early, because a public SBOM also gives attackers a map of the product's components.

Format is the open point. Article 13(24) allows the Commission to specify the SBOM's format and elements by implementing act, taking into account European or international standards. The Commission's CRA implementation timeline, as updated on 27 July 2026, does not list such an act. Before fixing a format in tooling or in the technical file, readers should check the Commission's CRA implementation page for any new act, and confirm the current position with their national market surveillance authority or an independent assessor. Choosing a commonly used machine-readable format now, and recording the version used in each release, keeps the SBOM usable whatever the eventual act requires.

Evidence that satisfies the SBOM and identification duty

An assessor or market surveillance authority will look for records that show components were identified and documented for each product version, not a single snapshot taken at launch. The cards below cover the artifacts that carry that proof and how to keep each one current between releases and between reviews.

SBOM files per product version

Keep one machine-readable SBOM for every released product version, in a commonly used format such as CycloneDX or SPDX, covering at least top-level dependencies. Each file should be tied to a build identifier and a version number so a reader can match it to the shipped artifact. Check that the SBOM is generated from the build pipeline rather than typed by hand, and that regenerated files for patched releases are stored alongside the originals. The SBOM is a technical documentation item, so confirm it is retained with the rest of the file.

Component inventory across releases

The inventory records every component, its version, supplier and license, and the products that use it. It answers the question of which products are affected when a component is disclosed. Refresh it on each build and on each third-party component update, not only at audit time. Where a component is shared across product lines, check that one record feeds all of them so the inventory does not drift between teams.

Vulnerability identification records

Record each vulnerability found in a component or in the product, with the affected versions, the source that reported it and the date it was identified. Scanners such as Trivy can scan an SBOM or a target and produce findings that feed these records. Confirm the records persist after a finding is closed, because the duty is to show identification over time. Include findings from your own testing and from external reports, not only automated scans.

Triage decisions and justifications

For every finding, document the decision: fix, mitigate, accept or not affected, with the reason and the person who approved it. Assessors look for reasoned judgment, so a bare status such as "ignored" is weak evidence. Use Vulnerability Exploitability eXchange (VEX) statements where the tooling supports them, and confirm that Dependency-Track can consume and produce them before relying on it. Review triage decisions when a new version ships, because a finding judged not affected can change once the component or its use changes.

Technical documentation section

Annex VII requires the SBOM to sit inside the technical documentation, so the file must include a section that points to the current SBOM for each version and describes how it was produced. Document the tools, the build step, the format version and the known limits, such as components the generator could not see. Assign an owner for this section and update it when the tooling or pipeline changes, so the description always matches what was run.

Process document and asset records

A written process states who identifies components, how often inventories are refreshed, how triage is approved and how the SBOM is handed to a market surveillance authority on reasoned request. Support it with asset records for the systems that build and run the product, such as GLPI entries or Wazuh inventory for build and test hosts. Review the process at least once per support cycle and record the review date, so the document and the practice stay aligned.

Open-source tools that produce or hold SBOM evidence

Trivy is an open-source scanner under the Apache-2.0 license that identifies OS packages and software dependencies in a target and can output them as a software bill of materials. It can also scan an existing SBOM, which helps teams check a component list produced by another tool. For the Annex I Part II (1) duty, generation is the starting point: the SBOM must cover at least top-level dependencies in a commonly used machine-readable format.

Target types: Confirm which target types your pipeline needs, such as container images, file systems or repositories, and test each on a representative build.
Output format: Check that the generated file uses a machine-readable format your downstream tools accept, and confirm the format version with the project documentation.
Dependency depth: Verify that top-level dependencies appear in the output, and document any dependency types the scanner misses.
Repeatability: Run generation in the build pipeline so each release produces a versioned SBOM tied to a specific artifact.
Existing SBOM scanning: Use scanning of existing SBOMs to check inputs from suppliers before you rely on them.

Before adopting it, read the Trivy README and confirm the scanner's fit for your languages, package managers and build systems.

What meeting the SBOM requirement costs and what drives it

This table breaks the SBOM requirement into cost components, showing who is paid for each, whether the cost is one-time or recurring, and what pushes it up or down. No prices are published here, so use the rows to build the questions you put to any quote and to your internal budget.

Cost component	Who is paid or who carries the cost	One-time or recurring	What drives it up or down
Tooling and hosting	Open-source SBOM generators such as Trivy carry no license fee, but hosting, storage and administration of an analysis platform such as Dependency-Track fall to the manufacturer or its implementation partner	Setup is one-time, hosting and upkeep recur	Number of products and retained SBOM versions; ask whether the quote covers high availability, backups and upgrades
Build pipeline integration	Internal platform or DevOps engineers, or an implementation partner, wire SBOM generation into each build and release job	One-time per pipeline, with occasional rework when build systems change	Number of distinct build systems and languages; standardizing pipelines lowers the per-product effort
Supplier and component inventory	Internal procurement, legal and engineering staff who collect component metadata and check supplier-provided SBOMs	Initial inventory is one-time, updates recur with each new dependency	Number of direct suppliers and whether they deliver machine-readable SBOMs; this is often the largest variable
Triage of vulnerability findings	Security engineers or product security staff who review findings, confirm exploitability and document decisions	Recurring, tied to release and advisory activity	Dependency count, advisory volume and how much VEX-style justification is maintained; suppression rules reduce noise
Evidence upkeep per release	Release managers and engineers who archive the SBOM, record its version and link it to technical documentation	Recurring with every release and every in-scope product version	Release frequency and the number of supported versions still in the support period
Independent review and testing	External security reviewers or testers chosen by the manufacturer, who check SBOM completeness against the build	Usually periodic rather than per release	Scope of the product, the number of products reviewed and how often the SBOM is re-verified
Notified body or auditor sampling	Notified bodies or other assessors, paid by the manufacturer under their own fee terms, who may sample the SBOM and its generation records	One-time for the initial assessment, recurring when reassessment or surveillance applies	Product class and conformity route; ask the assessor how sampling is scoped and what records they expect to see
Responding to authority requests	Internal engineering and legal staff who produce the SBOM to a market surveillance authority on reasoned request	Occasional, unpredictable	Quality of the stored SBOM history; a retrievable archive per release keeps response effort low

Who owns the SBOM work and what a partner can take on

Your engineering and product security team owns the SBOM content and every triage decision made from it. The manufacturer is the party the regulation holds responsible for identifying and documenting vulnerabilities and components, so the accuracy of the component list, the handling of each finding and the decision about what is shared with users all sit inside your organization. Ownership also covers the technical documentation that records how the SBOM was produced and kept current across the support period.

Component scope decisions: Your team defines which products, versions and build targets each SBOM describes, and records which dependencies count as top-level.
Triage and risk decisions: Your team decides whether a reported vulnerability affects the product, what severity it carries and what remediation follows.
Sharing policy: Your team decides whether the SBOM is made available to users, since Annex II makes user access optional.
Technical documentation content: Your team writes and approves the record that Annex VII requires to include the SBOM.
Ongoing upkeep: Your team keeps the SBOM current with each release and each dependency change.

Before engaging any partner, confirm that a named owner in your organization can explain each of these decisions without help from the vendor or consultant.

Where SBOM programs usually fall short

An SBOM that exists on paper does not satisfy Annex I Part II (1). The gaps below are the ones assessors and market surveillance authorities are most likely to find when they ask for the SBOM in technical documentation. Each card names a gap and the action that closes it.

Generated once and never refreshed

An SBOM produced at release time drifts from the product as soon as a dependency is patched, replaced or added. The regulation expects the manufacturer to keep identifying and documenting components across the support period, so the SBOM must be regenerated with every build that ships. Close it by wiring SBOM generation into the release pipeline and storing each version against its release tag.

Top-level dependencies missing

The regulation sets a floor of top-level dependencies, and many SBOMs stop at packages a team imported directly while omitting OS packages, container base images or vendored libraries. An incomplete inventory undermines every later vulnerability decision. Close it by comparing the SBOM against the build manifests and container layers and recording any component the scan cannot see.

No link to shipped builds

An SBOM that describes a repository branch rather than the binary, image or firmware image a customer receives can be wrong about what is actually deployed. Assessors will ask which SBOM belongs to which shipped artifact. Close it by recording the artifact digest or version identifier inside each SBOM and in the technical documentation index.

Triage decisions left undocumented

Teams often review a vulnerability finding in a ticket or chat and then close it without a durable record. When a market surveillance authority asks how a component was assessed, the answer must exist in the documentation. Close it by recording each decision (affected, not affected, mitigated, fixed) as a VEX statement tied to the component and product version.

Unclear product and supplier ownership

Components often come from upstream open-source projects, suppliers or cloud services, and no one owns their inventory. When the product team assumes the supplier maintains the SBOM and the supplier assumes the product team does, the gap goes unnoticed until review. Close it by assigning a named owner for each component source and writing the handover into the supplier agreement or internal procedure.

Asset inventory separate from build data

Operations teams track deployed software in an asset register or endpoint inventory that rarely matches the build-time SBOM. Two inventories that disagree make it hard to say which vulnerable version is in service. Close it by comparing the deployed inventory against the SBOM for each released version and resolving any mismatch in the record.

Questions buyers ask about the CRA SBOM duty

Is an SBOM always required under the Cyber Resilience Act?

No, but for most in-scope products placed on the EU market after the regulation applies, the answer is yes. Annex I Part II point (1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format. The SBOM also belongs in your technical documentation under Annex VII point 2(b). The regulation applies from 11 December 2027. Products placed on the market before that date fall under it only if they are substantially modified from that date, so an older product may have a different deadline from a new release. Products outside the regulation's scope carry no SBOM duty under it. Open-source software stewards follow a lighter regime, so check that before assuming the full duty applies. Confirm your position with counsel for each product line.

What do top-level dependencies mean in practice?

Top-level dependencies are the components your product declares directly, such as packages listed in a manifest file or libraries your own code imports. Annex I requires the SBOM to cover these at the very least. Illustrative example: a web application lists its packages in package.json or pom.xml. Each listed package can pull in further packages, which are transitive dependencies. The regulation's minimum covers the listed packages, but a vulnerability often sits in a transitive package, so many teams record the full dependency graph. Your build tooling decides how much is captured automatically. Check whether your container images, firmware and operating system packages are included, since these are often missed when teams only scan source manifests. The minimum is a floor, not a ceiling, and your engineers should document the scope they chose. The full text is in Annex I of Regulation (EU) 2024/2847. The format and elements of the SBOM may be specified later by an implementing act under Article 13(24). The Commission's implementation timeline, as updated on 27 July 2026, did not list one, so confirm the status before you fix a schema.

Does the SBOM have to be published?

No. The regulation does not require you to publish your SBOM. Annex VII point 8 requires you to provide it to a market surveillance authority on reasoned request where it is needed to check compliance. Annex II point 9 requires user information on where to access the SBOM only if you decide to make it available to users. Article 13(25) also lets the administrative cooperation group run a Union-wide dependency assessment for specific product categories, and market surveillance authorities may then request SBOMs for those categories. In practice, most manufacturers keep the SBOM internal and share it under confidentiality terms with customers who ask, or with an authority on request. Decide your access rules before the first release, and document them. Ask your legal team to confirm how your customer contracts, licensing and disclosure policy interact with any sharing decision.

How much effort does building and maintaining an SBOM take?

The regulation does not give a figure for effort, so ask for a scoped estimate rather than relying on a benchmark. Effort depends on the number of products and versions in the support period, the languages and package ecosystems involved, whether firmware, container images or third-party cloud services are included, and how much of SBOM generation runs automatically in your build pipeline. Costs fall into two groups. One-time costs cover tool setup, pipeline integration, the format and scope decisions and the first documented process. Recurring costs cover generating an SBOM for each release, triaging vulnerability findings, keeping records for the support period and reviewing changes to dependencies. Stakes matter for the business case: Article 64 sets maximum fines of EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of Annex I. Ask any provider for the list of products, build systems, output format, generation frequency, who triages findings, retention period and handover documents.

Can our engineering team build an SBOM process in-house?

Yes, many teams can build the core process in-house, because the main tools are open source. Trivy, licensed under Apache-2.0, identifies operating system packages and software dependencies in a target and can produce them as an SBOM. It can also scan existing SBOMs. OWASP Dependency-Track, also Apache-2.0, consumes and produces CycloneDX SBOMs and VEX, identifies components with known vulnerabilities, flags outdated or modified components and tracks license risk using SPDX license IDs. The work that is harder to staff includes owning the process across releases, deciding which components to include, triaging findings with clear records and tying the output to your technical documentation. Your team also needs build engineering skills, security triage capacity and legal input on licensing. Test each tool's output against your own ecosystems before you rely on it, and confirm that the chosen format meets any implementing act that is later adopted. The Dependency-Track documentation explains the self-hosted setup options.

What does a partner's role cover for the SBOM duty?

A partner prepares and implements the systems and evidence. The organization still owns the obligation, the controls and the declarations. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For the SBOM duty, that can include deploying a self-hosted platform such as Dependency-Track, integrating SBOM generation into build pipelines, documenting the procedures and assembling the supporting evidence for the technical documentation. DeployOpen does not issue audit reports, attestations or certificates, and it does not act as a notified body. Where the conformity route requires a notified body, an independent body performs that assessment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from the written scope, and DeployOpen does not publish a price list. Ongoing support and upgrades are available as retainers.

How DeployOpen prepares SBOM and identification evidence

DeployOpen plans, implements and documents the self-hosted tooling that produces identification evidence, but the manufacturer keeps ownership of its product, its technical documentation and the decision about what the SBOM must contain. In practice, that means deploying a platform such as OWASP Dependency-Track inside your own cloud account, data center or air-gapped network, wiring it to your build pipeline so that SBOMs for each release are generated and stored, and writing down how the pipeline, the component inventory and the vulnerability review fit together. DeployOpen does not issue conformity reports, declarations or certificates. Where an assessor or market surveillance authority asks for evidence, DeployOpen prepares the records, and the assessment itself stays with the independent body that performs it.

Scope is set in a written statement of work before any work starts. Ask for it to name the products and product versions in scope, the SBOM generation method (for example, a scanner such as Trivy run in CI against build artifacts, or a build-tool plugin), the output format and the component elements to be captured, the storage location and retention period, and who in your organization receives access. Also confirm which items are one-time (initial deployment, pipeline integration, documentation) and which recur (platform upgrades, backups, ongoing support under a retainer). Dependency-Track's ongoing vulnerability analysis and triage is usually a recurring duty, so decide early who in your organization owns it.

The statement of work should also settle who may see the SBOM. Annex I Part II point (1) does not require you to publish SBOMs to users, and Annex VII requires the SBOM in technical documentation and to be provided to a market surveillance authority on reasoned request. Confirm with your legal team whether any user-facing disclosure is planned, and if not, restrict Dependency-Track project access to the roles that need it. Before signing, confirm with the authority or your assessor how they expect the SBOM to be delivered on request, since the Commission has not yet adopted an implementing act specifying the format and elements.