Short answer: the technical documentation is the evidence file you prepare before you release an app, keep up to date, and hand to a market surveillance authority if it asks. It has eight parts (Annex VII), and you keep it, with the EU declaration of conformity, for at least 10 years or the support period, whichever is longer.
- Article 13(12) puts the order of work: prepare the technical documentation (Article 31), carry out the conformity assessment (Article 32), then draw up the EU declaration of conformity (Article 28) and affix the CE marking (Article 30).
- Article 31 says the documentation must contain at least the Annex VII elements, be drawn up before the app is placed on the market, and be kept updated, where appropriate, at least during the support period.
- Article 13(13) sets retention: 10 years after placing on the market, or the support period, whichever is longer. Article 13(22) says you provide it on a reasoned request from an authority.
- Most of the file is material you already need for other reasons: the risk assessment, the SBOM, the disclosure policy, the support period reasoning and the user information.
Where the file sits in the CRA workflow
Article 13(12) of the Cyber Resilience Act says that before placing a product with digital elements on the market, the manufacturer must draw up the technical documentation referred to in Article 31 and carry out, or have carried out, the conformity assessment procedure in Article 32. Where compliance with the essential cybersecurity requirements has been demonstrated, the manufacturer draws up the EU declaration of conformity under Article 28 and affixes the CE marking under Article 30.
So there are three different things, and teams often blur them:
| Item | What it is | Where |
|---|---|---|
| Technical documentation | The file of evidence: description, design, vulnerability handling, risk assessment, support period, standards, test reports. | Article 31, Annex VII |
| Conformity assessment | The procedure you follow to demonstrate compliance. For a product that is not an “important” or “critical” product, an internal-control procedure (Module A) is available. | Article 32, Annex VIII |
| EU declaration of conformity | A signed statement that the app meets the applicable requirements. One of the eight parts of the file. | Article 28, Annex V |
One summary of the conformity assessment rules we read says that Module A, the self-assessment route, is the general route for products that are neither important nor critical, with narrower or no use for the higher classes (Article 32(1) to (4)). We have not read Article 32 itself line by line, so check it before you rely on it, in particular if your app might be an important product, such as a password manager or a VPN client. This guide is about the file, not about that classification.
The eight parts of Annex VII as a checklist
Article 31(1) says the technical documentation must contain all relevant data or details of the means used by the manufacturer to ensure the product and its vulnerability handling comply with Annex I, and that it must at least contain the elements set out in Annex VII. Annex VII has eight points. The table maps each to an app team's work. The right-hand column is our suggestion, not wording from the regulation.
| Annex VII point | What it asks for | For a mobile app, keep |
|---|---|---|
| 1. General description | Intended purpose, the software versions that affect compliance with the essential requirements, and the user information and instructions under Annex II. Photos or illustrations of hardware are listed too. | A one-page product description per app, the release versions in scope, and a copy of the published user information. The hardware items do not apply to a software-only app, which is our reading; confirm for your product. |
| 2. Design, development, production and vulnerability handling | Design and development information, including a system architecture description of how software components interact. Vulnerability handling information: the SBOM, the coordinated vulnerability disclosure policy, the contact address for reports and the technical solutions for secure distribution of updates. Production and monitoring processes and their validation. | Architecture diagram of the app and its backend, the SBOM for each release, the published disclosure policy and security.txt, a description of how updates reach users (store, in-app, backend), and a description of your build, release and monitoring pipeline. |
| 3. Cybersecurity risk assessment | The risks the product is designed, developed, produced, delivered and maintained against, and how the Annex I Part I requirements apply. | Your risk assessment, versioned. See the risk assessment guide and the Annex I checklist for apps. |
| 4. Support period | The information that was taken into account to determine the support period under Article 13(8). | The reasoning and the end date per version. See the support period guide. |
| 5. Standards and specifications | A list of harmonised standards, common specifications or European cybersecurity certification schemes applied in full or in part. Where none were applied, a description of the solutions adopted to meet Parts I and II of Annex I, and any other technical specifications used. | A short table of the references you worked from, for example OWASP MASVS as a working reference while harmonised standards are pending (note that it is not a harmonised standard), and what you did for each requirement. |
| 6. Test reports | Reports of tests verifying that the product and its vulnerability handling processes meet Parts I and II of Annex I. | Penetration test reports, static and dynamic analysis output, dependency scan results, and the dated record of the fixes. |
| 7. EU declaration of conformity | A copy of the declaration. | The signed declaration for each app, and the earlier ones when you update it. |
| 8. Software bill of materials | Where applicable, the SBOM, provided on a reasoned request from a market surveillance authority, when necessary to verify compliance with Annex I. | The SBOMs for every released version, stored so that you can produce one for any past version. |
Points 2 and 8 both mention the SBOM. As we read the two sources, point 2 makes the SBOM part of the vulnerability handling information you document, and point 8 is the authority's route to ask for it. In practice, keep one per release either way. The free open-source Shipmark SBOM GitHub Action can write a CycloneDX SBOM on each build, and the SBOM guides for Flutter and React Native show the manual route.
The EU declaration of conformity
Article 28(1) says the declaration states that the applicable essential cybersecurity requirements of Annex I have been demonstrated as fulfilled. Article 28(2) says it follows the model structure in Annex V and contains the elements specified in the relevant conformity assessment procedures in Annex VIII, and that it is made available in the languages required by the Member State in which the product is placed or made available on the market. Drawing it up makes you responsible for the product's compliance (Article 28(4)).
The sources we read list these Annex V elements, with small differences in wording and ordering between them, so check the exact text in the Official Journal:
- the product name, type and any other information allowing unambiguous identification and traceability;
- the manufacturer's name and address, or those of its authorised representative;
- a statement that the declaration is issued under the sole responsibility of the manufacturer;
- a statement that the product conforms to the relevant Union harmonisation legislation;
- references to harmonised standards, common specifications or cybersecurity certification used, where applicable;
- where applicable, the name and number of the notified body, a description of the procedure and the certificate;
- additional information where applicable, then the place and date of issue and the name, function and signature of the signatory.
Article 28 says the declaration must be kept up to date “as appropriate”, so tie its review to your release process: a substantially modified version needs a fresh look. See the support period guide for what counts. For an app agency, the first question is who signs, and that depends on who is the manufacturer: Agency or client.
When to write it, how long to keep it, who can ask
| Question | Answer | Where |
|---|---|---|
| When is it drawn up? | Before the app is placed on the market. | Article 13(12), Article 31(2) |
| Does it change after release? | It must be continuously updated, where appropriate, at least during the support period. | Article 31(2) |
| How long is it kept? | At least 10 years after placing on the market, or the support period, whichever is longer. This applies to the technical documentation and the EU declaration of conformity. | Article 13(13) |
| Who can ask for it? | Market surveillance authorities, on a reasoned request. You provide the information and documentation, on paper or electronically, in a language the authority easily understands. | Article 13(22) |
Our support period calculator works out the retention date for a given app version. Two practical points follow from the table. First, “the file” must outlive your team's tooling, so store it somewhere with a retention policy and not only in a wiki page that someone will reorganise. Second, “continuously updated” means the file changes with the app: a new SBOM per release, a changed risk assessment when the architecture changes, a new declaration where needed.
A source we read says that micro and small enterprises may use a simplified documentation format set by a Commission implementing act (it cites Article 33(5)). We did not verify the implementing act or its status, so do not plan around it yet; the Annex VII content is the safe baseline.
What the Commission guidance adds
The Commission published its guidance on applying the CRA as communication C(2026) 5252 on 27 July 2026, under Article 26. It is not binding. The summaries we read do not describe Annex VII in detail. What they do say is practical: the Schutzwerk summary says the risk assessment and the technical documentation must stay accurate, complete and up to date, suggests checking at each release which changes must be reflected in tests and documentation, and recommends recording where the technical documentation is held and the reasoning behind each product decision. The noze summary recommends a register of which version is supported until when, with the reasoning. We have not read the guidance itself.
A working structure for an app team
- Create one folder or repository per app, named after the app, with eight sections that follow Annex VII points 1 to 8.
- Link instead of copying where a live source exists, for example the published user information and the disclosure policy, but snapshot a dated copy at each release so you can show what was true then.
- Add a release checklist item: “technical documentation reviewed, SBOM stored, declaration still accurate”. It takes minutes when it is routine.
- Record who owns each part and where the file is stored, and who can retrieve it if an authority asks.
- Set the retention date per app version, using the later of 10 years after placing on the market and the end of the support period.
- Keep a changelog of the file itself, so that you can show how it developed.
Some of this structure is our suggestion. The regulation fixes the content (Annex VII), the timing and the retention, not the folder layout.
Apps already on the market
The requirements apply from 11 December 2027. Under Article 69(2), products placed on the market before that date are covered only if they undergo a substantial modification from that date; the reporting duties of Article 14 are the exception under Article 69(3). If you will ship a substantially modified version after the date, plan its file now. See the support period guide for the same point.
Frequently asked questions
Is the technical documentation the same as the EU declaration of conformity?
No. The technical documentation (Article 31, Annex VII) is the file of evidence about the app. The EU declaration of conformity (Article 28, Annex V) is a short signed statement that the app meets the essential requirements. The declaration is one of the things the technical documentation must contain (Annex VII, point 7), and both must be kept for the same period under Article 13(13).
How long must the technical documentation be kept?
Article 13(13) says the manufacturer must keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after the product was placed on the market, or for the support period, whichever is longer.
Do we have to publish the technical documentation?
No. Article 13(22) requires you to provide it, on a reasoned request from a market surveillance authority, in paper or electronic form and in a language that the authority can easily understand. One exception reported by a summary of Article 32(5) concerns certain free and open-source software in the important-product classes, where the documentation is made public.
Does an SBOM go into the technical documentation?
Yes. Annex VII point 2 lists the software bill of materials among the vulnerability handling information, and point 8 says the SBOM is provided where applicable on a reasoned request from a market surveillance authority.
Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: the official text. The EUR-Lex page did not load its full text in our tool, so the provisions below were read through copies and summaries.
- SpringLex: Annex VII and Article 13 (paragraphs (12), (13) and (22)).
- EU Cybersecurity: Article 28, Article 31 and the EU declaration of conformity, and the Independent guide to the CRA: annexes (Annex V and VII).
- Sorena: Module A FAQ, a summary of Article 32 and Annex VIII Part I.
- Independent guide to the CRA: the Commission guidance of 27 July 2026, Schutzwerk and noze, summaries of C(2026) 5252.
This guide summarises EU law for practical use. The regulation was read through copies and secondary summaries, not the Official Journal text, and the Commission guidance only through summaries. The suggested file structure is ours. It is not legal advice. Related: Support period calculator · Risk assessment · Disclosure policy · Does the CRA apply to apps?.
Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.
Top comments (0)